05-04-2011 08:51 AM
Hello,
My idea would be to replace the Enum (e.g. replace "Enum Type 1" with "Enum Type 3") . The limitation is that some Bundle functions and Variant to data function, wait to have exactly the same data type (same Enum Items), and I just want to unbundle the "Type & # Fonctions" cluster from my main control to have the correct Enum (see BD picture).
An alternative solution shoud be to have 3 controls with their own Enum (ex.: Main control Type 1.ctl - Main control Type 2.ctl - etc), and select the correspondant Main Control in accordance with my test; but I want to reduce the number of controls, so that the programm could be as autonomous as possible.
Therefore, I would know if there is a way to programaticaly replace the Enum in my Main (cluster) control..?
Best regards
Fred
Solved! Go to Solution.
05-04-2011 09:31 AM
You can't do that at run-time. Doing so requires a data type change, which effectively means the application is trying to modify its own code (i.e., itself) and that is not allowed. You can use scripting to replace stuff, but that is an edit-time operation, not a run-time operation.
You can either replace that enum with a string, or you can use multiple controls as you had alluded to.
05-04-2011 09:51 AM
You might want to look into LabVIEW classes. This kind of problem can usually be solved with dynamic dispatching VIs.
05-04-2011 09:58 AM
@DFGray wrote:
You might want to look into LabVIEW classes. This kind of problem can usually be solved with dynamic dispatching VIs.
I had considered that, but I wasn't sure how you'd use dynamic dispatching for a control on the front panel. Admittedly I have little experience with dynamic dispatching.
05-04-2011 09:59 AM
Why can't you just use one enum with all the states in it? Since you are using a queued state machine, you can queue up only the states you want based on which mode you are in. Maybe I'm misunderstanding what you are trying to do.
05-04-2011 09:59 AM
Hello,
Thanks for the reply..
It is what I was thinking. I have tryed some conversions (like: Flatten to string, Type cast, ...) but it doesn't work.
Finaly, I will use multiple controls, because replacing that enum with a string will be less efficient in my case (too much constants).
In brief, thank you very much for the solution..![]()
Best regards
Fred
05-04-2011 10:07 AM
You are right, it's a solution too, but it was symply to have a coherent/readable diagram.. sometimes should we make more compromise.. 😉
05-04-2011 10:19 AM
sorry, I dont folow the flow of responses..
message n°7 was for : for(imstuck)
@ DFGray: I'm not sure it resolve this (specific problem), like smercurio_fc says, but in many cases LabVIEW classes, should be the solution. II've just started to study LVClasses, so I can't use it right now..
thanks at all
05-04-2011 10:59 AM
A readable way - but not something I would particurly recommend due to the way things would change (potentially making debug rather interesting and bringing lots of Rube Goldberg ridicule from other developers), would be to have your Enums / constants on your diagram and programmatically update a RING at runtime with a cluster of strings and values according to the Enum required. That way you could type cast the ring output with the Enums (type def) at all instances where you want to see what is going on, but still maintain a flexible cluster!!
It would do what you want - select from the text list and show the case in text on the BD according to what is selected if you wrote your code in this way, you would just have to watch out for the incorrect Enum being type cast (good error handling) (string match on the ring text with the enum text maybe?)
05-05-2011 08:38 AM
To dynamically dispatch a front panel control (or the equivalent of a front panel control) you would need to use a subpanel control and dynamically dispatch the VI that loads into the subpanel with one containing the control in question. You would also need the appropriate communication mechanisms (queues, user events, ...) to get data into and out of the control. User events would probably be easiest.
You may also be able to solve the issue with an X-Control, but all possible enums would need to be defined at development time. The classes approach would allow dynamic loading at run time.