Private Methods That Should Be Public

[hooovahh]

So today I found another method that in my opinion should be made public.  Obviously NI has more information than us, and maybe they have a good reason to not make them public, like they crash LabVIEW if you do XYZ.  But here is a couple I've found and thought were odd that they were still private.  These are functions that from what I see work just fine, and have little danger to a developer using it.  Please add others you find.

 

Class:VI

Property: FP.Native Window

This returns the HWnd in Windows to the front panel window, which can be used for low level window manipulation.  Many functions for window manipulation are in VI Server but not all of them which is why on occasion the HWnd is needed.

 

Class: Ring

Property: Flavor

This returns the type of Ring a reference is.  Text Ring, Picture Ring, or Text and Picture.

 

Class: VI

Method: Synch In All Contexts

I'm not sure this actually works, but it looks like it should sync a VI to all contexts.  Maybe this isn't needed because a Save Instrument also syncs but some times you may not want to save the VI.

 

Class: Control

Property: Grouped / Group Member Refs

This returns if a control is part of a group and the other references in the group

[mje]

Yeah, the NativeWindow property is just so damn useful. Can't say I've used the others.

[Shaun Hayward]

+1 for NativeWindow - that property is a godsend!

[JKSH]

Class:VI

Property: FP.Native Window

This returns the HWnd in Windows to the front panel window, which can be used for low level window manipulation.  Many functions for window manipulation are in VI Server but not all of them which is why on occasion the HWnd is needed.

Yeah, the NativeWindow property is just so damn useful. Can't say I've used the others.

+1 for NativeWindow - that property is a godsend!

 

I'm interested in the topic of manipulating HWNDs directly. Could you guys kindly list some example use cases?

[ShaunR]

Could you guys kindly list some example use cases?

 

Pretty much everything in this Toolkit

 

I don't know how they will implement it on Mac and Linux, although similar capabilities would be nice.

Edited June 11, 2015 by ShaunR

[ensegre]

Pretty much everything in this Toolkit

I get 403 Forbidden error....

[ShaunR]

I get 403 Forbidden error....

Unfortunate. Proxy?

 

It's the MDI Toolkit for LabVIEW but with bigger pictures and datasheets.

Edited June 11, 2015 by ShaunR

[ensegre]

Unfortunate. Proxy?

Also http://www.lvs-tools.co.uk/ for me, no pb with other sites. If it's only me, let it be proxy.

[ShaunR]

Also http://www.lvs-tools.co.uk/ for me, no pb with other sites. If it's only me, let it be proxy.

Well. You, malicious bots, hackers and Viagra spammers

 

PM me your IP address and I'll remove the block.

[Rolf Kalbermatter]

Pretty much everything in this Toolkit

 

I don't know how they will implement it on Mac and Linux, although similar capabilities would be nice.

 

Good luck with that!

 

On Linux the native handle is supposedly the XWindows Window datatype.

 

On Mac I would guess (don't have looked at it but entirely based on assumptions) that for the 32 Bit version it is the Carbon WindowPtr and for 64 Bit version it is an NSWindow pointer (and yes this seems to require Objective C, there doesn't seem to be a CoreFoundation C API to this for 64 Bit).

 

So, you have at least 4 ENTIRELY different datatypes for the native window handle, with according ENTIRELY different APIs to deal with! 

 

And no, the Call Library Node function can not access Objective C APIs, for the same reason it can't access C++ APIs. There is no publically accepted standard for the ABI of OOP compiled object code. I guess the Objective C interface could be sort of regarded as standard on the Mac at least, since anyone doing it otherwise than what the included GNU C toolchain in X code does is going to outcast himself. For C++ there exists unfortunately not such an inofficial standard.

[ShaunR]

Good luck with that!

 

On Linux the native handle is supposedly the XWindows Window datatype.

 

On Mac I would guess (don't have looked at it but entirely based on assumptions) that for the 32 Bit version it is the Carbon WindowPtr and for 64 Bit version it is an NSWindow pointer (and yes this seems to require Objective C, there doesn't seem to be a CoreFoundation C API to this for 64 Bit).

 

So, you have at least 4 ENTIRELY different datatypes for the native window handle, with according ENTIRELY different APIs to deal with! 

 

And no, the Call Library Node function can not access Objective C APIs, for the same reason it can't access C++ APIs. There is no publically accepted standard for the ABI of OOP compiled object code. I guess the Objective C interface could be sort of regarded as standard on the Mac at least, since anyone doing it otherwise than what the included GNU C toolchain in X code does is going to outcast himself. For C++ there exists unfortunately not such an inofficial standard.

 

I know. I reckon it's probably the reason that that function is, and always will be, private Doesn't hurt to sow the seed of the thought though-engineers love a challenge 

 

I've just been through a lot of this platform rationalisation with a replacement for the NI licencing system since I need one that works on all the platforms, not just Windoze. I was lucky enough to not have to link in to weird and wonderful static libraries, though. I think I could probably hack together a DLL that could get x windows forms and probably whatever the equivalent is,on Mac; if push came to shove. I'd rather NI did it properly though.

Edited June 11, 2015 by ShaunR

[Rolf Kalbermatter]

I've just been through a lot of this platform rationalisation with a replacement for the NI licencing system since I need one that works on all the platforms, not just Windoze. I was lucky enough to not have to link in to weird and wonderful static libraries, though. I think I could probably hack together a DLL that could get x windows forms and probably whatever the equivalent on Mac is, if push came to shove. I'd rather NI did it properly though.

 

Ahh licensing! Well, I'm also in the last stage of finalizing a license solution for all LabVIEW platforms. Yes, including all possible NI RT targets!

[hooovahh]

On 6/11/2015 at 12:42 AM, JKSH said:

