Re^5: Win32::GUI: how to find BrowseForFolder()'s handle?

First some notes SSCCE (its like noise )

Here is a complete (compileable and running) code example.

Thanks. I see what you're talking about now. You can fix this by removing

  
    -addexstyle  => WS_EX_TOPMOST,
[download]

from $window/Main Window

That may or may not be what you want, but its a fix ;D

2. How does one find the desktop windows handles? If we could find BrowseForFolder()'s handle, we could raise it to the foreground (how?)

Would you look at that # -owner => WINDOW

Yup, specifying -owner => $Window, does the trick (it works), no WS_EX_TOPMOST required

Comment on Re^5: Win32::GUI: how to find BrowseForFolder()'s handle? Select or Download Code

Replies are listed 'Best First'.
Re^6: Win32::GUI: how to find BrowseForFolder()'s handle? by HelenCr (Monk) on Sep 22, 2012 at 11:52 UTC
Thank you. That was instructive, and it actually solves the issue. (SSCCE and UTSL are instructive too - learned something new). A follow-up question: the role of the "-owner" option is not clear to me. Why and when is it necessary, and why does it fix the problem? TIA Helen	[reply]
Re^7: Win32::GUI: how to find BrowseForFolder()'s handle? by Anonymous Monk on Sep 22, 2012 at 23:33 UTC
A follow-up question: the role of the "-owner" option is not clear to me. Why and when is it necessary, and why does it fix the problem? It is necessary whenever you're using the functional interface If you had used $Window->BrowseForFolder() it would have happened automagically It lets the windowing system/ window manager, decide correctly to allow children of parent to display on top of parent , in effect it propagates the WS_EX_TOPMOST flag to the children	[reply]