[BUG] ESC doesn't close Directory Sync when focus...

[icfu]

...is set to the empty results area before starting the comparison.

Steps to reproduce:
1. Open Directory Sync
2. Click with mouse in results area
3. Compare by pressing Enter (don't use mouse)
When comparison is done:
4. Press Escape => no visible effect (invisible focus is released)
5. Press Escape => close

It doesn't work always as I have found now now, so please try to repeat these steps several times.

XP SP2 here.

Icfu

[Stitscher]

Can't confirm.

Directory Sync closes by pressing ESC the first time.

WinXP+SP2

[icfu]

Lefteous has pointed to this correction in 6.55:

Code: Select all

25.04.06  Fixed: Synchronise dirs: ESC has to be hold down for at least 100ms to avoid that comparison is stopped when pressing ESC in compare by contents window

So, obviously the timer is called not only during a comparison but also when no comparison is running. Maybe this can be changed?

Icfu

[ghisler(Author)]

The idea is that when any window in front of synchronize dirs (e.g. compare by contents, lister etc) is closed with ESC, it should be avoided that sync is also closed.

[icfu]

Is there any reason why you close the window already when ESC is pressed instead of when ESC is released?

If you would close the window after release, there would be no need for any timeout. This is true for all windows that can be closed by ESC in TC...

Icfu

[ghisler(Author)]

Yes, that's a good point - but the user expects that the window closes when ESC is pressed. Try for example a standard menu, or the Windows start menu, or any dialog box outside of TC...

[icfu]

Yes, that's a good point - but the user expects that the window closes when ESC is pressed. Try for example a standard menu, or the Windows start menu, or any dialog box outside of TC...

1. The Compare and Sync thingies are WINDOWS, no boxes or menus.
2. You only have advantages when a key release closes the box:
2.1. You can have a last look at it.
2.2 You can cancel the ESC by moving the cursor somewhere else.
2.3. You don't need delay workarounds which lead to negative side effects like being forced to wait longer for window close than without it.
3. Who is that user and why would he prefer to be able to kill 20 windows in a row if he holds down ESC too long? Just because other dialogs and menus act stupid, you don't need to copy that and make it even worse.

Well, I am annoyed by the delay because it feels wrongly, compared to the key response I got used to. Now I press ESC and nothing happens: not really an advantage...

Icfu

[StatusQuo]

but the user expects that the window closes when ESC is pressed.

Agree.

Now I press ESC and nothing happens: not really an advantage...

I consider this an advantage over accidently closing the Sync window.
Imagine you have just done a (fulltext) search over a large number of files, which may have took quite a long time.
Pressing ESC another time costs you seconds. Losing your results costs you minutes to hours to get the results back...

Alternatively you could use Alt-F4 which could work better for you.

[icfu]

You have missed the point, please reread this posting:
http://ghisler.ch/board/viewtopic.php?p=96353#96353

Alternatively you could use Alt-F4 which could work better for you.

This shortcut is blocked on my box with AHK, because when holding it too long, you can easily nuke half a dozen apps in a row. Also this shortcut is cumbersome, I prefer ESC+F1 as a closing shortcut which I have configured to work only on release, so it can only close exactly one window.

Icfu

[deus-ex]

@icfu

Hey, nice picture of yourself (Avatar).
So you are indeed a handsome Alien, eh?

__________________
Live long and prosper,
deus-ex

[icfu]

Nope, I am a Tofu. Don't miss it.
http://www.youtube.com/watch?v=NFJPt7izMnY

Icfu

[StatusQuo]

You have missed the point, please reread this posting:

I found nothing new, sorry, but thought about it another time.
When coming from another window while ESC key is still pressed, the Sync window receives the KEY_UP for ESC, so it would close anyway (also when waiting for/reacting to the release of the key) - or not?

I have not tried this in my own applications, so it's just a guess: perhaps it could work this way:

• never close on a received ESC character, instead
• remember when KEY_DOWN message is received for ESC
• on a received KEY_UP message for ESC:
  - check, if previously a KEY_DOWN was received, while the same window was active;
  - only close, when KEY_DOWN + KEY_UP were received while the own program window was active

[icfu]

Exactly this is how I would expect it to be done in TC.
Of course not only for the sync window but for all windows...

With AHK my solution is like that:
Close the window which was active when Esc was pressed down, when Esc is released. Of course, this special systemwide solution is not possible for TC because it doesn't know about other windows.

Icfu

[StatusQuo]

If this will be changed in a future version: This could have some side-effects.
Example:
When comparing big directories over a network connection, TC Sync doesn't react to ESC.
If you therefore hold down ESC until you see the abortion, the Sync Tool would close on releasing the ESC key.
So a remembered KEY_DOWN should be cleared when the Sync tool enters the routine waiting for user input (and close only, if ESC is pressed and released within the same waiting routine).