| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3014
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | drag word select buggy |
|---|
| Version: | 1.3-current |
|---|
| Created By: | elaforge |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.3 (SVN: v10383) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | elaforge
11:30 Dec 10, 2013 |
| From the mailing list:
There's a bug when dragging word select in Fl_Input_. You can see it
by running test/input, typing a bunch of words, double clicking a word
in the center and dragging right. Every pixel of the drag, it extends
the selection by one word to the *left*.
I tracked this down to the strange behaviour of the word_start() and
word_end() methods. Namely, instead of just finding the start of the
word under the index, if the index is already at the beginning of a
word, it will find the start of the previous word. I think this is
confusing and hard to use, and presumably the author of handle_mouse()
would agree with me. It's also inconsistent with line_start() and
line_end().
Unfortunately, the existing word_start() and word_end() behaviour is
documented, so there may well be people relying on it. So I add two patches. incompatible.patch alters word_start() and word_end(). compatible.patch leaves them alone (but I couldn't resist cleaning the doc and code a bit), and adds static strict_word_start() and strict_word_end(). | |
| |
| #2 | AlbrechtS
11:16 Oct 06, 2014 |
| Considering for inclusion in 1.3.3.
FWIW, mentioned discussion was in fltk.coredev.
Title: "Fl_Input_ word select drag bug". | |
| |
| #3 | AlbrechtS
05:21 Oct 16, 2014 |
| Fixed in Subversion repository.
Thanks for the patch(es).
I used "compatible.patch" with a few changes.
One minor point was that input type FL_SECRET_INPUT wasn't taken into account, so that you could find word boundaries in secret input fields by double-clicking and dragging.
I also removed all formatting-only changes for clarity of changes.
My tests showed that this is now working as I expect. Please confirm that it works for you. TIA. | |
| |
| #4 | elaforge
11:31 Oct 16, 2014 |
| Works for me, thanks for applying! | |
| |
| #5 | AlbrechtS
07:30 Oct 17, 2014 |
| You're welcome, and thanks for feedback.
STR closed. | |
[ Return to Bugs & Features ]
|
| |
