Esc key to close recompare dialog (and other MessageBoxes).

[browny]

Copy/paste of the dialog texts:

---------------------------
Compare contents
---------------------------
File(s) modified, recompare?
---------------------------
Yes No
---------------------------

Most dialogs in TC could be closed with Esc key, but not this one.

Cancel button automatically accepts Esc key in MessageBox.

So the easiest way would be to replace Yes/No with Ok/Cancel; even dialog text could be kept as is.

Edit.
Found more relatively unimportant dialogs that could not be dismissed with Esc key, but currently would not.
As this is a minor issue, and if nobody objects, I would simply add it here.
The list follows:
1) Recompare dialog (see above)
2) Edit file in archive. Message text:

Do you really want to unpack the selected file to a temporary directory and edit it?

3) Warning when attempting to close Commander while temporary files exist. Message text:

Warning: If you close Total Commander NOW
some temporary files extracted with Totalcmd
will not be deleted, since the programs started with them still run!
Close anyway?

[ghisler(Author)]

Hmm, this is is a question you answer with Yes/no, not with OK/Cancel.

[browny]

Hmm, this is is a question you answer with Yes/no, not with OK/Cancel.

Other options to egage Esc key would be more troublesome.

My guess is that Ok/Cancel might be tolerable here, though I am not a native English speaker to insist on that point.

[Dalai]

2ghisler(Author)
Well, in other places like the new update check, you already use Yes/No/Cancel dialogs - which would be very useful here, too, don't you think?

Regards
Dalai

[MVV]

Although any question may be rewritten to OK/Cancel form, Yes/No form looks more friendly:

Do you want to delete these items?
XXX
Yes/No

Following items will be deleted:
XXX
OK/Cancel

I've made a tiny NoCancel library that allows answering No in Yes/No dialogs by Esc, very handy. I start it elevated from Task Scheduler (to be able to close dialogs in elevated processes too) via rundll32:

Code: Select all

Command: C:\Windows\SysWOW64\rundll32.exe
Arguments: "X:\Path\NoCancel.dll",Resident

[browny]

Yes/No/Cancel dialogs

The Cancel button must differ from No in its function; otherwise it is a kludge and baffling choice for users.

Although any question may be rewritten to OK/Cancel form, Yes/No form looks more friendly

That is exactly what you would like to avoid with multilanguage applications - rewriting texts.

So the options could be
(sorted by ascending difficulty of implementation).
1) Leave things in current state.
2) Accept the suggestion.
My English friend said it would be passable (not perfect, of course); especially considering effect to effort ratio.
3) Use custom dialog.
This probably adds another .dfm and a module, but keeps all existing texts.
4) Use something like Windows CBT hooks and callbacks.
Also a good option.

[MVV]

4) Use something like Windows CBT hooks and callbacks.
Also a good option.

That's what my NoCancel library do - a global hook that sends No button press when there is no Cancel button in the dialog.
Perhaps it may be improved for using thread-wide hooks within local process but it is a bit more work to do because such hook must be installed for every thread separately. Also global hook works with all apps at once.

[browny]

Perhaps it may be improved for using thread-wide hooks within local process but it is a bit more work to do because such hook must be installed for every thread separately. Also global hook works with all apps at once.

Global hook is iffy.
Something like this might do what is needed: wh_keyboard_ll example
On Esc key up even send message to "press" No button.

[MVV]

Global hook is iffy.

Properly written global hook is not a problem at all. I use my library for almost 3 years (OMG, time's getting along!) w/o any problems (I only use 32-bit TC so it works with it).

Something like this might do what is needed: wh_keyboard_ll example

This is a global hook too, but it is more complex because it works on keypress level so have to check if active window is a message box (NoCancel simply catches WM_COMMANDs with Cancel button which are sent to a dialog on Esc and sends WM_COMMAND with No button then).

[browny]

Properly written global hook is not a problem at all.

There is a problem if someone does not want Esc key to close every messagebox in every application.

This is a global hook too

MSDN: This hook is called in the context of the thread that installed it.

[MVV]

There is a problem if someone does not want Esc key to close every messagebox in every application.

I doubt that one will want to answer No on Esc in one app and will not want to do the same in another one.

MSDN: This hook is called in the context of the thread that installed it.

Messages are processed in installer's context but the hook is still global because dwThreadId is zero:

For desktop apps, if this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.

Thread-wide hook is only good when you know the thread that should be hooked, but it is a problem with external processes.

[milo1012]

Properly written global hook is not a problem at all.

Seriously?
Hooks - especially global - are one of the main reasons for security software to alarm the user (example: our company's security software won't even allow a mouse button remapper program for such reason). It was just too often exploited by malware programs for keylogging, screen capturing, etc. in the past, so you can't accept the average user to use such program.

And I'm pretty sure that Christian won't use hooks in any form, see for example
http://www.ghisler.ch/board/viewtopic.php?t=38114
(in there you can also find such example code for how to customize std. MessageBox() button labels)


2Topic:
I'm also for a Yes/No/Cancel dialog, as it's a more common question for Windows applications in general.

[browny]

the hook is still global because dwThreadId is zero

That is getting offtopic, but:
Why you insist on using zero thread id when it is unnecessary?

I'm also for a Yes/No/Cancel dialog

Already answered above: the idea of having three buttons for two possibilities is far from brilliant.

[milo1012]

Already answered above: the idea of having three buttons for two possibilities is far from brilliant.

Well, repeating it doesn't change the fact that this is your own opinion.
I was involved in developing programs for different platforms, where such three-option dialog was in the favor of the majority of users, especially since they might not understand the actual question and therefore select "cancel" when in doubt (yes, even despite such hard facts).

Anyway, the perfect solution would probably be using a custom message box with the verb as a button
http://ux.stackexchange.com/questions/9946/should-i-use-yes-no-or-ok-cancel-on-my-message-box
So in our case: "Recompare" and "Cancel"
but as I said: only possible with a custom message box.

[browny]

Well, repeating it doesn't change the fact that this is your own opinion.

Should you pay attention and write someting about my objections before posting your opinion, there would be no need to repeat.

they might not understand the actual question and therefore select "cancel" when in doubt

A few times I encountered dialogs where cancelling would do something different from expectations.
From you links I got the following:
it is very important to chose excellent wording and good button texts, because nobody would read it anyway.

So in our case: "Recompare" and "Cancel"

It depends on the question; and currently Cancel does not make perfect button text.