-[TC8.50b6] Issues Overwrite prompt dialog

[gdpr deleted 6]

Since there is much discussion lately about how the BTM should work, and how it should not work, i will have to make it abundantly clear here to avoid confusion:

This bug report is not about how the BTM operates, this bug report is only about issues of the overwrite prompt dialog shown by the BTM and the consequences thereof.

I did reproduce the problems outlined below consistently with TC8.50b6 32-bit and 64-bit on Windows 7 Pro x64 (Aero enabled).
Fresh wincmd.ini has been used.


Problem #1:

This is a very dangerous problem!

When the BTM shows the dialog asking the user whether to overwrite/skip an existing file, it will steal the keyboard focus.

So, if you are typing a text in whatever application at that time, most likely some of the key presses will now be received by the overwrite/skip prompt before you realize the situation. If you are lucky, the keys you just pressed do not correlate with the keyboard shortcuts of the overwrite prompt dialog. But likely you will press 'a', 'o', 'p', 'd', or some other keys which will choose an action from the overwrite prompt, although you don't want to.

This problem happens in 9 out of 10 cases.
So far, i have not really a reasonable guess of why in rare cases it doesn't do it.


Suggested solution:
BTM overwrite/skip prompt dialog never(!) steals keyboard focus.
Let the BTM "flicker" (which should also be observable in the taskbar) if the BTM wants the user's attention.


Problem #2:

