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.
Note that the usual WinBatch behavior - of aborting the script when an attempt is made to reference an undefined variable - is generally good and should be used most of the time. This usage of % substitution, like all uses of % substitution should only be used when you a) Know what you are doing (and why) and b) Have thought through all the implications.
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.
Finally, note that the new feature you alluded to in a later post (about WindowOnTop() now having an additional optional parameter) is not germane to this discussion, except in one small way. That is, the reason I use "WinIdGet()" in the IntControl(54) line is to allow the secondary script to wait (up to 9 seconds) for the SelectFile window to appear. Had I not used WinIdGet(), the secondary script would almost certainly fail as the SelectFile window would not exist at the exact moment in which the secondary script tried to "ontop" it.
This is, in fact, a bug (well, not really a bug, more of an inconsistency) in IntControl(54) (aka, WindowOnTop) that I personally discovered and reported some time back. It is nice that WWW noticed it and has provided a fix. If you like, you can search this forum and find the thread that I started (sometime in the last month or two), that describes the problem and how using WinIdGet() provides a workaround.