GObject properties broken when accessed within a Traverse callback while recording undo transaction

[raphschru]

Hello everyone !

I'm trying to create my own scripting utilities with the help of the "Traverse" method on a VI reference.

To start simply, I inspired myself from "Traverse for GObjects.vi" provided in the scripting API and tried to create a similar VI that just grab all information it can from the controls present in the FP. Until then, no problem.

The problem happened when I tried to combine this with "Transaction:Begin/End Undo", allowing to undo potential scripting operation done in the Traverse callback function.

It seems that, while recording an undo transaction, the properties of the GObject (a Control in my case) in the callback suddenly gives nonsense values, whereas it does not happen whithout the undo transaction.

It is quite annoying as it cancels out all of the interest of the traverse function.

Does that sound like a bug, or am I doing something wrong with my references ?

To reproduce this behaviour, please try the attached code by running "MAIN.vi"

Thanks in advance.

[Intaris]

There are some properties of controls which also interfere with transactions ( they cancel them entirely).

I found no rhyme or reason why these properties should do this, it was a clear and obvious bug.  I can't recall which property I discovered, but it was something trivial like text orientation fo a control or something similar.

[wiebe@CARYA]

---

@raphschru wrote: 

Does that sound like a bug, or am I doing something wrong with my references ?

---

Seems a bug to me.

---

@raphschru wrote: 

It is quite annoying as it cancels out all of the interest of the traverse function.

---

All interest? I wouldn't go that far.

So you can't use it to change things. Actually, doing that has never crossed my mind. Or maybe it did 10 years ago, and I dismissed it there and then. Possibly for this reason .

Most of us use the traverse (very effectively and conveniently) to find things recursively. Simply get references, and then use them when it's done.

AFAIC, getting the references and then using them is usually less work then doing it in the callback (if that worked). You'll lose the "traverse created code", but I personally never needed that.

If you feel this "cancels out all of the interest of the traverse function", guess you have to recursively go over all diagrams yourself for block diagrams, and over and into all controls for front panels. Not that hard, we had to do that before the traverse was published. But I'd forgive the traverse it's merits, and use it the way it work.

EDIT: Nonetheless, this might need to be fixed, or documented, or disabled, or something. If it's not CAR-ed already.

[raphschru]

Appart from the "traverse generated code" feature, I want the traversal to be influenced by certain properties of the traversed objects, meaning I want to perform a logic using scripting which determines if current object's hierarchy has to be skipped or if the whole traversal has to stop. The properties being broken in this case makes it impossible.

I agree with you on the fact that it does not "cancel out all of the interest" of the traverse function of course, however why providing the ability to implement its own callback function if we are not supposed to put script inside it ?

Here is a really simple usecase : I would want to get the first GObject that has a certain tag in a VERY large VI (i.e. with lots of objects).

I could achieve this by using the "stop traversal" flag when the tag is found in the current object (within the callback), and the search would be shortcut immediatly.

Instead of this, I actually have to traverse through all GObjects in the VI first (which is not efficient), and then do the work.

For me it's actually just a matter of performance. When doing several searches in lots of large VIs, the times quickly add up.

I have heard other problems occurring with Undo Transaction :

https://forums.ni.com/t5/LabVIEW/Setting-a-Tag-of-an-object-is-not-captured-in-Undo-Redo/m-p/3746931

which gives me the impression that my problem is only the emerged part of a bigger problem.

I'm wondering how these Undo recording methods work...

[wiebe@CARYA]

---

@raphschru wrote:

I agree with you on the fact that it does not "cancel out all of the interest" of the traverse function of course, however why providing the ability to implement its own callback function if we are not supposed to put script inside it ?

---

Note that the functionality (to implement your own callback function) is really not provided.

You're digging in a function, assuming everything in it is 'provided'. It's not. The reason that NI is not providing the lower level could be that it's not working. Or working under certain conditions only.

This is scripting...