(Will become an issue as soon as problem #1 is fixed. But not that severe.)

Naturally, when the BTM begs for your attention (or rather would if #1 is fixed), you would switch to the BTM (through taskbar or ALT-Tab).

However, you will not see the overwrite/skip prompt then, because that dialog is having the TC main window as its parent, not the BTM window.

So, if BTM begs, you would need to switch to TC instead to see the overwrite/skip prompt -- and you might still need to make the BTM visible separately if you need to take a look at the queue.

Suggested solution:
Let the BTM window be the parent of the overwrite/skip prompt dialog.


Problem #3:

(Might or might not be related to #2).

While BTM's overwrite/skip prompt dialog is shown, the BTM window becomes unresponsive, but you can still try closing it. If you do that, TC crashes.

[white]

Problem #1:

Not completely confirmed. It doesn't steal focus from other applications. Tested using TC8.50b6 32-bit on Windows XP Pro.

Confirmed when typing on Total Commander's command line. For example when typing "aaaa" or spaces.
I haven't found other reports about this except for this one explaining the danger of pressing Enter.

This is indeed dangerous. The same applies to a foreground copy operation. You may want to press Space bar or Enter to activate the Cancel button, but an Overwrite dialog may popup and activate the Overwrite button.

Same applies for mouse clicks. The Overwrite dialog may pop up just when you click somewhere causing you to click on the Overwrite button.

Solutions may be: Changing the default button and removing access keys from important buttons, don't accept input until a delay has passed without any input.

[ghisler(Author)]

Sorry, currently there are no plans to change this behaviour.

[gdpr deleted 6]

Sorry, currently there are no plans to change this behaviour.

@ghisler: Was your reply a response to my report, or to @white's post? I am confused.

I am not sure whether you speak about this being intentional by design, or whether you just don't have enough resources available to direct your attention towards this issue...

Whatever the reason, keeping this behaviour implies the assumption that the user refrains from doing something else on his computer while BTM copy/move operations are active, because "Blam! Overwrite prompt!" could happen.

F5/F6 copy/move operations pushed into the background do not suffer from this behavior. Considering that, the recommendation should be:

If you want to use your computer for other things while copying/moving files in the background - do not use the BTM. Use F5/F6 background copy instead. If you still decide to use the BTM, and you expect/know that an overwrite prompt will come, stop interacting with your computer until the prompt comes.

That would make the BTM pretty meaningless for copy/move operations, don't you think?
(Unless you treat it as a "F.oreground T.ransfer M.anager", ofcourse.)

However, that would still be no excuse to keep it as it is right now.

[ghisler(Author)]

The overwrite dialog has to be shown as a child of the main window because you can't have multiple modal dialogs in the same application (this also causes problems with Lister sometimes). Unfortunately it's not possible to show a dialog as a child of the active window and NOT make it active. Or is there?

[white]

elgonzo
I don't think the issues are numerous, nor are they specifically related to the BTM. They are related to all background threads (for example background unpacking). Can you change the subject of this thread for example in "issues overwrite dialog and background threads"?

You mentioned the Overwrite dialog stealing focus from any application. As I said I cannot confirm that. Is it true on your computer?

Whatever the reason, keeping this behaviour implies the assumption that the user refrains from doing something else on his computer while BTM copy/move operations are active, because "Blam! Overwrite prompt!" could happen.

True, suddenly displaying a dialog box while processing input from the user imposes a real danger. This danger increases the more the user uses background operations. Suppose the user uses AlwaysCopyInBackground, AlwaysUnpackInBackground and FtpInBackground...

Perhaps the danger of typing or clicking when a dialog pops up can be solved by hiding the Overwrite dialogs until the user chooses to show them. The dialogs could be created with Visible set to false. Something in the layout, for example the title bar or a new to include button called "BG dialogs" could flash when there are dialogs. Clicking this button could show/hide the Overwrite dialogs. Or perhaps the user could choose which dialog to show. Perhaps Overwrite dialogs could be queued and showed one at the time in FIFO order.

Is it possible to flash or color the taskbar button of the background window before it opens the Overwrite dialog in main window? That way, the taskbar would show which threads are effected by dialogs.

Perhaps it is possible to change the "Pause" button into "Dialog" button and then open the Overwrite dialog using a separate thread, causing the thread without visible elements to be nonresponsive temporarily.

[MarcinW]

Is it possible to flash or color the taskbar button of the background window before it opens the Overwrite dialog in main window?

Yes, it's just one API call - to FlashWindow function.

[gdpr deleted 6]

@white
Okay. I'll change the subject line. I am sorry if it caused confusion/misunderstanding.
EDIT: It seems, i can only change the subject line of my post, but not the subject of the thread.

@ghisler/mods:
Could you please rename the thread to "[TC8.50b6] Issues Overwrite prompt dialog". Thank you!

You mentioned the Overwrite dialog stealing focus from any application. As I said I cannot confirm that. Is it true on your computer?

It does, otherwise i would not have reported it.
Originally i did a quick check on a VM too, so as to rule out any side-effects specific to my system configuration. There i only tested with TC, where the focus was stolen from its main window just like as happened on my desktop.

However, based on your feedback, i fired up the VM again and tested with Notepad++/Wordpad/IExplorer. As it turns out, on the VM only TC's main window is affected by the issue; i could not reproduce keyboard focus stealing if other applications had the focus.

My real machine do not use any sort of desktop enhancements or other things where interference with the window management is susceptible, so i am a bit baffled right now about why on the VM the problem only affects the TC main window, while on my desktop it seems to affect basically any application. Unless somebody comes up with an explanation, i will spend some time next weekend spy++ing and digging a bit deeper into the problem and hopefully finding out what the root cause is.

[white]

@white
Okay. I'll change the subject line. I am sorry if it caused confusion/misunderstanding.

EDIT: It seems, i can only change the subject line of my post, but not the subject of the thread.

You need to edit your first post and change the subject

[white]

My real machine do not use any sort of desktop enhancements or other things where interference with the window management is susceptible, so i am a bit baffled right now about why on the VM the problem only affects the TC main window, while on my desktop it seems to affect basically any application.

On your real machine, do other programs also steal focus when displaying a modal dialog?

[gdpr deleted 6]

On your real machine, do other programs also steal focus when displaying a modal dialog?

No, i am not aware of any. But, my thinking actually goes in that same direction, however, i will need some time to find out what really is going on.

[ghisler(Author)]

TC should not be stealing the focus from other programs in this case. But the dialog will indeed interfere with other things you are currently doing in TC itself. I'm not quite sure how I should handle this - maybe make the dialog disabled for a few seconds so the user notices when typing that the input goes to the wrong dialog? But this could also be annoying for impatient users...

[gdpr deleted 6]

With modal dialogs (in the sense as Windows knows them), the desired behavior would not really be possible, unless you find a way to suppress Windows bringing the modal window to the foreground. The only way i know of is to use modeless dialogs and lots and lots of plumbing code

The approach with the timer could work (make it configurable as option in a beta version, so there is a chance to figure out what would be a good value before deciding on a default for it).

Don't worry about being annoying, i would say. Just the fact of the overwrite dialog opening will pull the user out of her/his routine.
Generally, to avoid unnecessary pauses, check which window wants to show the prompt dialog (BTM, background/foreground transfer progress bar, but not the TC main window). If the window is already active, and it doesn't feature controls with keyboard input/shortcuts, you can safely minimize pause. I would prefer to minimize the pause (say 0.5 sec) over skipping in such case, as it can catch a mouse-click happening just the moment when the prompt dialog opens.

[MarcinW]

Unfortunately it's not possible to show a dialog as a child of the active window and NOT make it active. Or is there?

If the child dialog is modal, it's impossible.
If the child dialog is non-modal, it's possible.

Here is some kind of a solution - with this code, form ignores button clicks for 500ms since showing (this time could be configurable). Other user activity, like pressing Tab, is not blocked. This code will probably work only with Delphi, because it was requited to use some internal Delphi messages. However, there must be a similar solution for Lazarus.

Declaration:

Code: Select all

type
  TDangerousForm = class(TForm)
    ...
  protected
    ...
    ShowWindowTickCount : Cardinal;
    procedure WndProc(var Message : TMessage); override;
    ...
  end;

Implementation:

Code: Select all

procedure TDangerousForm.WndProc(var Message : TMessage);
const
  INPUT_IGNORING_TIME = 500;

  function CheckTime : Boolean;
  var
    Difference : Cardinal;
  begin
    Difference:=GetTickCount-ShowWindowTickCount;
    {Delphi 2 has Cardinal defined as 0..2^31-1 instead of 0..2^32-1,
     so we must check the highest bit manually}
    Result:=(Difference < INPUT_IGNORING_TIME) and (Difference shr (SizeOf(Difference)*8-1) = 0);
  end;

begin
  case Message.Msg of
    WM_WINDOWPOSCHANGED :
        with TWMWindowPosChanged(Message) do
        if WindowPos <> nil then
        with WindowPos^ do
        if flags and SWP_SHOWWINDOW <> 0 then
          ShowWindowTickCount:=GetTickCount;
    CM_DIALOGKEY : {Enter pressed}
        if CheckTime then
        if ActiveControl is TButton then
        if TCMDialogKey(Message).CharCode = VK_RETURN then
        begin
          Message.Result:=1;
          Exit;
        end;
    CM_DIALOGCHAR : {Alt + keyboard shortcut pressed}
        if CheckTime then
        if ActiveControl is TButton then
        begin
          Message.Result:=1;
          Exit;
        end;
    WM_COMMAND : {Space pressed or clicked by mouse}
        if CheckTime then
        if ActiveControl is TButton then
        begin
          Message.Result:=0;
          Exit;
        end;
  end;
  inherited;
end;

Regards

[ghisler(Author)]

I have thought about this too, but it could be very annoying:
1. Some users may be typing blindly for more than half a second
2. Some users who are impatient may press ENTER multiple times if the first doesn't work, causing other actions this way...