Text editing with ctrl + arrow keys

[leon42]

When I try to select a word or more words I currently have two options. The first one is to hold down shift and select on letter by letter basis which is slow. The second one is to select with help of mouse, which is error prone.

Normally all text editors have options to move for 1 word left or right by ctrl + left arrow or ctrl + right arrow. The same goes for selecting a word (ctrl + shift + arrow). I would like this functionality to be supported by LabVIEW at least on block diagram, VI documentation, enum editing.

[Its_Me_Ashiq(ஆஷிக்)]

This feature is already present at-least from LabVIEW 2015.

I couldn't even find any property to Enable/Disable it (as we do for QuickBold in LabVIEW.ini file).

It seems like a default feature in there!!!

LabVIEW Text Editing Feature.mp4 

[leon42]

It does not work for me in same way as it works for you.

I have tried this on my computer and one other computer. On mine it does not work, but on the other computer it does. The difference between the computers is the setting in Region -> Format. If I choose English(United States) or English(United Kingdom) the ctrl + left works. If I choose either English(Slovenia) or just Slovenia, it does not work. If I choose English(Germany) it also does not work.

I think this setting should not interfere with the shortcut.

And this raises an additional question. What other settings / configurations are dependent on your system locale in LabVIEW 😟

[Its_Me_Ashiq(ஆஷிக்)]

---

@leon42 wrote:

I have tried this on my computer and one other computer. On mine it does not work, but on the other computer it does. The difference between the computers is the setting in Region -> Format. If I choose English(United States) or English(United Kingdom) the ctrl + left works. If I choose either English(Slovenia) or just Slovenia, it does not work. If I choose English(Germany) it also does not work.

---

Then I'am giving Kudos to get this feature for all the users.

[Babel]

@leon42 , my LabVIEW R&D colleagues brought this to my attention. However, I cannot reproduce your issue.  I tried switching my regional settings (user locale) to English (Slovenia), also switched my keyboard layout to that country, but the keyboard shortcuts to fast select word by word still work for me.  The only thing our documentation states is that the behavior is different when dealing with double byte chars (Asian languages).  I will ask my Localization QA engineers colleagues if they have any more luck reproducing this issue.

Quick questions for you:   Does it work in other apps like Notepad?  Could "Sticky keys" be somehow turned on?  Could any other application or driver somehow conflict with these shortcut keys?  What version of Windows are you on?  Have you seen this on multiple machines, or just one?

Thank you.

[Babel]

I was able to reproduce the issue when "Language for non Unicode programs", a.k.a.  the System Locale or Windows Code Page is set to Slovenia (code page 1250)  AND the format settings configured to English (Slovenia).  If either one is set differently, then the feature works. 

AND 

Now that this is understood, I will report the findings to the development team.  Your report will probably be turned into a bug rather than a new idea.   Thank you for reporting it.

[leon42]

I am glad to help. I guess Slovenian is not the only problem here.

Looking forward to the fix. Cheers.

[Christina_R]

I've moved this issue to Bug 1341237. However, it isn't being prioritized for a fix at this time because we believe the configurations that have this problem aren't common.

[tst]

---

However, it isn't being prioritized for a fix at this time because we believe the configurations that have this problem aren't common and that using "English (United States)" as your format locale is a reasonable workaround.

---

I can understand not fixing this because it's not common (although if it happens with many languages I expect it is actually fairly common) or because having to select one character at a time is not that big an annoyance, but I wouldn't call using the US locale a reasonable workaround, because the inconvenience of having the entire OS in US format is significant if that's not the format you want. I would suggest removing that justification from the bug.

[Christina_R]

I would suggest removing that justification from the bug.

---

That's reasonable. I've revised the justification.