I'm interested in the topic of manipulating HWNDs directly. Could you guys kindly list some example use cases?

Oh also fun with parent children relationships.

 

http://screencast.com/t/LjlkYzTWKr8J

https://www.youtube.com/watch?v=-i3iaWm_Jiw

http://screencast.com/t/P9SJ1anR

https://www.youtube.com/watch?v=bqNVbSn7nKg

 

http://forums.ni.com/t5/LabVIEW/How-to-run-an-exe-as-a-window-inside-a-VI/m-p/3113729#M893102

https://lavag.org/topic/17046-multi-panel-interface/

[JKSH]

Thanks, all!

 

So in a nutshell, HWND manipulation can give us advanced, dynamic GUI behaviours that Front Panels, Subpanels, and XControls can't do natively.

 

 

So, you have at least 4 ENTIRELY different datatypes for the native window handle, with according ENTIRELY different APIs to deal with! 

 

And no, the Call Library Node function can not access Objective C APIs, for the same reason it can't access C++ APIs. There is no publically accepted standard for the ABI of OOP compiled object code. I guess the Objective C interface could be sort of regarded as standard on the Mac at least, since anyone doing it otherwise than what the included GNU C toolchain in X code does is going to outcast himself. For C++ there exists unfortunately not such an inofficial standard.

 

A cross-platform framework (like LabVIEW, or a LabVIEW toolkit) would typically present a unified platform-agnostic API to users, while calling these platform-specific APIs under the hood. (Conditional disable symbols, probably?)

 

Anyway, one could create a wrapper C library for Objective C and C++ libraries (I know that C++ has extern "C" {}, not sure about Obj-C). Then, LabVIEW could call this C wrapper.

Edited June 16, 2015 by JKSH

[Rolf Kalbermatter]

Thanks, all!

 

So in a nutshell, HWND manipulation can give us advanced, dynamic GUI behaviours that Front Panels, Subpanels, and XControls can't do natively.

 

 

 

A cross-platform framework (like LabVIEW, or a LabVIEW toolkit) would typically present a unified platform-agnostic API to users, while calling these platform-specific APIs under the hood. (Conditional disable symbols, probably?)

 

Anyway, one could create a wrapper C library for Objective C and C++ libraries (I know that C++ has extern "C" {}, not sure about Obj-C). Then, LabVIEW could call this C wrapper.

 

And that is exactly what LabVIEW does. It's Window manager component is a somewhat hairy code piece dealing with the very platform specific issues and trying to merge highly diverging paradigmas into one common interface. It makes part of that functionality available through VI server, and a little more through an undocumented C interface which lacks a few fundamental accessors to make it useful for use outside of LabVIEWs internal needs.

 

 

Anyway, one could create a wrapper C library for Objective C and C++ libraries (I know that C++ has extern "C" {}, not sure about Obj-C). Then, LabVIEW could call this C wrapper.

 

 

Yes "one" could! And what you describe is mostly how it would need to be done. But are you volunteering? 

 

Be prepared to deal with highly diverging paradigmas of what a window means on the different platforms and how it is managed by the OS and/or your application! And many hours of solitude in an ivory tower with lots of coffeine, torn out hairs and swearing when dealing with threading issues like the LabVIEW root loop and other platform specific limitations. 

 

I don't see the benefit of that exercise and won't go there! What for? For MDI applications? Sorry but I find MDI one of the worst implementation choices for almost every application out there.

[JKSH]

Yes "one" could! And what you describe is mostly how it would need to be done. But are you volunteering? 

 

Good call

 

No, I'm not volunteering to create LabVIEW wrappers for native window management APIs. That would be rather silly, as you said. I'm taking a different approach: Investigating how a 3rd-party GUI toolkit could be integrated into a LabVIEW application.

 

That's why I asked my original question -- to see what use cases need "unconventional" features in LabVIEW, and to see if a 3rd-party toolkit can satisfy those use cases.

[hooovahh]

I don't see the benefit of that exercise and won't go there! What for? For MDI applications? Sorry but I find MDI one of the worst implementation choices for almost every application out there.

I'm interested less in making MDI applications, and more in knowing that NI has provided the tools, to make any application my imagination can come up with.  Put another way, I'd like to have the ability to take any existing program, on any platform, and be able to recreate it's UX.  I want users to use my program and not know it was written with LabVIEW.  Exposing the HWND, or providing wrappers to similar cross functional APIs is one step towards that.  And to be fair the window management properties in VI Server is a decent step in the right direction.

[Rolf Kalbermatter]

I'm interested less in making MDI applications, and more in knowing that NI has provided the tools, to make any application my imagination can come up with.  Put another way, I'd like to have the ability to take any existing program, on any platform, and be able to recreate it's UX.  I want users to use my program and not know it was written with LabVIEW.  Exposing the HWND, or providing wrappers to similar cross functional APIs is one step towards that.  And to be fair the window management properties in VI Server is a decent step in the right direction.

 

I understand your concerns, but reality is that any multiplattform widget library (be it wxWidget, QT, Java, LabVIEW or whatever else you can come up with) is always going to be limited with whatever is the least common denominator for all supported platforms. Anything that doesn't exist on even one single platform natively has to be either left away or simulated in usually very involved and complicated ways, that make the code difficult to understand and maintain. And the LabVIEW window manager does contain quite a few such hacks to make things like subwindows, Z ordering, menus and common message handling at least somewhat uniform to the upper layers of LabVIEW. Hacky enough at least to make opening the low level APIs to this manager to other users a pretty nasty business.

 

I'm sure there are other marketing driven reasons too, that Apple didn't include a cfWindow interface to NSWindow into its CoreFoundation libraries, but even if they did, they certainly wouldn't have tried to map that to the WinAPI as they did with most other CoreFoundation libraries.