[9.2b]Plugins install Window OnTop LOST

[MarcinW]

No, you don't need to do nothing! Blinking is the standard operating system's behavior! The problem is that 32-bit TC overrides this standard behavior somehow - I suppose it's not intentional.

I'll make some experiment and let you know here.

[ghisler(Author)]

Well, I don't override it, it's probably somewhere deep in the Delphi libraries.

[MarcinW]

I think it's rather not a Delphi problem, since the example pasted above (test.zip) works properly.

I need few more days to investigate this.

[ghisler(Author)]

Unfortunately I couldn't find the reason. WM_WINDOWPOSCHANGING doesn't seem to be the problem - I do get this message when I click outside, but I don't get a beep, whether I return 1 or 0.

But this isn't the original problem here - I think that the original problem was solved?

[MarcinW]

I found the reason.

It looks like a missing call to DefWindowProcA / DefWindowProcW for WM_SETCURSOR messages - at least when SmallInt(lParam) = HTERROR.

All 32-bit TC windows suffer from this problem.


Regards

[ghisler(Author)]

Nice find, that seems to fix it, thanks!

[ghisler(Author)]

This should be fixed in Total Commander 9.20 beta 4, please check!

[MarcinW]

Now we can see that your patch for the main TC window works properly

Other TC windows still suffer from improper WM_SETCURSOR handling. For example:

A) Lister:
- press F3 on any file
- search for some text that can't be found, so you get a message box
- now click on the Lister window - message box doesn't blink - this means improper WM_SETCURSOR handling in Lister widow

B) Configuration window:
- choose "Configuration -> Options", so you get configuration window
- select "Font" in the left panel and press any of the "Change font" buttons, so you get a font selection dialog
- now click on the main TC window - font selection dialog blinks - this means proper WM_SETCURSOR handling in main TC window
- now click on the configuration window - font selection dialog doesn't blink - this means improper WM_SETCURSOR handling in configuration window

C) "Change attributes" window, "Find files" window, "Multi-rename tool" window also have similar problems as in B)

Solution: patch all your remaining WM_SETCURSOR handlers in the same way, as main TC window.

I think that the original problem was solved?

I just found a window with its parent improperly set (i.e. to TApplication instead of main TC window) - this is the nag screen ("Press 1/2/3") - both in 32-bit and 64-bit TC.

If you could implement WM_SETCURSOR fix in all the remaining windows, it will be much easier to test this - just by clicking, not by using tools like Microsoft Spy++.

[MarcinW]

16.05.18 Fixed: Add flag WS_POPUP for all resizable dialog boxes, otherwise GetParent() would return 0 (32/64)

Just one question to be sure, that anything has been overlooked: why is the GetParent() call needed for WS_POPUP windows?

GetParent(WndHandle) only works when called on WS_CHILD windows (like button, checkbox, etc. - which move along with their parents).

To get parent of some stand-alone window (i.e. window having the title bar), GetWindow(WndHandle, GW_OWNER) must be called.

Regards

[ghisler(Author)]

Sorry, I don't have the time to manually check all windows. I will add it for the nag screen as reported.

[MarcinW]

I think I was misunderstood.

Checking manually for parents of all windows would be, of course, highly time-consuming.

I was talking about WM_SETCURSOR handlers (i.e. adding DefWindowProcA/W calls for them). Just search for "WM_SETCURSOR" string in your code - you probably share the same code for many window classes, so there are probably only two or three places with WM_SETCURSOR handlers, that need to be fixed.

Regards

[DrShark]

It seems the behavior of Sync Dirs window I mentioned above is actually a bit different:
if to use Compare in Synchronize tool on some deel-level tree and to minimize and then restore window, Sync window may hang, and following minimize-restore tries may get main Total Commander window restored, and Sync Dirs window will be on top it, but not in restored state: it will be just a small window header (title bar) near Windows Start menu button, screenshot:
http://c1.staticflickr.com/1/894/42377548042_edf06323e0_b.jpg
It's possible to restore Sync Dirs window manually using a context menu of that window header/title.

However, I have a question about such situation: is it possible for TC to make Windows to restore SyncDirs window in such a case, or at least to place that header of SyncDirs window not in a left corner near Start button, but in a different place (centered / bottom centered)?

[MarcinW]

@DrShark:

The behavior that you described looks like due to unresponsive application (in this case: TC). When a thread, that created the window (in this case: sync tool window), doesn't read messages from the operating system for 5 seconds or longer, operating system assumes that the application is unresponsive (hung).

Under normal circumstances, the application itself is responsible for painting its own windows (by reading from the operating system - and handling - messages like WM_PAINT). In case of hung application, the operating system starts to paint the window - but only as a "ghost" window, having only a title bar, with empty window area. When the application starts reading messages from the operating system again, it repaints the window and everything starts to work as usual.

Side note: calling SendMessageTimeout API with a non-zero timeout value and SMTO_ABORTIFHUNG flag prevents our application from hanging, when the destination window's thread is hung.



Remedy: application should process messages at least every 5 seconds. In TC, this could be done by calling:

Code: Select all

Application.ProcessMessages

after processing every file. But I suppose, that TC already does this - and TC was hung just due to long-lasting disk operations.



Conclusion: The described behavior is normal and desired - and not connected in any way with the original problem, described in this thread. The only thing that can be potentially improved, is processing messages by TC after each synchronized file - if not already implemented.

Regards

[ghisler(Author)]

The set_cursor problem reported by MarcinW should be fixed. Please report when you find windows where it doesn't blink.

I couldn't reproduce the problem by DrShark, it seems to be completely unrelated.

[MarcinW]

1) All problems with blinking seem to be fully fixed. Blinking now works even for 4 levels of windows: main window -> configuration window -> plugins / lister plugins / configure -> "Add" button

2) The problem described by DrShark in his last post is in fact completely unrelated. However, I suppose that it can be reproduced by using some drive that responses slowly - like a DVD drive or a network drive with limited bandwidh.

3) The nag screen window has still TApplication as its parent - not the main TC window.

Regards