individual enable of controls in array

[ensegre]

For a GUI I'm doing, I find myself wishing for something like

which notoriously is not possible per element, as array element properties (e.g. disabled) apply to all elements. On the other hand, the array container is soo convenient because it's growable and indexable at runtime.

Can someone share an idea of implementation? I've been thinking: programmatical rewrite of the content of the "uneditable" elements which are changed (bad, it gives the user the impression that content could be written into); placement of a fixed maximal number of replicas of the element cluster on FP, and visibility of those needed (will become inconvenient for large numbers); array of clusters with subpanels (no goer).

Actually my customer is suggesting something like

which would be easily realizable (input field is copied to result on Value Change for editable elements, blanked for uneditable), but I find it a little overbloated, if it has to be extended to more cluster fields. Moreover both Enter and Focus off cause Value Change, unless they are trapped and treated...

[chris754]

You could trap the "key down?" event and discard it if the editable field is not enabled. The field will still be white, but no characters will be entered.

[Yair]

It is actually sort of possible to create an array of subpanels. You can't do it directly, but you can have a VI with a subpanel which will itself have multiple subpanels and control that to look like an array. To this day I still never had an actual need for something like this, so I didn't work out the whole thing, but I did post a quick example here - http://forums.ni.com/t5/LabVIEW/User-interface-problem-list-of-clusters/m-p/2311770#M726599

 

I expect that the major issue here would be that you need to communicate with all the VIs, so you would need to come up with a mechanism for that which would still have an API which would make them simple enough to use.

[ensegre]

You could trap the "key down?" event and discard it if the editable field is not enabled. The field will still be white, but no characters will be entered.

Right, that is an idea. But how to identify the array element? Key down doesn't return coordinates which can be worked out, and Array, unlike table, doesn't have a property which returns EditPosition.

[ensegre]

It is actually sort of possible to create an array of subpanels. You can't do it directly, but you can have a VI with a subpanel which will itself have multiple subpanels and control that to look like an array. To this day I still never had an actual need for something like this, so I didn't work out the whole thing, but I did post a quick example here - http://forums.ni.com/t5/LabVIEW/User-interface-problem-list-of-clusters/m-p/2311770#M726599

 

I expect that the major issue here would be that you need to communicate with all the VIs, so you would need to come up with a mechanism for that which would still have an API which would make them simple enough to use.

Cool, I need to study it. As you say, it may be that the infrastructure needed overwhelms the benefits in my use case.

[hooovahh]

Here is a quick solution that just looks at the value change seeing if the string changed value and if it did read the value of the boolean.

 

A better solution might be to look at the Mouse Down event, and find which index the mouse has entered then read the boolean value and do something else like force key focus off of that control so the user has no way of even entering a string.  The way it is right now is sorta strange where you are allowed to enter text in the control, and then it revers back.  I feel like a better user experience would be to prevent them from entering the control in the first place.

 

EDIT: Okay another quick and dirty solution, poll the key focus of the string and if it is true then read the value of the boolean, and if it is false, then remove the key focus.  I did it this way because with the mouse down event you could still tab into the control, and edit the string control. This way is less efficient because you are checking for key focus but it prevents this edge case.

Editable Disable Array.vi

Editable Disable Array Poll Keyfocus.vi

[ensegre]

thanks, but that is what I meant by

programmatical rewrite of the content of the "uneditable" elements which are changed (bad, it gives the user the impression that content could be written into)

 

Extending, I could also think ahead at pseudo-disabling mouse-operated controls, like booleans or menu rings; for them indeed trapping the mouse down (and working out the coordinates) should be doable.

[chris754]

This will get you which element the mouse is currently over. Maybe you can modify for the item being changed??

GetArrayElementMouseHover.vi

Edited March 2, 2015 by chris754

[ensegre]

EDIT: Okay another quick and dirty solution, poll the key focus of the string and if it is true then read the value of the boolean, and if it is false, then remove the key focus.  I did it this way because with the mouse down event you could still tab into the control, and edit the string control. This way is less efficient because you are checking for key focus but it prevents this edge case.

 

yeah, that gives a better experience. The price perhaps is that the focus condition has to be continuously polled in the timeout case, but its impact should be negligible.

 

EDIT: I see that it works because the editable value read is exactly that of the current element of the array, i.e. that containing the string which has currently focus. I would not have thought at once.

 

This will get you which element the mouse is currently over. Maybe you can modify for the item being changed??

I'm afraid that, besides requiring the position to be continuously polled, it will identify the element only as long the mouse is on it. Or, at least as long as it is detected that focus entered to the string (following a mouse click). But tabbing, etc...

 

