Possible to move window to front without making active?

[Thomas_robertson]

We have a "windows stack manager" vi which accumulates all running vi's and which tier (Z order) they should be.  If a window is made frontmost but is not the highest tier, we move everything else to the front using a Windows API call that makes the window frontmost without automatically activate the window.

Because we are trying to cross compile to x64 and MacOS I need to eliminate this Win32 call.  Doing it with property nodes is not working for me so far.  I now have a situation where the child windows are being made active as well as being moved to the front and thus you can't interact with the parent window.

However, the only relevant things I can find are the FP.Is Frontmost property and the FP.Open method.  Setting the frontmost property seems to automatically active the window.  Calling the open method with the Active input set False does not move the window to the front and setting it to True does bring the window to the front.  So I need some way to control the Z order (make window frontmost) without also activating it.

Any ideas?

[Yupeng_Jia]

Hi Thomas,

Thanks for your question. First you are able to accomplish making a window be in the front most position using property nodes without WIN32 call in the Knowledge Base article Can I Force a SubVI Front Panel To Stay in Front of the Main Front Panel?

You mentioned that "If a window is made frontmost but is not the highest tier, we move everything else to the front using a Windows API call that makes the window frontmost without automatically activate the window". Do you mean without automatically activating the child window or higher tier window?

Also, I'm curious why you might want to have an inactive window in the front. Do you just need to disable some features of that window?

Hope this link helps you. If not, I think it will help us troubleshoot more efficiently if you can post a screen shot of your code here.

[Thomas_robertson]

This article talks about modal windows which are not appropriate for our application, other than that it talks about the frontmost property which also is not appropriate (regularly using that property is not much different than making the window modal).

To understand our need, think of the probe window in LabVIEW.  It's always in front but dosen't block you from interacting with other windows.

We have a 1st tier main application window where the user can type in lot, serial number, initate a test, etc...  We then have any number of 2nd teir windows which are display windows, they show graphs, tabular views, etc...  We then have editor windows which are third-tier and should always be front most but not restrict you from interacting with the main window or 2nd teir windows.

Our current method is whenever the active window changes we pull windows to the front according to their window teir (first the 1st tier, then the 2nd tiers, then the 3rd tiers) however, we do not change the active window.

[Yupeng_Jia]

Hi Thomas, Did you try Floating/Auto-Hide in Front Panel Window: Behavior Property  —   the front panel window is floating and when you switch from LabVIEW to another application, the window does not appear. The procedure is basically the same as that for modal windows in the article above. Since it is a cross-platform application, the pre-developed solutions don’t solve your problem. I would suggest go ahead and try Floating/Auto-Hide. Please let me know if it works for you.

[Thomas_robertson]

Thank you Yuping, we had to go back to the system-dependent way for this version of the software.   For the next version of the software we have a very ambitious hope to create a window object that will allow us to create our different tiers of windows along with a common minimize/restore feature (minimize the main window and they all minimize), a docking feature, a modal option, etc... and use subpannels to attach vi front panels to the window object instances...  So, probably in a few a months time I will get back to you with plenty more questions about this.

[Yupeng_Jia]

sure, please let me know if you need any other help later.

[paul_a_cardinale]

Perhaps something like this.

[Thomas_robertson]

@pcardinale that looks very promising and I will give it a try in a few months.  If it does what it looks like it will do I will come back and accept it as the solution.  Thank you very much!

[Thomas_robertson]

@pcardinale Unfortunately, no, that didn't work.  For one thing, The App.ActiveVI (which doesn't have any documentation), but, it doesn't seem to do what I would expect of it (return the active vis name).  Additionally, setting the active window pulls the window to the front which defeats the whole purpose.

I almost have this working if only I could set a window to be the active window without LabVIEW setting it to the frontmost window.  Does anyone know of a platform independent way to make that happen?  

[paul_a_cardinale]

App.ActiveVI actually does return the name of the active VI.

The 'active VI' is the one with the active window.  Note also that in a windowing environment, the 'active window' is always frontmost.

What are you really mean when you say "active VI"?

Are you trying to get a window to have keyfocus while it's under other windows?