Sparkette

You must have edited the PNG file directly while leaving all of the header data alone.  When I copied that snippet to a blank VI, that TRUE constant wired to the conditional terminal became a FALSE.

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.

That is fascinating.  So that explains this thread on glyphs in multiple columns.

 

http://lavag.org/topic/7002-multiple-glyphs-columns/

 

I haven't played with it yet but some of these settings sound very useful.  If you don't mind me asking how did you find this INI key?

 

EDIT: BTW has anyone just tried SuperSecret<insert function or control>Stuff=True  for every function imaginable?

 

Or EnableSecret<insert function or control>=True

 

Double Edit:  Looks like this works on 2013 and newer.

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!

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 or fact?   .

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 used that method when writing this VI, which programmatically generates an image of a VI's connector pane terminals.

 

http://lavag.org/topic/16581-get-connector-pane-32x32-image-looking-for-better-idea/?p=101586

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.

quite often I have to copy the OpenG libs (or other libs) onto a PC without net access.

 

The bodgy way (they works fine though) is just copy various directories from user.lib and vi.lib directly to the other machine. If done incorrectly, in other words if you don't copy the right files/directories,  you may end up with missing palettes. 

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?

Okay I don't think I'm as bad as some of you guys but I too find my self moving things one pixel at a time some times to line them up nicer.  But there are a few times that I hate the terminal choices used by NI.  Here are two times that I can think of that irk me.

 

 

 

Why do these not line up?  Seriously NI?  Seriously?

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.

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

Does anybody have this file?  I recall seeing it a long time ago and I want it again.

 

Thanks,

Jim

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

Each class in the hierarchy is free to reinterpret the flag sets differently and each class may (and frequently does) shift the meanings around between LV versions as we add new features. The flag set is really convenient, so an older, not-used-so-much feature may get bumped out of the flag set and moved to other forms of tracking if a new feature comes along that wants to use the setting (especially since much of the the flag set is saved with the VI and a feature that is a temporary setting in memory may have used the flags since they were easy and available on that particular class of the hierarchy). Tracking what any given flag does is tricky. Even the three flags that haven't changed in any class for the last five versions of LV have very different meanings depending upon the class using the flag.

 

For example, flag 1 on a DDO specifies control vs. indicator, but on a cosmetic it turns off mouse tracking. On structure nodes it indicates "worth analyzing for constant folding", and on the self-reference node it indicates that dynamic dispatching isn't propagated from dyn disp input to dyn disp output.

 

 

 

It's pretty much pot luck. You can use Heap Peek to get some translation.

I thought Mike said it was confidential.

Thanks for the explanation though!

Thanks for the response. It is actually $2,300 flat. Plus free shipping. This way, you are saving $1,350.

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

Thank you for being much more explicit about the dangers of playing with these things.

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.

Well what's the price?

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

I found an interesting private property for the GObject class: Basic Object Flags. This provides low-level access to an object's flags, such as (for controls) the mechanical action, disabled/grayed behavior, etc. Some of them cause very strange behavior, which is not surprising for a private property. I can confirm that this is the same as the "flags" value seen in Heap Peek.

I wrote a VI (attached here) that lets you change these flags. Just wire a GObject reference to it, and the front panel will pop up and let you interactively change the flags and see the results. Does anyone have any more information on what some of the flags do exactly? Here's what I have so far for controls:

00000008 - Object is disabled (sort of like it forgets it exists)00000010 - Object is not selectable00000020 - Object is not resizable00000080 - Object is grayed00004000 - Object exhibits strange behavior, becoming grayed at random00010000 - Affects mechanical action00020000 - Affects mechanical action00040000 - Affects mechanical action

Object Flag Manipulator.vi

(For those unfamiliar with private properties/methods, they're additional properties and methods that remain hidden even when scripting is turned on. To enable them, just add "SuperSecretPrivateSpecialStuff=True" to LabVIEW.ini, but be warned, this is internal low-level stuff that NI doesn't support.)

When the Application builder renames VIs and X-Controls, the X-Control gets locked as soon as the VI using it gets loaded into memory. So my guess this feature or another hidden feature is used to be able to modified/rename locked items.

It seems more likely that Fake Exec State would be able to do that. (not sure if it actually can)

There is one more much needed method.

 

InternalCmdsHelp.vi

I found that one too, but I'm pretty sure everything you can do with that command you can also do with the debug keys. What do you mean by "much needed" by the way?

My guess is to be able to build exe-files containing x-controls.

Why do you say that?

If someone were to figure out the format though (I haven't, in case anyone's wondering), how would they get LabVIEW to actually import it as a PICC image? By examining copied decorations in Heap Peek + Cheat Engine, it seems like the decoration is only showing an image that's hardcoded into LabVIEW. Does LabVIEW contain functionality to show an embedded PICC image just like it does with any other image you paste in, or can it only show that image format if the image is already programmed into LabVIEW?

Also, I noticed the Silver controls, added less than two years ago, still make use of the PICC format. Why continue to use this when you can add support for an open format like SVG and use that instead?