In any event, thanks everybody so far for the suggestions.

Edited March 2, 2015 by ensegre

[chris754]

I agree. But I was thinking you could trap the item in the array on the mouse down event. But this won't work if tabbing is allowed. Although you could keep track of it on mouse down and tabbing event. Not very elegant, but possible.

[viSci]

I have done this using a boolean that is small and non overlapping in the false state and large (eclipsing) and partially transparent in the true or disabled state.

[ensegre]

How can you make a boolean with size depending on its value?

[drjdpowell]

placement of a fixed maximal number of replicas of the element cluster on FP, and visibility of those needed (will become inconvenient for large numbers); 

 

This will work with very large numbers of elements, if you keep the full set of data as an array and only write the visible portion of the array into clusters (where there need only be 50 clusters to fill the screen).  Use a separate vertical slider whose Value Changed event triggers a rewrite of a subarray of data into the clusters, complete with disabling selected controls.  One can also change colours or other attributes this way.  

[hooovahh]

EDIT: I see that it works because the editable value read is exactly that of the current element of the array, i.e. that containing the string which has currently focus. I would not have thought at once.

Oh yes that is a nice little trick to use.  Be sure and share that nugget when you find others that don't know that is how it works.

[viSci]

You can customize a boolean and replace the on and off images with different sized rectangles from the decorations palette.  If you want to get fancy you can import graphics with alpha transparency so that the disabled state looks grayed out but still visible.

[Mike Le]

placement of a fixed maximal number of replicas of the element cluster on FP, and visibility of those needed (will become inconvenient for large numbers)

 

I've used this solution before; how many elements are you looking at and what do you mean by "inconvenient"? I've been able to do it with an array of ~50 elements with no problems. I find the cluster elements automatically by searching through the main cluster's sub-references.

 

If you're talking hundreds or thousands of references then it would be slow to start up, but if it's in the dozens, I don't notice a performance hit.

[viSci]

Here is an example of what I am talking about....

Array Disable.vi

[drjdpowell]

Here’s a quick example of the cluster method.   I did disabling of the string, hiding unused clusters, and also added some colour based on string length.  LabVIEW 2013.

 

Cluster View into Array.zip

[Yair]

Here's a very rough example of the subpanels way (2011). The actual mechanics obviously need to be made proper.

 

The big advantage with something like this is that you can completely divorce the UI from the data, you can create arbitrarily complex behavior (because you're only dealing with one element) and that if you need to change something, you only need to do it in one place.

 

The disadvantages are that you lose some of the edit time convenience (although that happens with other things too), that the code can be more complex and that you might have some more difficult with keyboard navigation.

Array of subpanels demo.llb

Edited March 3, 2015 by Yair

[ensegre]

All interesting ideas, hats off! Can't really mark four or five posts as the Solution, do I?

[ensegre]

You can customize a boolean and replace the on and off images with different sized rectangles from the decorations palette.  If you want to get fancy you can import graphics with alpha transparency so that the disabled state looks grayed out but still visible.

I'm trying this technique which is the simplest, but I'm finding really difficult to achieve correct alignment between the rectangles (in LV2014 linux). Moreover, once I drag the control on a FP, the result morphs to an unpredictable container size, with arbitrary displacement between the two rectangles - sometimes one of them not even clickable. When I edit the control appearance, depending on the mode I am into (wrench or tweezers), I note that there seems to be some sort of containing frame, appearing as dashed if I select an area around the control, which encloses the button rectangles in all of its possible states - but the relation between the two button rectangles I can resize, their relative position, the frame, and the result once used in another FP is a complete mystery to me.

 

Are there known bugs, is perhaps the idea of different sized boolean images something which sneaked through the cracks of LV, but isn't really supported? I note that while for instance there are properties supporting the four colors and four strings for all states of the button, there are only one Button Size and Bounds.

 

Attached my simple attempt: it would be a rectangle of about 135x35, half width when off, derived from the Classic Flat Square Button. Well, just resizing the on and off state rectangles, not dragging in anything from the decorations palette.

LeftNumberCoveringBoolean.ctl

Edited March 9, 2015 by ensegre

[ensegre]

I fear that this solution of covering the control to be disabled with a boolean rectangle with size dependent on state is somehow unstable, and I'm not too surprised, missing detailed size properties as mentioned above.

 

It occurs me now that one of my compound buttons displays fine on my linux development systems, but gets mangled if I transfer the code to the test windows system, and stays mangled when I save the containing FP and bring it back to the dev sys. Attached the .ctl, this is how it looks on linux

and this on windows

 

Any experiences?

EnabledShutter.ctl