Total Commander

As obtaining data about file versions can be slow, i am getting them in worker thread and returning ft_delayed while it runs. But when i have all the data, my fcn is not called untill (i presume) file row is not refreshed by sliding cursor line over it or listctrl is scrolled (well untill rgn is refreshed). Is there any way for me to trigger updating from plugin? Or at least get totalcmd hwnd to call redrawwindow, invalidate, <whatever>... EnumWindows is a bit annoying for such simple task...

Found.

hwndTotalcmd = FindWindow("TTOTAL_CMD", NULL);

Thank you anyway

Is there any way for me to trigger updating from plugin? Or at least get totalcmd hwnd to call redrawwindow, invalidate, <whatever>

Please DO NOT do this. More and more other programs start to use Total Commander plugins, and relying that your plugin is called by TC is very bad practice. It's the same bad programming as those Explorer shell extensions which crash when called from other file managers like TC...

But when i have all the data, my fcn is not called untill (i presume) file row is not refreshed by sliding cursor line over it or listctrl is scrolled (well untill rgn is refreshed).

Why is this a problem? The data is only needed when the field is displayed! You can either start your calculation on the first call and put the data in some kind of cache, or start the calculation only on the second call.

2ghisler(Author)

Why is this a problem?

It's the same as with PreloadThumbnails. Navigating in a directory is just smoother when calculations are continued when more than just the visible columns are calculated.
Please add PreloadColumns.

ghisler(Author) wrote:

Is there any way for me to trigger updating from plugin? Or at least get totalcmd hwnd to call redrawwindow, invalidate, <whatever>

Please DO NOT do this. More and more other programs start to use Total Commander plugins, and relying that your plugin is called by TC is very bad practice. It's the same bad programming as those Explorer shell extensions which crash when called from other file managers like TC...

But when i have all the data, my fcn is not called untill (i presume) file row is not refreshed by sliding cursor line over it or listctrl is scrolled (well untill rgn is refreshed).

Why is this a problem? The data is only needed when the field is displayed! You can either start your calculation on the first call and put the data in some kind of cache, or start the calculation only on the second call.

A bit explanation; I am "driving" one cleartool instance with redirected stdin/out behind plugin. Once i enter directory i run a ls <dir>/* command to obtain data for whole directory as it is much faster then using it for single file. And this takes time (even 5 seconds), so i process it in background thread into map<filename, parseddata>. So if data are processed (btw, no, cs is not an option, i though about that) they are loaded from that map.

At the moment i have the data i want them to be shown. Not after user scrolls, hide/show window etc. They should be shown at the moment i enter directory, but this would block quick "surfing" through directorys (you enter directory, ls is triggered, you wait for 5 seconds as you are blocked, then you can continue... a bit annoying. So now; you enter directory, ls is triggered in background thread that is stopped and rerun on any dir change. You can still fly through directory structure without any blocking). I dont think i have any alternative for that then refreshing the pannel (well unless you have some better idea). And after all, it is one refresh thread end (=per entering directory), i dont think this is such a big expense...

"It's the same bad programming as those Explorer shell extensions"

You try to insult me, right? (*joke*) if some other program loads this plugin, window is not found, so it is not refreshed, one simple if() (you know, that old good E R R O R H A N D L I N G?) ... it is not really showstopper, right?

ghisler(Author): Ok, i figured out why i needed to do a refresh, you were right, if i would do it documented way and return delayed for CONTENT_DELAYIFSLOW only, everything would be fine... to some point... well side effect for checking that flag is WaitForSingleObject(threadstopped, TIMOUT) and this slow things down. A lot. Maybe a little more control from plugin side is needed here Sometimes if lot of processing (or as in my case; communicating with service that does its "magic" trough network) is involved it is faster to obtain data for whole directory instead of processing for each file on function call.

i have one little request/question, you have CONTENT_DELAYIFSLOW flag, but i am unable to recognise if the plugin was run for search... is it possible to somehow signalise (trough bitmask?) to plugin why it was called? I could optimise search of versions/rules/checkouts in clearcase a lot if i would know why i was called... again i have a walkaround (FindWindow TFindFile), but... well i hate it

another nice thing would be to add another type of colume, something like ft_icon (image, whatever...) to provide a path to icon that would be shown in column. I was thinking about implementing it on my own, but I am not to glad about runtime subclassing your pannels... but sure i do understand you have more important stuff to implement.

(sorry if i am pain in the as*, i am just trying to be usefull, you have great plugin architecture (i couldnt believe that actually all i need is there), but when i head for speed optimisations, some stuff is missing. Surely for hit and run plugin the architecture is all i need but i can/will do it better...)