Sync dirs enhancement

[wanderer]

For the last hour, i'm doing certain comparisons in the Sync Dirs window for certain file types. I have created a selection (1x button, defined a search filter) and i'm using it for all comparisons. I find it tiresome that each time i open the Sync Dirs window, i have to go and select that filter. It would be nice if it was remembered (in memory - until TC instance is closed). If for some reason this behavior is not liked, it could be enabled with an option in the INI.

EDIT - CLARIFICATION:
Once again, to be clear, the request is: If the "Sync Dirs" window is open, when it is being closed, store (in memory) whatever is selected as a search filter (wildcards or saved searches) and restore the selection when it is reopened (perhaps according to whether a specific (new) setting in the INI file is set to "true", for those who like the current behavior). Since this value should be stored in memory, this would be done for the current TC session (so the selection is lost when TC is closed).

[Horst.Epp]

Why don't you store your selection under a name.
The * button on the upper left.
You can reload it thru the same button or even make button for this sync profile on the toolbar.

[wanderer]

Why don't you store your selection under a name.
The * button on the upper left.

I have done just that (saved it) but every time the window opens, i have to go and select it and then press "Compare". Doing that with 40-50 comparisons in a day might be a little irritating...

You can reload it thru the same button or even make button for this sync profile on the toolbar.

Well, this would not be the most convenient way (for me at least). There is already a specific button for SyncDirs in the toolbar. I would just like to always use the last search i had selected.

[Fla$her]

TCFS2-based solution for TC x32:

Code: Select all

TOTALCMD#BAR#DATA
%COMMANDER_PATH%\Addons\TCFS2\TCFS2.exe /ef tcm(2020,1) eval(send_wait(,findwnd(TCmpForm))) sendmsg(findwnd(TMyComboBox,,findwnd(TPanel,,findwnd(TCmpForm))),334,1)

WCMICON2.DLL,48
Synchronize directories with the latest wildcard

[petermad]

2wanderer
Why not make a button using the SYNCOPEN command to open the setting automatically - like:

Code: Select all

TOTALCMD#BAR#DATA
SYNCOPEN Mysetting

wcmicons.dll,48
Open Sync Tool with settings: Mysetting

0
-1

Or with automatic compare:

Code: Select all

TOTALCMD#BAR#DATA
SYNCOPEN=Mysetting

wcmicons.dll,48
Open Sync Tool with settings: Mysetting - automatic comparison

0
-1

[Fla$her]

2petermad
You offer what has already been discussed and what has been answered:

I would just like to always use the last search i had selected.

The last search means the last filter (wildcards).

[sa16]

1x button, defined a search filter

Predefined filter, no wildcards?

[petermad]

2Fla$her

The last search means the last filter (wildcards).

Well your solution:

Code: Select all

TOTALCMD#BAR#DATA
%COMMANDER_PATH%\Addons\TCFS2\TCFS2.exe /ef tcm(2020,1) eval(send_wait(,findwnd(TCmpForm))) sendmsg(findwnd(TMyComboBox,,findwnd(TPanel,,findwnd(TCmpForm))),334,1)

WCMICON2.DLL,48
Synchronize directories with the latest wildcard

does not reenable the last used filter set with the 1x button. See: https://tcmd.madsenworld.dk/syncwildcards.mp4

Other setings like Asymmetric, Subdirs, Empty directories, and the active Show buttons are already remembered by TC, you don't need a TCFS2 script for that.

It seems to me that the only way to retrieve the wildcard filter (in the top middle, between the Source and target paths) is to use a saved setting.

[Fla$her]

2petermad
You don't get the gist of the request. It wasn't about a set of options. The filter is the only combobox with wildcards in the dialog. And it's in it that the last choice is not remembered. All other options are remembered without any use of the template.

Well your solution does not reenable the last used filter set with the 1x button.

>>>

TCFS2-based solution for TC x32:

I don't have Win x64 at hand, so I can't immediately remember what classes are needed for TC x64. If there is a desire to help, I will tell you how to get them.

[petermad]

2Fla$her
Sorry I didn't notice the x32 clause - yes it works in 32bit TC

So now I know that TCFS2 scripts might not be useable universally

I my suggested buttons were a reply to:

I have done just that (saved it) but every time the window opens, i have to go and select it and then press "Compare". Doing that with 40-50 comparisons in a day might be a little irritating...

Apart from that I support wanderer's request for TC to use the last wildcards, at least in the same TC session (maybe configurable with an ini-parameter) - so we don't need a lot of workarounds.

[Horst.Epp]

So now I know that TCFS2 scripts might not be useable universally
at least in the same TC session (maybe configurable with an ini-parameter)

That not a problem of TCFS2.
Its a result from different Compiler environment for 32/64 bit
which have other class names.

But this problem is going away as the long term Windows is x64
with the exception of hardcore users of old platforms

[Horst.Epp]

So now I know that TCFS2 scripts might not be useable universally
at least in the same TC session (maybe configurable with an ini-parameter)

That not a problem of TCFS2.
Its a result from different Compiler environment for 32/64 bit
which have other class names.
You can adapt to the current environment with some AutoStart plugin functions.

But this problem is going away as the long term Windows is x64
with the exception of hardcore users of old platforms

[petermad]

2Horst.Epp

That not a problem of TCFS2.

I didn't say it was a TCFS2 shortcoming...

[Fla$her]

So now I know that TCFS2 scripts might not be useable universally

Incorrect conclusion. This only applies to commands where the search for different window classes is used.
Give me the dialog classes and I'll show you the button for both bitness.

But this problem is going away as the long term Windows is x64

Because of plugins, many users prefer to use TC x32 on Win x64, so this is a weak argument.

[petermad]

This only applies to commands where the search for different window classes is used.

Hence the use of the word "might".

I wrote:

So now I know that TCFS2 scripts might not be useable universally

Notice, I said that SCRIPTS (a given script - not the program) MIGHT (as in "can possibly") not be universally usable - I did not state that TCFS2 cannot be used to make universally usable scripts - but the above example is not of them, which proves my point .

And since the script code is not for everyone to decipher (I cannot tell that the above example calls TC classes) - I just noticed that from now on, when presented for a TCFS2 script the reader have to make sure that it can be used for his flavor of TC, either by reading the fine print (which I failed to do) or by asking.