Jump to content
Michael Aivaliotis

How do you make your application window frontmost?

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by ThomasGutzler

Share this post


Link to post
Share on other sites
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? attachicon.gifToFront.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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.  :D

 

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

Share this post


Link to post
Share on other sites

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

Many thanks!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.