02-10-2016 12:29 PM
I have an application that works but requires Human Factors improvements due to new hardware with a smaller keyboard and no external mouse in a harsh environment with various limitations on the operator.
The existing app has a main panel with groups of controls. The controls are grouped by their commonality; they're not in arrays or clusters, they're just individual Boolean controls. Each control on the main panel activates a subVi; a single event structure calls each subVI with a control’s value change. See the 'before' image, attached. The actual panel is much more crowded; I've only depicted two groups of controls in the image. (Pardon my ppt depiction of LV objects, especially the event structure with a heavy dashed-line box.)
As a baseline before actually improving human factors, the attached proposed 'after' image has a tab control that selects event structures; i.e., no longer just one event structure, there's an event structure for each case of the tab control. In the ppt, I've copied/pasted the controls for each group; in LV, I'd make the controls physically larger and spread them out a bit.
I'm also considering a dedicated "QUIT" tab (i.e., no ‘quits’ on the other tabs) because all the subVIs have QUIT buttons to return to the main panel/tabs; possibly too many QUIT buttons and confusing to the operator.
Assuming what I've proposed so far is understandable and could conceivably work, to improve Human Factors I'd like to define a key(s) to tab through the panels AND another key(s) to tab the focus through the controls in each panel. The operator can use a pen as a stylus for pecking keys, which should be easier than using the built-in touchpad.
Questions:
Thanks,
Solved! Go to Solution.
02-10-2016 12:56 PM
02-10-2016 01:08 PM
Why do you need to have separate event structures?
Have one event structure that handles all of your tabs. That event structure would also contain the key up/down events that would affect manipulation between tabs and within tabs. That event structure would know whether tab 1 or tab 2 is the currently active tab based on value of the tab control and would act accordingly.
02-10-2016 01:25 PM
@RavensFan wrote:Why do you need to have separate event structures?
Have one event structure that handles all of your tabs. That event structure would also contain the key up/down events that would affect manipulation between tabs and within tabs. That event structure would know whether tab 1 or tab 2 is the currently active tab based on value of the tab control and would act accordingly.
RavensFan,
After I made the post, I wondered if my approach was too complicated or if multiple event structures would even work. I guess I was thinking I had to separate the functions in the tabs in order to eventually key between tabs. I wasn't thinking of adding new events to the event structure. This gives me a good starting point.
Thanks,
02-10-2016 01:30 PM
@Dennis_Knutson wrote:
Start by rethinking your event structure. You should NOT use a case structure with individual events. Use one event structure like you have now. A tab control does not get wired to anything.
You can have controls that are common to all tabs. You place them off the tab and move then onto the tab with the keyboard arrow keys instead of dragging them with the mouse.
When a subVI finishes, you are returned to the main.
Like I said to RavensFan, I was wondering about the complexity of my approach shortly after posting. The tip for moving controls back onto the tab control with keyboards arrows is much appreciated. I guess that's been a problem area with new users of tab controls in the past.
Thanks,