Sparkette

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.

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!

Okay, bumping an old thread here. For anyone who's still interested, I've discovered with almost complete certainty what Darren meant by "a certain way we can configure the UI to make controls generic." Simply add the following line to LabVIEW.ini: GenericsAreGo=TrueNow every control will have a "Generic" context menu item that does what you'd expect. I'll post this on the LabVIEW wiki as well.

Why is it posted in OpenG? (Also, if any moderators see this, please don't remove this thread. Lock it at most.)

Where can I find more information about this DLL feature?

Okay, I think I figured something out. The first eight bytes are 32-bit integers. I'm pretty sure the first corresponds to the number of "parts" the model has, but the second I'm unsure of. After that are coordinates of points as single-precision (32-bit) floats, in the order X, Y, Z, X, Y, Z, …. The aforementioned "parts" mentioned before are separated by "FF FF FF FF". As for what determines which points are connected to which, I'm not sure. That would likely use integer values, but there aren't any non-float values other than those two integers at the beginning and the FFFFFFFF that separates each part. I don't think the order in which the points are listed affects it. However, the apparent lack of any information related to which vertices are connected made the term "point cloud" come to mind. And then I realized: perhaps that's what PTC stands for. One more thing: it seems the models' filenames are hard-coded into LabVIEW.exe. Which means it wouldn't be surprising if it can't load model files that it's not already programmed to load. However, I did find this humorous string, presumably used for debugging: "This model doesn't know how to see it's [sic] shadow. Two more weeks of winter." But seriously, LabVIEW's support for custom control graphics is just terrible. It's almost a joke: the only supported formats in which you can load in images (as opposed to only being able to use specific hard-coded images built in to LabVIEW) are all non-scalable raster formats. There is one exception, but that exception is Windows metafiles, and that format just sucks. And if they're going to program in 3D support, why not enable importing of models as well? EDIT: Apparently it also supports PICT images, which also support vector graphics. But that's yet another obsolete format that nobody uses. And some format with a ".aaa" extension, which I know nothing about. I only suspect that because ".pct" and ".aaa" are found as strings near ".wmf" in LabVIEW.exe.

Uh oh, looks like somebody's using a private method in production code. In all seriousness, that one seems innocent enough, but the truth is you never know; it's probably marked private for a reason.

So have I! It's addicting!

Oops! My mistake. I had hacked the Boolean constants so the true one says F, and the false one says T, but I guess that didn't save in the VI snippet. Never mind! I'll still mark yours as the solution though. EDIT: This works though!

To clarify, this isn't me asking for help. It's a challenge of sorts, to see if anyone can figure out what I did. EDIT: The trick I used apparently didn't save to the VI snippet. Never mind!

I just wrote this VI to accomplish a task that's come up quite often: rescaling a value from one range to another. There may be a VI for this built-in, but I wasn't able to find it. Convert Range.vi

I noticed that some of the controls actually use 3D models. For instance, if you turn on debug keys (LVdebugKeys=True) and press Ctrl+Shift+D, then Ctrl+Shift+_, it toggles wireframe drawing. This affects the appearance of many of the Modern controls. In addition, if you go to your LabVIEW installation directory, and open the "resource" folder, there's a folder in there called "models", which contains several files with names corresponding to different types of controls. Six of them are in 3DS format, and are in fact valid models that can be loaded in a 3D modeling program. The other 36, however, are in some format with the extension ".ptc", and a quick Google search doesn't turn up anything about that model format. So what model format is that? (At least it's not the only model format it supports.) And more importantly, how can I get LabVIEW to load a custom model for a custom control? EDIT: I edited slided.3ds in Blender and the changes were visible on the Boolean slide switch controls.

Just searching for strings in LabVIEW.exe. Also, about the wiki page for Easter eggs, that's more for settings that only cause minor visual changes, just for fun. This one actually adds additional options that could have some use to a menu. By the way, if anyone can figure out what any of these options actually do and how to use them, please post here!

First off, let me say that this is yet another post concerning functionality that has not officially been released by NI, so the standard disclaimer about not using it in anything you care about applies here. Basically, if you add the line SuperSecretListboxStuff=True to LabVIEW.ini, it adds some additional options to the context menu for the list box control. Here's a comparison: Just thought I'd share this, since I googled the INI key and didn't find anything, so I figured nobody's found it yet.

I know about that section, but what about the section for XNodes?

As anyone familiar with my posts would know, I tend to enjoy finding "hidden" stuff in LabVIEW, that's currently not ready for public consumption. Like XNodes, private methods/properties, stuff like that. There used to be a section called "Rusty Nails" designed for discussing this unreleased stuff, with subsections for XNodes and VI scripting (keep in mind this was before scripting was officially supported.) What happened to this section?

Description, I guess. I was able to unlock it just fine with that hex hack. If you want to make it yourself, just set SuperSecretPrivateSpecialStuff=true in LabVIEW.ini, place an Application property node, and select the Application->Unattended Mode property. That's exactly what Darren's VI does.

I wrote a VI like that a while ago too! Only instead of a VI's terminals, it draws an Xnode's terminals, from the cluster returned by its GetTerms4 ability VI. And yes, it also uses that method.

Well when I do get VIPM working, I'd still like to have the packages kept track of properly. Though I guess I could always just install them and have it overwrite the files. Besides what if I want to install something I didn't have installed in LabVIEW 2012?

Why are you using To More Specific Class there? AFAIK, Bool is more specific than Control, so To More Generic Class would make more sense. But yeah, I hate it when the terminals are like that. 1 pixel bends look terrible. That's one case when I'd rather have the wire not line up perfectly with the terminal.

When designing block diagrams, I tend to spend way too much time making sure things are aligned perfectly, down to the pixels. It's really annoying. This is most noticeable with bends in wires. I don't like having "uneven" bends, or bends where they aren't necessarily needed, or wires that cross unnecessarily. For instance: Now you might wonder why I have bends there if I can just move the wires so they look straight. Well then they won't be perfectly aligned with the node's terminal. For instance: Of course, when there are bends, I want them to be even. For instance, these are the steps I might take to "fix" this sequence of property nodes (that I wouldn't likely put together in practice to my knowledge): Does anyone else have issues with trivial things like this? I find myself using the arrow keys a LOT on the block diagram to fix these kinds of things. Am I alone in that?

Bumping this thread because I tried VIPM 2013 and it didn't work either, and when I reinstalled VIPM 2010 that stopped working too

Actually, turns out that particular scripting action works even when the VI is running, so I didn't need to use Fake Exec State. Here's one that's 100% safe to use. animation.vi

I imagine it was something like this. (warning: uses a private method to keep it in one VI, and in a manner I doubt was intended, so it might crash under certain circumstances. I feel it's fine in this case since this is just for fun, and nothing critical.) animation.vi