Leaderboard

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.

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

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/

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.