Directing User Attention to Correct Front Panel?

[WMassey]

I was curious what others are doing about directing the user

[Jeffrey Habets]

I think in general it is bad to have nested user interfaces (except for dialogs/modal windows), specifically because of the problems you described.

Loose coupling of UI and application functionality is the answer. If you need to spawn a subprocess which needs to be monitored and/or controlled by the user, make the subprocess message based, but without a UI and let the owning VI be the UI and control the sub-VI through messages.

Although still not the best way to do it, but in your case a nice solution without redesigning your application: instead of using the tab to display a message that the VI can't be operated you could use the tab do display the UI components of the sub-VI that is performing operations at that moment. Subpanels is one option here, the other is passing reference of the controls/indicators you want to be able to use and see.

This is ofcourse a very short version of the answer and nothing really implementation specific is mentioned here. I could go further into implementation details, but lets first see how the discussion takes of further.

[WMassey]

I think in general it is bad to have nested user interfaces (except for dialogs/modal windows), specifically because of the problems you described.

Loose coupling of UI and application functionality is the answer. If you need to spawn a subprocess which needs to be monitored and/or controlled by the user, make the subprocess message based, but without a UI and let the owning VI be the UI and control the sub-VI through messages.

Although still not the best way to do it, but in your case a nice solution without redesigning your application: instead of using the tab to display a message that the VI can't be operated you could use the tab do display the UI components of the sub-VI that is performing operations at that moment. Subpanels is one option here, the other is passing reference of the controls/indicators you want to be able to use and see.

This is ofcourse a very short version of the answer and nothing really implementation specific is mentioned here. I could go further into implementation details, but lets first see how the discussion takes of further.

I can see what you suggest working for relatively simple upper and lower level processes but I suspect that if there is a moderate amount of complexity at ether level then this would either present a UI that is too complex or else too cumbersome to build and maintain.

For example, one piece of the system I'm working with concerns multiple (6-to-13) motion control axes. The top-level VI/UI provides a system view of those axes and provides the means of making coordinated moves of multiple axes to selected setpoints. One of the next VI/UI levels down provides the means of operating just one axis including absolute/relative/setpoint positioning, homing, jogging, running to limits, speed adjustment, and control via a joystick. The VI/UI level below that provides means for configuring the many parameters that define how the axis is operated.

I cannot even begin to imagine how I could fit all the controls and indicators associated with running this into one common UI. A tabbed display would be essential at the outset but the programming and maintenance of it would be a nightmare. There has to be a tradeoff made between the slickness of the UI and the complexity of the code behind it.

[Michael Aivaliotis]

I was curious what others are doing about directing the user's focus toward the VI (or VIs) that have execution focus and away from VI's that have lost execution focus because one of their subvi's has it?

I have a user who has difficulty keeping this straight and I would like to try to smooth things out in this area. The LabVIEW system is somewhat complex with as many as three top-level VI's running at one time controlling various pieces of hardware and the user switches back & forth between them by either clicking the window or pulling it up off the WinXP task bar. This part of it works fairly well and is how the user wants it to work.

Where the trouble comes in is when one of the top-level VI's has a subVI window open that has execution focus. At this point, if the user expands the upper-level window off the taskbar (to where it was automatically minimized when the subVI window opened) he will find that it is no longer responsive because it is waiting for the open subVI to complete.... snip

Are there other, better ideas out there?

Well, why put the burden of figuring out which panel is active on the operator? It's the developer's job to make this obvious right?

One solution is to hide the panel that does not have the focus. Programming this is easy but the problem is that the operator will be confused when different panels become visible or invisible. The reason behind this behavior is not immeadiatly apparent to them.

Another solution is to leave everything as it is and just flash the titlebar of the VI which has the focus. This can be done using the windows API utilities that are available on NI's site and other places (i wish I had the link handy). I believe this will even flash the bar if it is minimized.

[WMassey]

Well, why put the burden of figuring out which panel is active on the operator? It's the developer's job to make this obvious right?

One solution is to hide the panel that does not have the focus. Programming this is easy but the problem is that the operator will be confused when different panels become visible or invisible. The reason behind this behavior is not immeadiatly apparent to them.

Another solution is to leave everything as it is and just flash the titlebar of the VI which has the focus. This can be done using the windows API utilities that are available on NI's site and other places (i wish I had the link handy). I believe this will even flash the bar if it is minimized.

I agree that it is the developer's job to make it obvious, hence the question in the first place. But with that said it also has to be implemented using practical, understandable and maintainable code and I always assume that it will be someone other than myself who might have to provide that maintenance.

Your idea of flashing the title bar is a good one. I think the link you are referring to is this one Windows API Function Utilities (32-bit) for LabVIEW (at NI).

It has also occurred to me that I can tinker with the actual window title as well.

I might also be able to play with window transparency using a VI I found in another area of this forum.

I think if the user were to see a ghost window that included the words "no focus" in the window title then they might get the hint that they need to look somewhere else to find a button they can poke. :laugh:

[WMassey]

FWIW, the attached LLB has a demonstration of what I've worked out so far for this. I've only tried on two differnt systems so far and while it works on both, on one of them there seems to be a lot more flickering of the WinXP window as it makes a switch into an enhanced display properties mode that supports transparency. I suspect it may be caused by differences in how the video drivers on the two systems handle transparency.

Download File:post-2800-1127195063.zip

[WMassey]

FWIW, the attached LLB has a demonstration of what I've worked out so far for this.

A couple of the LLB subVIs need to be updated.

The one that finds open subVIs was also picking up windows associated with a VI (like the block diagram window and probe windows) resulting in multiple identical entries in the array being returned. It's been fixed so now it just returns one entry per VI.

