supersecretprivatespecialstuff Basic Object Flags

[Sparkette]

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.)

Edited August 13, 2013 by Mark Balla

[Mr Mike]

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.)

 

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

 

I'd be especially careful with 0x0000 00010, 0x0000 0080, and 0x0000 4000.  Different types of objects have different sets of flags stored in the same place.  Good luck.  You're probably going to be seeing a lot more strange behaviors once you start playing with non-controls.  And they're not good strange behaviors

[Sparkette]

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.

Edited August 13, 2013 by flarn2006

[jcarmody]

I assume you're being sarcastic.

 

I didn't get that impression.

[Mr Mike]

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?

Definitely not sarcastic.  It was entirely sincere.  Your older posts didn't include the warning at first and you edited them to include it.  Now you're including it by default.  Thank you.

 

What each flag does is confidential.  About a third of the flags are for edit-time features (like "object is grayed" -- but that's just a side effect of what the flag actually does), a third for settings on objects, and another third for flags for the compiler.  That's all I'll say about it.

[Aristos Queue]

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.

[Sparkette]

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!

[Aristos Queue]

I thought Mike said it was confidential.

There are various levels of confidential.