Saving all properties for Gobject

[JesVestervang]

Hello everybody,

I am trying to make a GUI where all user custumizations to a number of graph charts etc. can be saved (line styles, axes etc.), but fetching every single property through its own property node will not be very pretty although it will work. Can I somehow fetch the entire set of properties for a graph chart instead of picking each property individually?

Best Regards

Jes Vestervang

[Antoine Chalons]

Hello everybody,

I am trying to make a GUI where all user custumizations to a number of graph charts etc. can be saved (line styles, axes etc.), but fetching every single property through its own property node will not be very pretty although it will work. Can I somehow fetch the entire set of properties for a graph chart instead of picking each property individually?

Best Regards

Jes Vestervang

I don't think you can, but somehow I hope you can.

I think someone had a try before you though, have a look it's interesting : Property Saver on NI Community.

[crelf]

I usually just save off the control itself to a ctl file - you can do that programmatically through scripting.

[Francois Normandin]

I don't think you can, but somehow I hope you can.

I think someone had a try before you though, have a look it's interesting : Property Saver on NI Community.

I had started this last time a similar question was asked, just for fun. So I finished it. It's only the "save to file". You'd have to do the same for "loading" the properties... but I think it's a good start.

Scripting involved, of course.

Keep both VIs in the same directory and call "Save All Properties to INI.vi" with inputs wired. No error checking and no user interface done.

saveprops.zip

[JesVestervang]

Hi guys, thanks. It looks very useful. François, do you think you can save your code so that I can load it in my LV 8.6.1?

[JesVestervang]

I think someone had a try before you though, have a look it's interesting : Property Saver on NI Community.

Now I tried it out and the functions Set/Get VI control properties seem to work perfectly. The "Get" function returns a nice struct which I just pass on as a variant to my configuration handling routine.

Now I just hope that it is stable and so on. :-)

Regards

Jes

[Francois Normandin]

Hi guys, thanks. It looks very useful. François, do you think you can save your code so that I can load it in my LV 8.6.1?

I changed the hierarchy. Check out the top-level VIs in this llb saved for 8.6.

I had to include the OpenG VIs in the llb to prevent breaking the links. I got wet last time I backsaved...

SaveProps.llb

[Norm Kirchner]

Francois,

I like the way that you've coded this up, but there is a minor yet major point you've missed.

Although this will work great for things like numerics and such, things that have hierarchical layers of properties will fall very short.

I've been trying to eat the beast from the inside in order to make this possible through scripting by being able to get the full hierarchy of properties exposed through VI Server, but have fallen short so far.

There are a few classifications of property 'types' that warrant having some time spent defining.

I really think that an waveform graph is probably the most inclusive of all types and also the one that needs this ability the most (think XControls)

Unless I really mis-read your code, and it actually does this exact thing.

(if so, feel free to steal one of the beers that I've got lined up for me @ ni week this year)

-Norm

[Francois Normandin]

I like the way that you've coded this up, but there is a minor yet major point you've missed.

Although this will work great for things like numerics and such, things that have hierarchical layers of properties will fall very short.

Hi Norm,

of course, you are totally right. I've failed to even consider this possibility.

However, the code does it and doesn't do it at the same time. From what I can tell at first glance, there are two caveats:

1- "Properties.All Supported Properties" doesn't return the full property name. I mean, take XControl, it contains "Is XControl?" and a cluster of "Container Bounds". I thought the property returned "XControl:Is XControl?" and "XControl:Container Bounds". Rather, it returns "IsXControl?" and "Container Bounds"... so in the successive for loop, I get values for the property "control/Container Bounds" instead of "control/XControl:Container Bounds" and therefore gets the wrong property value for all properties that share the same datatype. This wil happen in hierarchies like Cursors, Plot, XControl, and so on... (Name collisions)

2- And the same "Properties.All Supported Properties" returns the property names inside hierarchical structures up to the first separator. We can see that from the "Caption" property.

The first property is "reference", and then the first separator. So this is all that gets thrown in the file: a reference number which is totally worthless the next time you would load the application. Here, I guess I should try to detect the reference type and add it to the list of "control references" to sort though. There would most probably be issues with naming convention in the file to prevent name collisions here as well.

I don't see how this can be done safely without using recursivity.

To tell the truth, this is more of a fun experiment in scripting than it is a real need (for me anyway). Like Chris mentioned, save the control directly to a file ad save yourself a lot of trouble!

[JesVestervang]

Now I tried it out and the functions Set/Get VI control properties seem to work perfectly. The "Get" function returns a nice struct which I just pass on as a variant to my configuration handling routine.

Now I just hope that it is stable and so on. :-)

Now I tested the Property saver quite thorougly with various controls and indicators and it seems to work with no problems at all. Very neat when you want to allow your users to save run-time configurations of graphs etc.

Regards

Jes

[viSci]

The link to the Property Saver vi is broken. Could someone please repost? Thanks!

[Yair]

In case someone runs into this in the future, the property saver is here - http://www.kshif.com/lv/index.html

[viSci]

I have been using the property saver vi's and they are very useful but slightly buggy in LV 2011. One example is that for any controls that have a scale (sliders, graphs, etc) the property Uniform Marker Spacing seems to always get turned off. I looked into the code but did not see anything that looks incorrect. Has anyone had any luck fixing such version incompatibilities?