Getting the Window Handle for a FP with No Title Bar

[mje]

I've run into a problem where I need to fetch the hWnd of a VI's front panel which has no title bar. Usually I just make a call to User32:FindWindow with a null class and the title bar string, but it seems if the title bar doesn't exist, FindWindow can't do it's job.

I might be able to make the title bar visible, do the FindWindow call, then re-hide it, but I'm looking for something more elegant which won't introduce flicker, etc.

Anyone have any ideas?

[Jarrod S]

I've run into a problem where I need to fetch the hWnd of a VI's front panel which has no title bar. Usually I just make a call to User32:FindWindow with a null class and the title bar string, but it seems if the title bar doesn't exist, FindWindow can't do it's job.

I might be able to make the title bar visible, do the FindWindow call, then re-hide it, but I'm looking for something more elegant which won't introduce flicker, etc.

Anyone have any ideas?

There is a VI property to get the window handle. I think it's one of the super secret hidden property nodes. Not sure if scripting support turns it on.

On a side note, beware of getting an hWnd by FP title! Danger lurks! We had a huge bug in Vista that all boiled down to this. The problem is that in Vista the little Aero preview windows that pop up when you hover your mouse over a TaskBar item have the same window title as the window they're previewing. This makes it possible to accidentally get an hWnd for the preview window for your VI instead of your VI itself if you call FindWindow when the preview is active. Nasty little bug took us forever to find. Win7 does not seem to have this issue. Stick with the property node.

[mje]

Thanks, Jarrod! I'll do some property node hunting and see what I come up with. I don't currently have scripting turned on, so hopefully this method will end up working in the RTE...

If you track it down before me, please do post (if you can make that info public).

Nice bug too, sounds like an odd one to track down!

[Francois Normandin]

[JackDunaway]

It appears OS Window is deprecated - you may want to try Native Window. It outputs 64 bit handle rather than 32-bit, and the results seem to be equal (run this snippet):

[mje]

Interesting...thanks gang. Hopefully the returned U64 will always return a valid 32bit handle when working with the Win32 calls. Maybe I'll mask off the high words and return an error if they're ever non-zero.

Further investigation seems to imply that my inability to find my hWnd using Win32 might also be related to the VI FP being a floating window, not only the lack of a title bar? Who knows, all I can say is FindWindow returns a null handle, but both of those properties work.

[hooovahh]

So one thing that is worth mentioning that I noticed about these undocumented functions is that the "NativeWindow" method does not work for remote application instances, but the deprecated method "OS Window" does.

[Rolf Kalbermatter]

So one thing that is worth mentioning that I noticed about these undocumented functions is that the "NativeWindow" method does not work for remote application instances, but the deprecated method "OS Window" does.

 

Hmm, for some reasons it would seem rather strange to support the retrieval of HWND across machines. The HWND really only has any meaning on the system it was created. And if you use the OS Window you are setting yourself up for big troubles once you move to LabVIEW for Windows 64 bit.

 

I suppose you are doing some remote work where you retrieve the handle and pass it back to another function or whatever on the same remote system. The proper way to do such things would be to have the actual handle twiddling all done on the target machine and expose that VI doing this, over the VI server to your other machine(s).

[Mr Mike]

Thanks, Jarrod! I'll do some property node hunting and see what I come up with. I don't currently have scripting turned on, so hopefully this method will end up working in the RTE...

Both FrontPanelWindow:OSWindow and FP.NativeWindow are in the Run Time Engine.  They are not in RT (Real Time).

 

- Mike

[hooovahh]

Hmm, for some reasons it would seem rather strange to support the retrieval of HWND across machines. The HWND really only has any meaning on the system it was created. And if you use the OS Window you are setting yourself up for big troubles once you move to LabVIEW for Windows 64 bit.

 

I suppose you are doing some remote work where you retrieve the handle and pass it back to another function or whatever on the same remote system. The proper way to do such things would be to have the actual handle twiddling all done on the target machine and expose that VI doing this, over the VI server to your other machine(s).

I may not have used the right words but what I meant is "NativeWindow" does not work with an application instance that was opened explicitly.  It is just like the "All VIs in Memory" property.  It will work if you don't wire anything to the reference in terminal.  But if you open a new application instance the "NativeWindow" will not work but "OS Window" will.

 

This may be better answered in a different thread, but is there a list of private methods/properties that are more stable than others?  What I'm trying to ask is if I use either of these two methods what risk is there?  Knowing these are unsupported functions.  I found the wiki here, but was quite disappointed to find it so empty.  I planned on using a few others like "All Context", and "Is Context Private?" (to get a list of non-private Contexts), and was wondering the risk of these as well.

[Rolf Kalbermatter]

I may not have used the right words but what I meant is "NativeWindow" does not work with an application instance that was opened explicitly.  It is just like the "All VIs in Memory" property.  It will work if you don't wire anything to the reference in terminal.  But if you open a new application instance the "NativeWindow" will not work but "OS Window" will.

 

This may be better answered in a different thread, but is there a list of private methods/properties that are more stable than others?  What I'm trying to ask is if I use either of these two methods what risk is there?  Knowing these are unsupported functions.  I found the wiki here, but was quite disappointed to find it so empty.  I planned on using a few others like "All Context", and "Is Context Private?" (to get a list of non-private Contexts), and was wondering the risk of these as well.

 

I'm afraid such a list will stay a wet dream. Officially those private properties and methods don't exist and NI people are not supposed to comment on them, but they are the only ones who could really make some educated comments. For me it is just an educated guess.

 

While I think the safety of these two properties is fairly well, as far as rusty nails and other painful accidents are concerned, they were probably made secret since the LabVIEW developers did not want to carve the association between a panel and an OS window in stone. Also as we have seen the move to 64 bit has posed a challenge. Changing the existing property to a different datasize is not really an option as that could lead to very hard to debug bugs, when the truncated value is passed around as a 32 bit entity and eventually interpreted as a handle again, which might be accidentally pointing to an entirely different but still valid object. So in a way not having exposed that property they could easily change it without having to go through 200 documentation change requests at the same time.

[hooovahh]

I'm afraid such a list will stay a wet dream. Officially those private properties and methods don't exist and NI people are not supposed to comment on them, but they are the only ones who could really make some educated comments. For me it is just an educated guess.

 

While I think the safety of these two properties is fairly well, as far as rusty nails and other painful accidents are concerned, they were probably made secret since the LabVIEW developers did not want to carve the association between a panel and an OS window in stone. Also as we have seen the move to 64 bit has posed a challenge. Changing the existing property to a different datasize is not really an option as that could lead to very hard to debug bugs, when the truncated value is passed around as a 32 bit entity and eventually interpreted as a handle again, which might be accidentally pointing to an entirely different but still valid object. So in a way not having exposed that property they could easily change it without having to go through 200 documentation change requests at the same time.

I understand why they are private, I was just wondering if in a specific use case if there was any danger in using it.  Say if I'm in a 32-bit Windows environment would there ever be a case where using "OS Window" would cause bad things to happen?  I have very similar questions for a few other private methods too, and was hoping for some unofficial documentation is all.

[Stobber]

DND isn't working with these snippets. Can anybody provide a VI (LV 2012 here) that calls the nodes?

[Darren]

Sure, here you go. Saved in LabVIEW 2012.

OS Window and Native Window properties.vi