Sparkette

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

I thought Mike said it was confidential. Thanks for the explanation though!

Yeah, that's WAY out of my price range. Sorry to get your hopes up, and good luck!

I assume you're being sarcastic. I guess I didn't really make that very clear. Sorry; I'll fix it! By the way, could you maybe post some stuff about what each flag does? Or is that confidential? EDIT: Oops, can't edit the post. If a moderator sees this, please add the following text to the beginning of the first post: As with many of my posts, this is very dangerous, and should under no circumstances be used with anything too important to be affected by crashes, corrupted VI's, and other bad stuff, which will very likely happen as a result. This is only posted as a curiosity about the internal behavior of LabVIEW.