Triple-click has changed in 2.9
revdev at pdslabs.net
Tue Jun 3 10:54:17 CDT 2008
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
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
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!
Paul Looney wrote:
> 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
> 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! ;-)
> Paul Looney
Professional Software Development
More information about the use-livecode