How do you make your application window frontmost?

[ThomasGutzler]

For me I use code similar to this.  It gets the HWND using a VI reference instead of window title.  This is more robust for things that maybe in subpanels, or hidden but in most cases the get HWND from window title you posted should work.  Where we differ more is on the make window top. The VI I have for set Z order comes from code posted here.  I've used this technique in built EXEs without a problem.

 

EDIT: OpenG error, and Application Control is required.

 

I'm afraid, this also crashes my app when I build it - and it doesn't bring the window to front. Something's seriously effed up here.

 

So, I've made a vi that waits for three seconds and then brings itself to front (it doesn't come to front on my PC). I also built an exe from it, which crashes immediately (not after 3s). All attached in LV 2013 and 2012: ToFront.zip

 

Could someone try this out so that I know if it's a problem with my build or my PC?

[Rolf Kalbermatter]

The first thing you should do is to change the library path in the Call Library Node to only explicitedly say USER32.DLL. You have currently a path in there and not just a name, and in that case the LabVIEW application Builder believes that the DLL is private to the app and adds it automatically to the data folder in your app. LabVIEW then will try to load that private DLL and call its function but the handle you do pass it comes from USER32.DLL in the system folder and has absolutely no meaning inside the private copy of USER32.DLL and therefore crashes.

 

The problem is in fact already happening when LabVIEW tries to load its local copy of USER32.DLL. This DLL interacts on many levels with other Windows kernel internas and tries to do all kinds of stuff to initialize the Windows API system. However that conflicts with the initialization the system DLL has made when it was loaded at computer startup and therefore Windows simply shutdowns the process.

 

After you rebuilt your app, make sure you don't end up with a user32.dll file inside your built application directory anymore. This should fix the crash in the built app.

 

Another change you should do is to make the HWND control an U64 control, remove the U32 conversion in Get HWnd From VI Ref.vi, and change the according parameter in the Call Library Node to be a pointer sized integer. Otherwise you will run into nasty stuff again when you ever move your application to LabVIEW for Windows 64 bit.

[ThomasGutzler]

Interesting, hooovahh must have done that in his version but when I loaded it, I got the warning dialog that the dependencies had changed. I thought it was just fixing the OpenG path and ignored the warning. Doh.

 

Now I just have to work out why it doesn't actually bring the window to front. I thought it may have something to do with my desktop manager as discussed here but turning it off doesn't make a difference. Strangely, my own BringToFront.vi doesn't work anymore either.

 

Does this (exe or Main.vi) come to front for anyone? ToFront.zip

EDIT: Unfortunately, I can only build in 2013 at the moment so I haven't included 2012 code either

Edited May 3, 2014 by ThomasGutzler

[ShaunR]

Interesting, hooovahh must have done that in his version but when I loaded it, I got the warning dialog that the dependencies had changed. I thought it was just fixing the OpenG path and ignored the warning. Doh.

 

Now I just have to work out why it doesn't actually bring the window to front. I thought it may have something to do with my desktop manager as discussed here but turning it off doesn't make a difference. Strangely, my own BringToFront.vi doesn't work anymore either.

 

Does this (exe or Main.vi) come to front for anyone? ToFront.zip

EDIT: Unfortunately, I can only build in 2013 at the moment so I haven't included 2012 code either

Put the 3 sec delay after you set to top

[hooovahh]

Another change you should do is to make the HWND control an U64 control, remove the U32 conversion in Get HWnd From VI Ref.vi, and change the according parameter in the Call Library Node to be a pointer sized integer. Otherwise you will run into nasty stuff again when you ever move your application to LabVIEW for Windows 64 bit.

Thanks for the tip.  I understand the edge case and so far my applications that have been built haven't seen any strangeness but I will make that change for future applications.  I think the reason I stuck with U32 was because the WIN API I linked to earlier used U32 for all the HWND values but that was developed before a 64 bit Windows.

 

@ThomasGutzler the VI you posted ran and worked as expected without error or crash.  The EXE ran without crash or error, but it didn't actually bring it to the front.

 

EDIT:  A quick search resulted in someone over on Stack Overflow saying that even in 64 bit Windows, only the lower 32 bits of a HWND are used.  The internet has been wrong before.

[Rolf Kalbermatter]

EDIT:  A quick search resulted in someone over on Stack Overflow saying that even in 64 bit Windows, only the lower 32 bits of a HWND are used.  The internet has been wrong before.

 

That's currently mostly true due to most Win64 machines still using not more than 4GB memory per process normally. But going to rely on this will surely go and bite you in a few years when your 100GB machine is starting to crunch on 5000* 2500 pixel images in 32 bit color mode. 

 

Microsoft didn't define a handle to be pointer sized for no reasons. Internally most handles are pointers.

[Bean]

Updated VIs to obtain hwnd by FP.NativeWindow as suggested above.  Saved in LV 2013 SP1.  Only tested with Windows 7 64-bit and LV2013 SP1 32-bit.

Set Calling VI Wnd Top & Active.vi

Set Calling VI Wnd Topmost & Active.vi

Cancel Calling VI Wnd Topmost.vi

[guentermueller]

Nice work, Bean.  Can I use this code in a commercial application?

I see a copyright note in the VI Documentation.  Is the code covered by a specific license?

[yile]

Looks like Bean's vi doesn't work for LabVIEW2016. Anybody has solutions? 

Many thanks!

[hooovahh]

Works fine for me.  I tried the set Top & Active in Windows 7 x64, LabVIEW 2016 32-bit.  I had a wait which allowed me enough time to put other windows (non-LabVIEW ones) on top then waited and it was brought to the front most of all windows.

[Mopar_Elwood]

I know this is an old thread but figured I would chime in and see.  These work for me fine on windows 7 service pack 1 and Labview 17.02f. I does not work for me with Windows 10. As far as I can tell the SeWidnowPos function in Bean's VI should work fine for windows. At least everything matches what I find on the msdn. I have tired most if not all the solutions here and used some other VI's even the old WINUTIL.llb. I can get them to work in windows 7 but not 10. Anyone have some ideas? Anyone else have the windows 10 failure.  

Thanks.

[Rolf Kalbermatter]

If you happen to use these VIs in LabVIEW 64 bit you will certainly have to review them and make sure that all Windows handle datatypes such as the HWND used in those functions are configured to be pointer sized integers rather than 32 bit integers (and change the according LabVIEW controls to be of type 64 bit integer).

[Mopar_Elwood]

Thanks for the suggestions. I think I got them all changed but I will go back and check and report back.

[GWiking]

Old thread, I know  

But I have to say that You rock Bean!

Thank You! 

[Darren]

FYI to anyone using Bean's VIs. I was successfully using them in an application, but they had a peculiar side effect. Whenever another application on the system (G-Force) was in full-screen mode, the LabVIEW application windows were non-responsive to mouse clicks. If I switched G-Force out of full-screen mode, the LabVIEW windows started behaving properly again.

It took me a while, but I figured out that in order to fix the issue, I needed to add another call to 'AttachThreadInput' at the end of Bean's code IF AttachThreadInput had been called earlier. In Bean's code, the 'fAttach' parameter is set to '1' to attach the thread. If you do this, you then need to call AttachThreadInput again at the end of the code, but with an 'fAttach' value of '0' to detach the thread. When I made this change, my application remained responsive to mouse clicks even when G-Force was in full-screen mode.

[Bean]

Thanks GWiking and nice work Darren!

-Jason Benfer

[CT2DAC]

Bean's VI's still rockin........ 🤩

Thanks Bean, saved my day!