13 replies to this topic

[crelf]

So here's what I want to do: I've got some comma-deliniated text coming into a VI that describes what to set one of the VI's properties to. For example:

Control=Progress|Scale.Range.Maximum,Value=50

I'd like to do this in a generic way (ie: don't want to create code to handle all the different control classes or their property accessors). I can get a generic reference to the control, but how do I push data to its properties?

Discuss

[ShaunR]

Don't you just love strict typing

I've got a control scraper and it's counterpart which sets the values. Unfortunately it's part of the websocket API, so can't give it to you.
Basically you have to use variants to get the control type and use the controls ref with the appropriate value property type to set it (case structure with a frame for almost every type). This means that it runs in the UI thread which is a real downer.

You can encode the type in your string if you want it to be generic for transmission or you can use coercion to force values to the target controls type (different type of genicity).

I would also suggest JSON rather than a comma delimited string

Alternatively, you can wait for the serialization VIs in the other thread.

[GregR]

If your code is only going to run in the development system, then you could use scripting to dynamically generate a VI that sets the properties in the file being loaded. That would at least be interesting.

If you have to resort to staticly creating code for each property, the property node scripting interface can return a list of all the supported properties for its current class. You could use that to generate a VI for each property or a case frame for each property in a VI for each control.

[crelf]

I've got a control scraper and it's counterpart which sets the values. Unfortunately it's part of the websocket API, so can't give it to you.

I have no problem setting the value of the control (I'm doing it just like you suggested - great minds think alike )

Alternatively, you can wait for the serialization VIs in the other thread.

No doubt

If your code is only going to run in the development system, then you could use scripting to dynamically generate a VI that sets the properties in the file being loaded. That would at least be interesting.

Yeah, I thought about doing that, but this will be a built app

If you have to resort to staticly creating code for each property, the property node scripting interface can return a list of all the supported properties for its current class. You could use that to generate a VI for each property or a case frame for each property in a VI for each control.

Right - and that's currently my last resort, but I really want to avoid that if at all possible.

[sachsm]

Maybe you can hack into this bad boy and make it work for your purposes.

http://www.kshif.com/lv/ps150_85.zip

[hooovahh]

Maybe you can hack into this bad boy and make it work for your purposes.

http://www.kshif.com/lv/ps150_85.zip

Wow that guys had alot of time and dedication for that. Here's the site which explains a little about what it is.

http://www.kshif.com/lv/index.html

I expected cool scripting or something to get those attributes but when I dug down saw lots of case statements for each attribute, for each control type.

[ShaunR]

Wow that guys had alot of time and dedication for that. Here's the site which explains a little about what it is.

http://www.kshif.com/lv/index.html

I expected cool scripting or something to get those attributes but when I dug down saw lots of case statements for each attribute, for each control type.

Yup indeedy.

There are some optimisations you can do to reduce the cases. All controls have a "label" and "Caption" of type text (single case), U8,U16,I8 I16 et al can have one case etc. But as soon as you get to graphs and the more complex controls, you pretty much end up with a case for each property/type

That implementation is a lot cleaner than mine though but, in my defense, mine does produce JSON strings (for obvious reasons)

[crelf]

...mine does produce JSON strings

You're really quite the JSON fan Maybe start a new thread and we can talk about the pros and cons of JSON vs other notations.

[ShaunR]

You're really quite the JSON fan Maybe start a new thread and we can talk about the pros and cons of JSON vs other notations.

Not a fan. Just a really easy way to link labview to browsers. I think another thread would be very short i.e. Prefer anything over xml .

[huotom]

I think maybe it is available in the app's config file whose extensions is *.ini or *.aliases.

[Aristos Queue]

i.e. Prefer anything over xml .

ShaunR and I agree on very few things, but when we do, it is adamant agreement. Whatever your data communications problem you're having, if XML is your solution, you actually have two problems.

[jcarmody]

ShaunR and I agree on very few things, but when we do, it is adamant agreement. Whatever your data communications problem you're having, if XML is your solution, you actually have two problems.

That sounds familiar.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Found on the Internet...

[crelf]

ShaunR and I agree on very few things, but when we do, it is adamant agreement. Whatever your data communications problem you're having, if XML is your solution, you actually have two problems.

Damn it people - I *want* to comment on this, but I refuse to hijack my own thread! Start a new one!

[crelf]

I think maybe it is available in the app's config file whose extensions is *.ini or *.aliases.

I'm not sure I understand what you mean - can you please explain a little further?