LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

A more successful experiment in creating compositable user interfaces for Config Dialogs

Solved!
Go to solution

GoofeyWires: Can you elaborate on change #1? I'm intrigued but not seeing how it would work.

0 Kudos
Message 11 of 15
(1,256 Views)

First I need to understand why did you pass data to each of the UI elements instead of a real control which you can configure as you like?

If you pass a control you can use the PropSaver to get all the properties and move them to the chosen control on the FP.

You wrote something about avoiding property nodes since they make the UI flicker but I didn't have time to get too much into it.

Are you avoiding property nodes? I see property nodes in the setup control.vi of the ring for example...

Anyhow, If you are ok with it then my basic solution is setting the controls by using PropSaver on some off FP controls and allow composition of the controls properties by allowing to override location/size properties in your controls array, again, by enterring a control with the properties you desire.

If it was possible to turn a LV object to be the dynamic dispatch input of a vi the next step could have been simple and elegant.

I would then add a vi called "create control" with all the possible controls as input and create all the connected controls and maybe even allow an array input for each control type.

However, since you didn't do it, I guess I'm missing something here.

The other option is to create a long cluster with all the possible inputs and in addition an enum type. This cluster will be parsed and get you the same result as you currently have.

The added value of the PropSaver option is that you can add many more complex control types and the logic becomes much simpler with much less work on your side.

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

0 Kudos
Message 12 of 15
(1,227 Views)

I can't pass a real control because there is no real control to pass. The controls are repurposed continuously as the mouse moves on the screen. I have to know every property that the user wants set on a given control so that I can reset that property the next time the control is needed in that same location. I didn't know anything about a PropSaver until you mentioned it. Even with that,I only can return one reference at a time, so the user would "get reference for first, configure it, tell framework "remember this property set", then ask for the next control reference." Besides all of that, if the caller gets its hands on the control references, who knows what they start messing with, like position properties or sizing nested parts, or embedding font runs in the string control.

 

I'm happy to explore this option the next time I work on this project, but that's my reasoning for the current design. Returning a reference to the caller was just never an option.

0 Kudos
Message 13 of 15
(1,211 Views)
AQ, this is exactly what I've been trying to implement in my project, but done much more elegantly and efficiently than the way I was doing it. Thankyou for sharing this!
Message 14 of 15
(1,073 Views)
AQ, this is exactly what I've been trying to implement in my project, but done much more elegantly and efficiently than the way I was doing it. Thankyou for sharing this!
0 Kudos
Message 15 of 15
(1,073 Views)