Leaderboard

After digging around some more I found more hidden INI keys. Again, use these at your own risk. whileLoopSharedCloneOptions=True - adds an additional context menu option to the While loop; not sure what the different options do GenericsAreGo=True - enables the creation of generic VI's (danger!) by right-clicking a control or indicator and selecting "Generic" ActiveXMoreContainerOptions=True - Adds "Persist State To Edit Mode" and "Destroy And Recreate When Run" to the Advanced submenu of an ActiveX container AdvancedPlotLegendMenu=True - Adds a whole bunch of additional options to the context menu for a plot legend EnableStrictTypedefConstantConfiguration=True - Adds a new context menu item to constants based on strict typedefs called Act as Strict Typedef Constant. Function unknown. enableSecretPopups=True - Adds additional context menu items to custom control parts that configure how they scale with the control. Apparently some other hidden menu items are added somewhere too. (Thanks, hooovahh and Christina Rogers!) showRunAtAnyLoopMenuItem=True - Adds a new menu item to Property and Invoke nodes labeled "Run At Any Loop". When selected, the node turns brown as if a private property or method was selected, even if none are. Function unknown. ShowWireAddressMode=True - Adds some additional memory-related information to the context help window when you hover over a wire. Also adds a context menu item to wires called Select InPlace Signals, which likely selects wires that share a memory address. Seems like it could actually be pretty useful for optimization! SimShowCompanionDiag=True - Adds a context menu option to the Simulation structure called "Show Companion Diagram", which toggles showing what looks like a "behind-the-scenes" block diagram for the simulation. NEW! ShowHiddenLibraryItems=True - Shows hidden library items. (big surprise there!) So far I've only seen changes when editing a statechart library, but it seems most of the items in a statechart library are hidden, so it reveals a lot. There's also some more whose functions I'm not sure of (but look interesting) such as TotallySecretAndPrivateMSNCompanionDiagram, and growSubVI.enabled (might be pretty mundane, but it's false by default and might have something to do with creating subVI's that can grow like XNodes.) If I find any more interesting ones I'll post them here, but here's a list of every INI key loaded when LabVIEW starts, obtained by hooking the internal function that reads them: http://pastebin.com/j1iAEZXg. See here for information on finding the rest. In the meantime, if anyone knows what any of these do, please post!

EDIT: Alright never mind I just made the XNode from scratch. It supports LabVIEW 2011+. It supports breaking the wire if the input is not a cluster, it does clusters in clusters, it has the type adaption on the output, and the icon changes color, based on the color of the cluster wired into it. I also built an EXE using it just to make sure that worked and it does. All source is included with no passwords. To see how it works just open the XNode Template.vi. It will basically just set the cluster size and change the terminal types to what was wired. Array Of Variant To Cluster XNode.zip

Oh boy are you in luck. So I have tucked away some code I made a while ago for reading parts of the VI file structure. It needs some polish and more features but here is the basics of it. Open the attachment with OpenG installed, I think it uses the File and MD5 packages. Then open the Example Read VI Data. It will read in things like description, icon, version, VI title, bookmarks and a few other things from the file on disk. Yes it did have the ability to overwrite passwords but I removed that for this post. Also I'd like to mention that the VI Explorer is just crap. The way it is written it is obvious the author comes from a text based language. Looking at his PHP source shows how good he is at text programming. That is mostly what these VIs are, is the reverse of his PHP source. Oh and by the way I don't know if you have visited his site lately but he has updated source that reads front panel and block diagram objects. This is done by reading the BDHX and FPHX sections, then uncompressing them. As for editing the VI..yeah not so much sorry. I assume there are tons of hashes and checksums to look for file corruption. VI File Structure.zip

Now the question is whether there's any practical use for such a data type?

