Triple-click has changed in 2.9

[Phil Davis]

Hi Paul,

I concur.

In the transition from Rev 2.8.1 to 2.9.0 (Mac and Windows versions at 
least), there has been a change in double-click-text and 
triple-click-text behaviors.

The 2.8.1 behaviors are exactly the same as they are in the several 
other apps on each platform where I tested this. The 2.9.0 behaviors 
aren't.

In 2.9.0, it seems the trailing CR gets selected with the rest of the 
line upon triple-click, causing any replacement text to be inserted at 
the beginning of what was originally the line following the selected 
line. So the list linecount is shortened by one line.

I believe it's a bug!

Phil Davis



Paul Looney wrote:
> Revvers,
> I am having a problem with Rev 2.9 and OS X 10.4.11. If you can 
> confirm this is also a problem on Windows and Linux, I'll post the bug.
>
> Previously (through version 2.8.1) one triple-clicked to select an 
> entire line of text.
> In Rev. 2.9 a triple-click also selects the return character at the 
> end of the clicked line.
> So, if you triple-click to select a line of text between two other 
> lines of text, then begin typing, the third line will have jumped to 
> the end of the second.
> This creates massive havoc with linked scrolling fields:
> 1. Triple-click to change a quantity
> 2. Attempt to edit the selection
> 3. Any quantities below have jumped up one line
> 4. Any descriptions, or prices below that line are now out of alignment.
> 5. Because there is code to keep the fields in sync, hitting Return in 
> the problem field (to fix the problem) will just add a blank line to 
> all of the linked fields - without fixing the problem.
>
> In the word processors and spreadsheets I've used to date, 
> triple-clicking does not select the final return. They work as Rev. 
> used to work.
>
> By the way, using a triple-click was a workaround for Rev's 
> non-standard way of handling the double click:
> Double-clicking in Rev works for selecting quantities or single word 
> descriptions but on prices containing both integers and fractions 
> (123.45) it only selects one side of the decimal. Making it more 
> difficult than needed for a user to change a price. Triple-clicking 
> was a way of selecting, and editing the entire price.
>
> In word processors and spreadsheets I've used to date, double-clicking 
> will select the entire number - if the period/decimal is the final 
> character of text, the period will not be selected.
>
> It would be nice if both double-click and triple-click worked in the 
> standard way, but it is essential that triple click work right - as it 
> did.
>
> Is this a problem on Windows and/or Linux?
> Was the problem created by the new Unicode extensions in Rev?
> Is there some reason why it needs to work this way?
>
> By the way, using the linked scrolling fields was a workaround to get 
> right-aligned columns. A true table field would fix a host of 
> problems!  ;-)
>
> Sincerely,
> Paul Looney
>

-- 
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net