OK, I should have been more clear. My bad. Sorry about that. Let me try this again, and put it another way, so maybe you can suggest a different perspective.
Added a third parameter to the "WindowOnTop" function.
"Retry" - (Optional) Set to a @False (default) or @True value to indicate whether or not
the function should use the current WIL retry timeout setting when a window
name is provided in the function's first parameter. Set to @True to have the
function use the current timeout setting. Set to @False or omit, to have
the function immediately generate an error when the target window is not found.
The parameter is ignored when the first parameter is a window id.
Note that IntControl 46 can be used to change the current retry timeout setting
(default is 9 seconds.)
Thank you, SnowSnowSnow, for the snippet. While I have tried to figure out what's actually happening in the script, I'm stumped about a few things. For example, based on how substitution supposedly works in WB, according to the Help, I can't see how your use of %param1% doesn't cause the script to crash, as param1 is not a defined variable in the script before its being referred to.No. One of the nifty things about using % substitution is that it doesn't blow up the script if the variable is undefined. That is, it works the same as the same basic construct does in ordinary DOS batch - an undefined variable substitutes as nothing.
For that matter, what does that If branch up top actually do?When the program is invoked with Param1 containing the string "-ontop", it will expect Param2 to contain a partial window name, indicating the name of the window to be "on topped", and will go ahead and "ontop" that window. After doing so, it exits the script.
Then there's your implementation of the RunHide function. How is "-ontop SelectFile" a valid parameter?You can pass whatever you like when you invoke programs. I think the answer you are seeking is that "-ontop" is syntax invented by me; it isn't defined by the WinBatch implementation.
I don't see that verbiage in the Help for the RunHide function.It isn't.
And, since the Help says that IntControl 1004 "Returns the full path and file name of the current WinBatch program", RunHide seems to be calling the same script/.exe from which it's being run, again. ???Correct. The script invokes itself running in a separate process, concurrently with the original process. The secondary process waits for the "SelectFile" window to appear, then "ontops" it. Once it has done so, it exits.
I can't think of a reason for it to need to retry other than to check again for the existence/presence of a window it's looking to place on top.
From MSFT's documentation: "When a non-topmost window is made topmost, its owned windows are also made topmost."
From MSFT's documentation: "When a non-topmost window is made topmost, its owned windows are also made topmost."However, that all said, the wording quoted above is interesting. A lawyer might well argue that it means that while all owned windows extant at the moment of going on-top will also go on-top, it doesn't necessarily guarantee that subsequently created windows (such as our AskFilename() window) will be on-top.
Unlikely, but then again, lawyers have argued (successfully) for the "affluenza defense"...
"Any window (for example, a dialog box) owned by a topmost window is itself made a topmost window, to ensure that all owned windows stay above their owner."I call BS on this. This is simply not true. In a script, put in the IC54, then throw in some BoxOpen statements, then AskDirectory. What will happen is that the WB script will open on top (as is evident by the Box you see), then the Browse For Folder dialog will open BEHIND the WB-generated Box.
"Any window (for example, a dialog box) owned by a topmost window is itself made a topmost window, to ensure that all owned windows stay above their owner."I call BS on this. This is simply not true. In a script, put in the IC54, then throw in some BoxOpen statements, then AskDirectory. What will happen is that the WB script will open on top (as is evident by the Box you see), then the Browse For Folder dialog will open BEHIND the WB-generated Box.
I've never even bothered to check if this happens with WIL Dialogs, but I would guess the same thing happens, and if the WIL dialog is larger than the Browse for Folder window, you're in deep doo-doo, 'cause the user won't even see the Browse For Folder dialog! :o So, when I have to call AskDirectory from a WIL Dialog, I've always made sure NOT to use the IC54, and PRAY LIKE HECK a user doesn't click outside the Browse For Folder window! It may be a small one, but it's a nasty bug I wish would have gotten fixed at some point in the last 22 years. I would have reported it long ago had I known it was a bug, but I didn't, so I didn't. ;)
Any window (for example, a dialog box) owned by a topmost window is itself made a topmost window, to ensure that all owned windows stay above their owner."
thisWin=WinName()
;IntControl(54, thisWin, 1, 0, 0)
WindowOnTop( thisWin, 1 )
The 2nd line has a semi-colon in front of it, which comments out that line. Was that a typo?
Your snippet displayed 54, not 46. Was THAT a typo? ;)The 2nd line has a semi-colon in front of it, which comments out that line. Was that a typo?
No. The IntControl 46 only allows setting the default wait time. So if commented out/or not used defaults to 9 seconds.
Your snippet displayed 54, not 46. Was THAT a typo? ;)
I wasn't referring to what you posted, but what Gibberish posted. He posted some lines of code that included IntControl 54, but then referred to IntControl 46, which was NOT in his original post thus was a bit confusing, so I was trying to get clarification.Your snippet displayed 54, not 46. Was THAT a typo? ;)
Actually my 'snippet' displayed 46, but as a great contributor IFICanByte suggested this is a forum for solving problems, not silly semantics.
I would imagine that the commented ;IntControl(54, OurWnd, 1, 0, 0) was placed in the Tech Database script to assist users with older versions of WinBatch as older versions of WinBatch only have IntControl 54 and not its replacement - the "WindowOnTop" functionI see what you mean. It's basically showing someone how to use WindowOnTop it in place of IntControl 54. Thanks for that clarification.
I also have been frustrated by this problem, and this was the thread that best addressed the problem.Just so you know, this does not work with the Browse For Folder window that's generated by the AskDirectory function, which was why this initial thread was started. Thanks for trying, though! :-)
I noticed something in my own situation: when run directly from Winbatch Studio, the WindowOnTop / IntControl(54) methods worked. But once I ran either the .wbt file outside of WinBatch studio, it no longer worked.
Found this solution, which made it work:
From Article ID: W13250
http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Hiding-Disabling~Apps~to~Prevent~User~Intervention+Cover~the~Screen~to~Keep~Users~Out.txt (http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Hiding-Disabling~Apps~to~Prevent~User~Intervention+Cover~the~Screen~to~Keep~Users~Out.txt)
Place these lines at the top of your script:Code: [Select]thisWin=WinName()
;IntControl(54, thisWin, 1, 0, 0)
WindowOnTop( thisWin, 1 )