Jump to content

Basic Object Flags


Sparkette

Recommended Posts

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 by Mark Balla
Link to comment
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

 

 

attachicon.gifObject 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 ;)

Link to comment
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 by flarn2006
Link to comment
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.

  • Like 1
Link to comment

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.

  • Like 1
Link to comment
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. :P

 

Thanks for the explanation though!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.