The one that returns a WinAPI refnum based on a window's name has been updated to account for more variations that are possible for a LabVIEW window name. It's amazing how many of these that there are!

And, for the Windows API to return a refnum, the match with what you see in the title bar has to be exact.

For example, for a VI named XXX.vi the possible LabVIEW window names include:

XXX.vi

XXX.vi Front Panel

XXX.vi *

XXX.vi Front Panel *

and if it has a window title of ABC too, then these variations get added:

ABC

ABC [XXX.vi]

ABC [XXX.vi] *

ABC [XXX.vi] Front Panel

ABC [XXX.vi] Front Panel *

The "Get Window RefNum.vi" in the "Windows API Function Utilities" referred to earlier in this thread assumes you are passing it the actual title bar text. And since, to the best of my knowledge, LabVIEW itself provides no means of providing what it actually places in the window title bar, you have to try all the various permutations. :headbang:

Download File:post-2800-1127316604.vi

Download File:post-2800-1127316631.vi

[klessm1]

And since, to the best of my knowledge, LabVIEW itself provides no means of providing what it actually places in the window title bar, you have to try all the various permutations.

Doesn't LabVIEW give you the actual window title with the FP Title property? The only issue I see with that is if you are managing windows that are not running. Are not all of the vi's you are managing running when you are switching focus?

[Yair]

Doesn't LabVIEW give you the actual window title with the FP Title property? The only issue I see with that is if you are managing windows that are not running. Are not all of the vi's you are managing running when you are switching focus?

I have had cases where I did testing on VIs which weren't running.

Warren, there is one way you can get rid of your Aargh!!! - use the VI class properties FP.CustomTitle, FP.Title, Name and the ones in the modifications section to determine what the title will be. That way you don't have to try and then check for errors.

[WMassey]

Doesn't LabVIEW give you the actual window title with the FP Title property? The only issue I see with that is if you are managing windows that are not running. Are not all of the vi's you are managing running when you are switching focus?

No LabVIEW definitely does not give you the actual exact window title in all cases.

It's close enough for a human to understand but these computers are so damned literal that sometimes it just doesn't work for them.

No, not all the windows I am managing are, in every case, running. Built into the llb/routine/system I supplied is an independent hidden background routine that does cleanup (restores a no-transparency state) to any windows left partially visible if the main routine is aborted. In this case the cleanup routine will then be changing the appearance of VIs that are not running before it itself exits.

[WMassey]

I have had cases where I did testing on VIs which weren't running.

Warren, there is one way you can get rid of your Aargh!!! - use the VI class properties FP.CustomTitle, FP.Title, Name and the ones in the modifications section to determine what the title will be. That way you don't have to try and then check for errors.

Yes, I suppose you are right.

I could find all the various title-bar-impacting properties of a VI and figure out how changes in each cause the title bar to change and from that build up a text string that should match.

That is to say it should match just as long as the state of the VI does not change between the time when I get the state and when I get the refnum to the window. There is a small window of opportunity there for things to change.

The attached VI demonstrates what you suggest I think.

When I was doing this it just seemed easier to try all the various permutations and use the one that didn't return an error.

Download File:post-2800-1127389150.llb

[jpdrolet]

A couple of the LLB subVIs need to be updated.

The one that finds open subVIs was also picking up windows associated with a VI (like the block diagram window and probe windows) resulting in multiple identical entries in the array being returned. It's been fixed so now it just returns one entry per VI.

The one that returns a WinAPI refnum based on a window's name has been updated to account for more variations that are possible for a LabVIEW window name. It's amazing how many of these that there are!

And, for the Windows API to return a refnum, the match with what you see in the title bar has to be exact.

For example, for a VI named XXX.vi the possible LabVIEW window names include:

XXX.vi

XXX.vi Front Panel

XXX.vi *

XXX.vi Front Panel *

and if it has a window title of ABC too, then these variations get added:

ABC

ABC [XXX.vi]

ABC [XXX.vi] *

ABC [XXX.vi] Front Panel

ABC [XXX.vi] Front Panel *

The "Get Window RefNum.vi" in the "Windows API Function Utilities" referred to earlier in this thread assumes you are passing it the actual title bar text. And since, to the best of my knowledge, LabVIEW itself provides no means of providing what it actually places in the window title bar, you have to try all the various permutations. :headbang:

And you forgot the option "Show revision number in title bar" that adds "rev. nnn" to the title bar...

[WMassey]

And you forgot the option "Show revision number in title bar" that adds "rev. nnn" to the title bar...

That's one I quite honestly never have heard of or seen.

I just looked for a way to set it in the VI Properties panel and didn't find it and looked for it in a VI property node and didn't see a way to set it there either.

Where is it found?

Never mind. I just found it under Tools > Options > Revision History and it would only seem to apply to the History window.

"Help" says this:

"Show revision number in titlebar

[WMassey]

The "Get Window RefNum.vi" in the "Windows API Function Utilities" referred to earlier in this thread assumes you are passing it the actual title bar text. And since, to the best of my knowledge, LabVIEW itself provides no means of providing what it actually places in the window title bar, you have to try all the various permutations.

While playing around with the scripting stuff I noticed a "FP.OSWindow" property that I had not seen before.

I suspect it appeared once I added one or the other of these lines to my LabVIEW.INI file:

SuperPrivateScriptingFeatureVisible=True

SuperSecretPrivateSpecialStuff=True

The context help gave me hope that it would provide something that could be turned into a refnum for the WinXP window so I tried it out and it works!

The attached VI (LV v7.1.1) will take a VI Name (not a Window name) and return the refnum to the window if it is open.

Download File:post-2800-1127861661.vi