Leaderboard

Thought I would update this thread to let everyone know that apparently NI has (recently?) updated their EULA to include the following useful loophole (emphasis mine): You include the following copyright notice "Copyright [insert year] National Instruments Corporation. All Rights Reserved." in the Authorized Application's About Box (if applicable) and in (i) any applicable written documentation or, (ii) if no such documentation exists, in a "read me" or other .txt file distributed with each copy of the Authorized Application; (you may instead, or in addition, include your own copyright notice with the notice(s) required above, but in no event may you remove or alter any copyright, patent, trademark, or other legal notices or disclaimers that exist in the SOFTWARE I have no idea what moved NI Legal to make this change to the EULA, but I think it's a good change! Perhaps NI finally figured out that it wasn't a good idea to have people indiscriminately slapping the NI copyright notice onto the About Box of shoddily-written end-user applications??

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

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.

In computing, a computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete execution. Rules for reentrancy: Reentrant code may not hold any static (or global) non-constant data. Reentrant code may not modify its own code. Reentrant code may not call non-reentrant computer programs or routines. Citaton given. Can we please move on now?

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/

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.

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.