LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
michael.lambert

Case Structure case sensitivity default setting

Status: New

This subject has been touched on briefly, but only in a post that started out just suggesting an indication of whether or not a case structure is case insensitive. This has been implemented since then, of course.

 

What I'd like to bring to the surface again is the case sensitivity. The mention of this in the previous post was suggesting that case insensitivity be made the default. I don't agree with this - especially with the repercussions it could have on converting older code. 

 

However, I think it would certainly be useful and acceptable to add a checkbox to the "Block Diagram >> General" options for "Case structures case insensitive by default" (see screenshot). This would not break previous code, since turning it on would only effect case structures created after turning it on. Additionally, the "default default" would still be case insensitive, but programmers that do use string-based case selection could leverage this to their advantage (and not deal with forgetting to turn it on via the right-click option).

3 Comments
AristosQueue (NI)
NI Employee (retired)

I'm uncomfortable with this because turning on case insensitivity seems like such a low impact action, but the performance ramifications are huge. Forgetting to do it on one deep case structure could kill performance. It may shift thread scheduling. It would inject the jitter of memory allocation into a real-time system. It isn't a setting that should be casually left enabled, even if you're a user where most of your case structures prefer case insensitivity. I think it should always want to snap off unless you proactively say, "Yes, this one also."

 

I don't know any way to draw the case structure such that enabling this option seems more threatening.

 

I will recommend NI leave this idea OPEN. Personally, I think it is bad. It is my job to be protective of G users -- we have plenty of users who aren't programmers and wouldn't recognize the implications of toggling such an innocent setting. We try to provide power and ease of use without encouraging users down a bad path. But maybe I'm being too protective in this case -- the string performance concerns are much smaller than when I started programming. I'd like to hear more community feedback on the topic.

tst
Knight of NI Knight of NI
Knight of NI
@michael.lambert wrote:

This subject has been touched on briefly, but only in a post that started out just suggesting an indication of whether or not a case structure is case insensitive.


This was actually discussed in more detail here, including the environment option you suggest - https://forums.ni.com/t5/LabVIEW-Idea-Exchange/String-case-structures-should-default-to-being-case-i...

 

To be clear, neither change would break older code - with or without an environment option, existing case structures would not be modified and the insensitive option would only be applied to new case structures.

 

My feedback to AQ is that I generally don't care about the performance implications in most cases (unless you can tell me that they are significantly more pronounced than I thought they were), but some users in the other thread did say they do prefer the existing situation (although no one seemed to cite performance as the reason).


___________________
Try to take over the world!
michael.lambert
Member

Hi AristosQueue and tst.

 

Thank you both for the feedback. @AristosQueue, I appreciate you sharing your understanding of the back-end ramifications of providing such an option - something that most people would not realize. I would also be interested to have someone chime in on the performance impact in regards to strings in the more current versions of LabVIEW. 

 

@tst, that was the only related post that I could locate as well. Since it was from 2010 and the ultimate idea suggested in it (to have a glyph on the case structure to indicate case sensitivity) has already been implemented, it seemed most logical to begin a new thread.