Menu Ring text string problems

[84berlinetta]

I have stumbled across a LV problem with locating menu rings close to window edges. As long as the list of ring menu entries is long enough to extend beyond the edge of the screen when the menu is opened, the entries in the table are not all visible.

For example: If I set up a menu ring with 4 entries that is located close to the bottom of the screen, a box opens that is large enough to display 4 lines of information, but the top and bottom lines are blank until I scroll down the list. If I select the last item in the list, the next time I select the menu ring I can see all 4 entries. If, however, I select the first entry in the list, the next time I select the menu I get blank lines at the top and bottom of the box once again.


I have heard this is a definite LV problem that has been around for awhile. Has anyone found a work-around for it?

[Greg_McKaskle2]

> I have heard this is a definite LV problem that has been around for
> awhile. Has anyone found a work-around for it?

This action is intentional. The goal is to have the current value open
under the mouse. This is in part so that a double click is less likely
to change the value. It also reminds the user what the current value is
and lets them easily move to adjacent values. I'm not sure what the
current UI convention is for Windows, but the Mac still does this, or at
least something very close to it.

Greg Mckaskle

[Thoric]

I'm reviving this old thread because after 16 years it appears to still be a cosmetic problem.

Shown below is a VI with the same text ring control placed four times with increasing closeness to the bottom of the screen and I've demonstrated what you get when you select them.

The menu fails to properly display the entries if the control is within, roughly, 20 pixels of the bottom of the desktop area. Note that all four controls render the same if I move the window up the screen and away from the bottom of the desktop, so this rendering choice is related to on-screen position, not Front Panel position.

I don't accept this is intentional, the large blank area is very undesirable and gives the impression of a rendering mistake. I dislike it, and need a workaround if anybody knows of one please?

[brentjustice]

ugh, just bumped into the issue described here.

Anyone find any workarounds?

[tst]

I was not familiar with this, but a quick test shows that a system ring doesn't have this behavior. I don't know if that can work for you in terms of UI appearance. It's possible that the other types of controls don't have this either (Silver, NXG, etc.). Other workarounds would be using .NET or rolling your own with XControls or QControls. Not ideal.

[brentjustice]

oh wow, you're totally right.  The system control must inherit drop-down logic must be different

[brentjustice]

I don't love it, but this seems like a note-worthy workaround:
On Mouse-Down?, if you rearrange the StringsAndValues such that the current value string is at the bottom of the list, then you will never get the annoying bug being discussed here since the current value will always be on-screen.

[brentjustice]

Ok, I finally found a workaround that makes me happy.  (VI attached)

@tst already pointed out how the system ring's menu bar doesn't have the same bug.  (NI says feature, I say bug.)

I discovered that I can overlay a NXG ring directly over-top of a system ring.
The NXG ring is nicer in that it lets me customize color and style.
I use the MouseDown? event to then turn off visibility of the NXG ring.
This then activates the menu from the System ring.
I also then use the MouseDown event to turn the visibility of the NXG ring back on.

Conveniently, this string of events work out perfectly so that the System Ring is never actually visible on the UI.

Hacky, but low effort and works well