From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
> This was the one that we decided was the best alternative given usability concerns, implementation details, and developer resources.
...and yet the proposed implementation is not so usable if the case structure is very large. Did you consider at least putting the identifier on the same side as the case selector terminal? On very wide diagrams (which are common) it would at least be good to see the identifier before you add additional logic to the case selector input...
Did you consider at least putting the identifier on the same side as the case selector terminal?
As I mentioned, we looked into several designs and placement alternatives. This included placing the glyph in the lower left. I'd have to talk to the team to remember why we didn't go with that location.
For larger structures where you can't see the entire structure, you're still able to right-click the border and see the current Case Insensitive Match setting.
> I'd have to talk to the team to remember why we didn't go with that location.
My guess: Dragging the case selector to the very bottom would then clash with the case identifier... Of course, the select list would be the obvious place to put it but that particular choice probably required too many developer resources!
Shame, because the identifier needs to be as visible as possible to serve its purpose. Bottom-right feels like a slightly disappointing outcome for a generally good feature.
> but that particular choice probably required too many developer resources!
No, it wasn't developer resources. The ring is a problematic choice because we would be adding this glyph to already shipping VIs. Putting the glyph on the ring would eclipse text that is already in the ring. Rings are frequently alredy clipping text; reducing the space for visible text further didn't seem likely to be appreciated.
The four corners are the locations where the text is least likely to have existing elements. A tunnel can be in the very corner, but it is so unusable from every direction that it is basically unheard of. The top corners are eclipsed by the selection ring. Frequently the case structure is shrunk until the selection ring is the full width of the top. So it comes down to the bottom corners.
After having it for a couple months, I'm tempted to say it should move to the left bottom corner so it is in line with the selection terminal -- it becomes something your eye catches on as you're watching execution highlighting and thinking about which frame is about to be selected. Would that be an improvement?
Yes, IMO bottom-left would be much preferred. Your observation was the same as mine: That the identifier relates most to the case selector, and that having the two items near each other seems to make more sense. Coupled with the fact that the bottom-right corner may be (very) far away seals the deal for me.
Available in LabVIEW 2015 and later