SyncTool: first Click on [Close] after [Abort] doesn't work

[JOUBE]

If I click on [Close] immediately after [Abort] in the sync tool, this mouse click often doesn't work, but only a second mouse click. I don't know whether it's a mistake or intentional: in any case, it's annoying and disrupts the workflow (many Syncs at same time) : comparison (a few minutes) -> synchronization -> automatic restart of the comparison -> [Abort] -> [Close] (doesn't work) -> [Close]

It's annoying since (I do not know): Tc11.xx?

Joube

[ghisler(Author)]

The only case where I can see a slight delay is during the "comparing by content" phase. But I get the same also in older Total Commander versions like 10.52. In the "reading directories" phase I can even double click on "Abort" and it closes immediately.

[JOUBE]

Relatively before short times I started working with many (up to 10-15 max) smaller comparisons (250-4000 folders) in own instances at the same time. I am ending them now more quickly after the comparison (Abort->Close) as before, while other smaller syncs still running. Before now I used to synchronize with a few large comparisons in the Tc itself. So I changed the way I work, and before I didn't notice anything. But now it's quite annoying that you can't cancel straight away, but mostly surprisingly have to click twice. It gives me the impression that the Tc is deliberately preventing the clicking from happening.

[ghisler(Author)]

No, TC has to stop the comparison before it can close the window. When your system is very busy, it can take a while until Windows functions for reading directories or files return.

[JOUBE]

But it already shows the [close] at the button. Is this wrong (this means: to early)?

[ghisler(Author)]

Here it reacts immediately when the button already shows "close" and you then click on it. It doesn't react while the button still shows "Abort".

[AntonyD]

Yet something has changed in the behavior of this tool. Much more often, when starting the comparison process, a system overlay window from Windows began to appear - indicating that the process was overly busy and had completely stopped responding to messages. Although I compared, for example, only different Total installations in different folders. The number of elements in them is simply ridiculous, but this tool “corrected” in the latest builds has now begun to “stop responding to messages”...
And yes - I began to experience exactly the same difficulties with pressing buttons, as noted in the original message.

[JOUBE]

And yes - I began to experience exactly the same difficulties with pressing buttons, as noted in the original message.

Yes, something is wrong...

... it reacts immediately when the button already shows "close" and you then click on it.

Unfortunately no.

It doesn't react while the button still shows "Abort".

Honestly, what's the point of this statement? Of course [Close] can be seen on the button if clicking doesn't work.

If you say it works as always, but it doesn't, then it's not just a problem, it's a serious bug. At least debug: why does [close] appear when [close] doesn't do anything yet. As I've written, this behavior of [close] is quite annoying.

[white]

Can you give more info? Does it happen with 32-bit and 64-bit TC? Does it happen with a clean ini? What are the steps to reproduce? Which options do you use? In what phase do you click Abort?

I haven't been able to reproduce it, but I didn't compare very large folders. I did notice the behavior when I press Esc to abort and to close, but perhaps that is a different issue.

[JOUBE]

Clean ini? you are kidding, how is this supposed to work with preconfigured syncs? I believe you, that it is almost impossible to recreate the situation: But the main hint for ghisler(author) is, that the text [close] is shown at the button, before it is possible to click it. This he will find within the sources, I hope. (32 bit).

[ghisler(Author)]

Sorry, I cannot reproduce these problems at all. I need more info, otherwise I will never be able to reproduce your problems.
1. Some of you write that it got worse, but no one writes with which update. 11.02rc? 11.01? 11.0? Earlier?
2. In which phase does it take longer? When the footer shows "Reading directories:" or "Comparison:"?
3. What exactly are you comparing? Two local directories, a local directory and a remote directory, or something else?
4. When you click "Abort" just once, what happens then? Do you get an empty result list, or a partial result? If partial result, how long does it take to appear?

[AntonyD]

1) sorry but I can't tell exactly version. but definitely with 10.52 all was much faster
2) in both phases. In different situations, the situation manifests itself in either one phase or another
3) two local huge(> 1GB at least) dirs, or dir and zip|7z archive.
4) just once - nothing - after ~2 sec Windows cover the whole TC window with its special overlay window which "explain" to user that this is particular window/program got freeze and stopped response on windows messages. And after different periods of time (from 10 seconds to a full minute) - the overlay disappears and Total finally displays everything that it should.

And of course, it’s also annoying that pressing the Abort button is also not processed quickly. You can also wait up to a couple of tens of seconds before the synchronization process is interrupted. This is very annoying(((

p's. I've used 64 bit TC btw.

[ghisler(Author)]

3) How many files? And big is the largest?
4) The sync tool should only show something when aborting in the "Comparison" phase, otherwise the list should be empty. In this phase, TC updates the found items in the list when you use any display filter. For example, when you don't have the "=" button pressed, TC hides all files which were detected as equal until then in the "Comparison" phase. This can take a while when there are many 1000 entries. However, when aborting in the "Reading directories" phase, aborting should just clear the result list, which should be instantaneous.

One more thing: How long does it take during the "Comparison" phase to update the result list when clickin on the "=" button?
It should be almost instantaneous, except when using a screen reader.

[AntonyD]

3) > 2 - 4 thousands approx. Biggest = a couple hundred MB.
4) Processing of clicks of these buttons for the filter is acceptably fast. And I never tried to press anything else or exit at all - if suddenly at first I set the filter by pressing one of these buttons.
" However, when aborting in the "Reading directories" phase, aborting should just clear the result list, which should be instantaneous." - nope. at least a few seconds it will take for sure.

`clickin on the "=" button` as I said a little above - is acceptably fast. Not "almost instantaneous" - but rather fast.
Just like all its neighboring buttons

[AntonyD]

But in general, I also agree that the situation is very ambiguous and poorly repeatable on other machines. After all, even in my own home right now, for example, I have nothing to test this on. After all, taking and simply copying the same directory - but then simply deleting a couple of files somewhere in the depths of one of them, adding a couple of others, changing the contents in a couple of text files - unfortunately for some reason this is not an ideal test set would be. This comparison will go quite quickly... As if some cache from the disk is helping this process.