[REQ] Content plugin model update

[majkinetor !]

onRefreshStart()
Called before first request

onRefreshEnd()
Called after TC have finished displaying/searching.


This is 4 minutes work for you ghisler... Just put 1st func before FileNext loop and 2nd after.... and thats it.

[majkinetor !]

Any words, Ghisler ?

[ghisler(Author)]

In principle, the idea is good, and such functions were also part of the interface when I first designed it. But unfortunately it's much more complex than what you may think: The content plugin interface supports synchronous and asynchronous retrieval of the plugin values. Asynchronous means that the data is retrieved in a background thread. Therefore the data requests can come in a mixed mode for the two panels, and even for separate dirs when using branch view.

This is also described in detail in the content plugin help file:

About caching the data: Total Commander will not call a mix ContentGetValue for different files, it will only call it for the next file when the previous file can be closed. Therefore a single cache per running Total Commander would be sufficient. However, there may be other calls to ContentGetValue with requests to other fields in the background, e.g. for displaying result lists. There may also be multiple instances of Total Commander at the same time, so if you use a TEMP file for storing the cached data, make sure to give it a unique name (e.g. via GetTempFileName).

An idea to decide whether to cache data or not is to measure the elapsed time (GetTickCount). If there has been more than a second since the last request, it's better to verify whether the data has changed or not.

[majkinetor !]

What about transmiting thread ID ?
In DELPHI u can set this argument to have default value of 0 meaning this value is not important so current plugins unaware of threads are compatibile.

[Lefteous]

2ghisler(Author)

An idea to decide whether to cache data or not is to measure the elapsed time (GetTickCount). If there has been more than a second since the last request, it's better to verify whether the data has changed or not.

This is not a reliable solution. Please implement such a mechanism.
http://www.ghisler.ch/wiki/index.php/Info_about_refresh

[ghisler(Author)]

I could send such a notification, but I couldn't guarantee that there aren't any ongoing calls to the plugin in the background list. The refresh call could even occur at the same time as a background call, which could crash the plugin if it discards the cache in that moment...

[Lefteous]

2ghisler(Author)

I could send such a notification, but I couldn't guarantee that there aren't any ongoing calls to the plugin in the background list. The refresh call could even occur at the same time as a background call, which could crash the plugin if it discards the cache in that moment...

The plug-in is responsible for synchronizing access to its resources.

[majkinetor !]

What about thread ID ?

onRefreshStart ( threadID: HANDLE )
Called before first request for thread

onRefreshEnd( threadID: HANDLE)
Called after TC have finished displaying/searching in thread

The plug-in is responsible for synchronizing access to its resources.

right !