How to update type-def programmatically

[labmaster]

My application is consisted of various sub-VIs.

To select some instrument setup, I used an common enum control in main VI.

In this case, I used the type-def enum control (control.ctl) to update in all sub-VIs.

In some situation, an user can define the instrument setup file by editting setup.ini.

Therefore, the enum control should be updated in executing.

My problem is the enum control property node can't be used in updating the type-def enum control.

(The type-def and strict type-def are not allowed to write via the property node.)

If so, how to update the type-def enum control programmatically?

[BillMe]

You can't update the "Strings[]" property of an enumerated type while the VI is running. You CAN do this with the Text Ring and Menu Ring controls however.

[chrisger]

Hi there

the "Strings[]" property of Text Rings and Menu Rings is NOT part of their strict typedefs data, so even if you use a Ring you aren't able to update the "Strings[]" of all the Ring's instances.

[tbd]

Hi labmaster,

      I don't think this is going to help you - it sounds like you need the enum to be on a running diagram during the update and, like Bill said, you can't update the enum "strings" property while it's on a running VI,

...  but you can write to its "strings" property programmatically - via reference if you:

1) Open a reference to a non-runnng VI with the target-enum on the FP

2) get the Front Panel "Controls" [array] property,

3) Find the right reference (look at each control-reference if there's more than one)

4) Write to the strings property (programmatically)

Cheers!

[chrisger]

whops, my post valid for "typedefs", not "strict typedefs"....

[TCPlomp]

It can be done, but I advise you not to....

Here's how:
-Close all VIs owning the Typedef
-Create a new Typedef with the following code
-Save it under the same name
-Open up your VIs and the Typedef should be updated

The problem lies in the fact that your case structures will react in strange ways, most likely your code is broken because there might be less items in the new enum and there would be cases for non-existing items which LabVIEW can't handle

Ton

[Ben]

I love these "YES YOU CAN!" replies to traditionally "No you can't" questions.

Ton wrote

"

The problem lies in the fact that your case structures will react in strange ways, most likely your code is broken because there might be less items in the new enum and there would be cases for non-existing items which LabVIEW can't handle.

"

If all of the case structures have a default case that enunciates an un-handled condition, you can survive these dynamic changes.

Now if we could only do this in an executable...

Ben

[tbd]

Hi Ben,

      To be fair to BILL @ NGC who responded "you can't update the Strings[] property of an enumerated type while the VI is running".  Isn't this accurate?  I don't think this has been refuted or disproven - just a couple of work-arounds (including mine) that won't do what the original poster requested.

My sense, reading Ton's post, was that Ton responded mainly to the subject-line, not the content of the post: "the enum control should be updated in executing" (translation: "the enum control should be updated while executing"). 

Your reply seems to be denigrating a concise and accurate reply(?)

Regards.

[Ben]

Sorry it cam across that way.

My intent was to encourage thinking outside the box and finding new was to "break the rules".

That is how scripting was uncovered etc.

Ben

[mikeporter]

My colleague Ben ( ) brings up a good point concerning case structures and enums, and in the spirit of his "thinking outside the box" comment, consider that there can be situations where you want the code to break if an enumeration changes. Take for example a VI that is parsing an input based on the value of an enumerated input. In those situations I don't want a default case. The broken arrows will help me find the places where I need to add code to deal with new enumerations.

Mike...