Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 SmartSelectExtend behaviour with hex numbers

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
alex.postlethwaite Posted - Jul 04 2017 : 11:12:15 AM
I have some suggestions/feature requests for the behaviour of SmartSelectExtend when dealing with hex values.

My ideal behaviour is that the first incremental selection of a number is the significant (number) part, without the base prefix, for example:

Desired behaviour:

If I have the number 0x12ABCDEF and my caret is somewhere between 1 and F the region 12ABCDEF should be selected. When editing hex values, this is the most common part you want to change.

The current behaviour falls short in a few ways:

1. 0x12ABCDEF the region 0x12 or ABCDEF will be selected, depending on the caret position, probably because numbers and letters denote a word boundary.

2. 0xABCDEF the desired region will be selected, but on if the values are uppercase. Using 0xabcdef, the 0x will be included in the region, probably because case changes typically denote the word boundary.

3. 0x6321 the 0x will be included in the selection, probably because the whole thing is numeric.

What do you think about the changes?

I currently have all these options checked:

[X] Start and grow by relatively small increments
[X] Start non-block selections with the current word
[X] Changes in case delimit current word
[X] Underscores delimit current word

Thanks
Alex
4   L A T E S T    R E P L I E S    (Newest First)
alex.postlethwaite Posted - May 03 2018 : 09:59:06 AM
Dredging up an old topic, but forgot to say - Thanks, these changes are great.
sean Posted - Aug 16 2017 : 01:37:10 AM
case=109428 is fixed in build 2231
Dusan Posted - Jul 05 2017 : 10:42:57 AM
Hello Alex.

The behavior you see is by design, but I agree that in case of hexadecimal numbers it is odd.

I have put in a feature request:

case=109428
alex.postlethwaite Posted - Jul 05 2017 : 05:02:24 AM
I should have posted this in the other forum - my mistake. I can't see a way to move it.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000