Part of the fun was figuring out that while multidimensional arrays and nested queues have caps at how thick the wires are drawn, they weren't programmed to detect each other. I.E. while a 4D array has a thicker wire than a 3D array, a 5D array wire isn't any thicker than a 4D array wire. Same with queues of queues of queues of queues. But once it's determined the thickness to give the wire based on the dimensionality of the array, it doesn't take that into account when determining the base thickness of the wire, as determined by the data type the array contains. And that data type may be a quadruple-nested queue, which has a similar means of determining thickness. And what if the data type contained in the queue is another 4D array? It's not programmed to deal with that kind of recursion as far as limiting the width of wires goes, so there doesn't seem to be any limit to how thick it can get. In other words, I wasn't trying to point out how data types can be nested really far; I was just pointing out how LabVIEW wasn't programmed with that particular kind of combination in mind, so the wires can get infinitely thick. So thick, in fact, that it causes glitches where not enough of the screen is redrawn in certain cases because it doesn't expect the wire to go beyond a certain space.

Did you mean to add "penalty" or something there? Also, I decided to give this a try myself. Here's an XNode I made that's basically the type cast function, only it implements the behavior described in the thread. (I actually got the idea to do this in an XNode before I noticed hooovahh's post; maybe he hadn't posted it yet.) A couple warnings though: one, I haven't tested it that much, and two, it uses a private method in the GenerateCode ability to create a constant of a given type. No idea why this method is private; I don't see any problems using it can cause, but I'm warning you because I imagine it's marked private for a reason. Also, if you right-click it, there's an option to replace it with a regular typecast node along with a constant of the proper type. Auto Typecast.zip

Thanks! I thought that one might have had its functionality removed, since "MathScriptFastPropTypes" is mapped to the same memory address, which is kind of strange. I'll add it to the list at the top. Do you happen to know off hand what other menu items it enables? Oh, another thing: that PDF you linked to mention some new decorations that aren't in the palette. If they're not in the palette, how do you place them? (I also know there are other decorations that aren't in the palette, that I've found by manually editing the image ID of an object in memory (thanks, whoever made Heap Peek show memory addresses); is there a special palette with all the images hidden somewhere?) I think there's actually more that just aren't loaded until they're needed. But there is a way to monitor every config token LabVIEW looks for. Download and install Cheat Engine (pay attention when installing it, as it may ask you to install "sponsored" stuff as well; CE itself is open-source and safe to use though.) Run the program and click the Memory View button without targeting any process. In the new window that appears, press Ctrl+L, or go to Tools->Lua Engine. In the box at the bottom of that window, paste in the following script, making sure to enter the path to LabVIEW.exe in the marked area, replacing every \ with \\: LVEXEPath = "PUT PATH HERE" createProcess(LVEXEPath, "", true) CfgGetDefault = getAddress("LabVIEW.CfgGetDefault") debug_setBreakpoint(CfgGetDefault) function debugger_onBreakpoint() if EIP == CfgGetDefault then local a, b, c, d = readBytes(ESP+4, 4, false) local size = readBytes(readInteger(ESP+8), 1, false) local str = readString(readInteger(ESP+8) + 1, size) local addr = readInteger(ESP+12) print(string.format("%s (0x%X) [%c%c%c%c]", str, addr, a, b, c, d)) end debug_continueFromBreakpoint(co_run) return 1 end Finally, make sure LabVIEW is not running, and press Execute. LabVIEW will open, and Cheat Engine will list every INI token as LabVIEW looks for them. This is how I found the tokens I mentioned in the post at the beginning.

While I agree 100% with this, I'm still on the fence. If there's a 'type' input, my personal preference is to be explicit and wire it up. But, then again, the fewer replacements I have to make if I change types later, the better. When it comes to remembering to modify the data originator, a broken run arrow in the receiver won't help my brain synapses work any better unfortunately. So, rather than vote bug or no-bug, I'd rather just push for consistency; Either give me the "magic" everywhere, or none at all. The inconsistency can definitely be cause for confusion: