wdx - when obtaining file information is slow

[Hologram]

Hi all,
I am developing content plugin (wdx) to show some information from specific files, but obtaining such information is a bit slow (few seconds) so my idea is like following:

When the file is parsed for the first time I save its result into a file (in plugin folder) which will serve as a database holding required information for files already parsed so next time I don't need to parse file again, I just get this information from this file. It is good idea to load this file when the plugin is loaded so it is stored in memory or accessing it everytime information is needed (as disk operations takes more time)?

I think there can occure some issues e.g. when more instances of total commander are running, so there is a need to synchronize access to this file (e.g. using semaphores)?

Can you direct me to the best coding practices for my situation?
Any help appreciated, thanks.

[m^2]

I suggest to use a database, it will solve all synchronization issues for you. Like SQLite, it's said to be very easy to use (granted that you know SQL).
Remember to store file date together with this information if you expect that file modification might obsolete the results.
Also consider CONTENT_DELAY_IF_SLOW (written from my head, exact name might differ).

[j]

I second that SQLite choice. There are also several C++ wrappers which make it even simpler (if you are into C++). I for one have used the "SQLite C++ Wrapper", which is straight forward to use.

Other than that:
Do not store your cache/db file in the plug-in directory but the path of the ini-file which you either retrieve via the [face=courier]COMMANDER_INI[/face] environment variable or better via the [face=courier]DefaultIniName[/face] of the [face=courier]ContentSetDefaultParams[/face] call.
Remember that the user does not necessarily has access to write to the plug-in directory.

[Hologram]

Thank you both for helpful suggestions.

Ok, based on your suggestions, I decided to use a database, using Delphi I check for wrappers for Delphi or I try to use some Delphi file-based database solution.

As of DefaultIniName, I have read in documentation it points to the same path directory as wincmd.ini which is by default windows directory I guess, that's why I wanted to pick another location, but maybe I am wrong.

[m^2]

Thank you both for helpful suggestions.

Ok, based on your suggestions, I decided to use a database, using Delphi I check for wrappers for Delphi or I try to use some Delphi file-based database solution.

As of DefaultIniName, I have read in documentation it points to the same path directory as wincmd.ini which is by default windows directory I guess, that's why I wanted to pick another location, but maybe I am wrong.

It's Windows dir only if user has write rights to it.
I suggest giving users 2 options:
-near wincmd.ini. Almost warranted to have write rights.
-in the plugin directory. Simplifies plugin management, no need to trace different pieces all over the hard drive in case of uninstall.

[Hologram]

Thank you,
I decided to use plugin directory.

Meanwhile I have come across the following problem.
Plugin uses sqlite dll, which is distributed along wdx file.
When I try to install plugin I got an "Error loading plugin file!" error.

FileInfo plugin told me its only dll dependency is the mentioned sqlite dll so I saved it into win dir and plugin could be installed.
But next time when I launch tcmd, plugin uses dll in its directory so it looks like problem is only when I try to install plugin for the first time.
Is there any recommended way for distributing such plugins as I would be like if I can avoid copying dll into win dir, thanks.

[m^2]

Use dynamic dll loading. With LoadLibrary. This way you don't have to mess with Windows and can avoid dll hell.

[Hologram]

I have tried to use LoadLibrary in DllMain, but it doesn't help. I tried to call Sleep for a few seconds and seems it resolved it somehow.
Maybe it is a bug when installing plugin with zip packer. Simple copying files into content plugins directory and using Configuration menu in tcmd works with no problems.
I'll search for similar plugins using dlls and check them.

[m^2]

Don't know how is it with Delphi, but it's the way you included the library. The goal is to get rid of sqlite.dll in your plugin's imports list, as long as it's there, expect troubles.
In C++ it would be usually (depends on compiler, linker and their settings) enough to not call functions directly, but LoadLibrary, GetProcAddress of all functions and use the addresses resolved this way.

[Hologram]

Wrapper rewritten so it can use dynamic linking and now it works well, thanks for helpful advices.