[ Return to Bugs & Features | Roadmap 1.1 ]
|Status:||1 - Closed w/Resolution|
|Priority:||4 - High, e.g. key functionality not working|
|Scope:||3 - Applies to all machines and operating systems|
|Summary:||Fl_Text_Display::wrap_mode() doesn't work correctly|
|Fix Version:||1.1-current (SVN: v5194)|
Trouble Report Files:
Trouble Report Comments:
11:41 Apr 03, 2006
|Wrap mode produces wrong wrapping and display text at wrong positions. I even once saw one text line doubled. The problem appears when long lines with wrapped text are being scrolled into the visible area. |
To reproduce the problem, I added one line to fltk-1.1.7/test/editor.cxx to enable wrap mode:
> diff -u editor.cxx.ori editor.cxx
--- editor.cxx.ori 2006-04-03 20:19:00.218750000 +0200
+++ editor.cxx 2006-04-03 20:20:17.296875000 +0200
@@ -766,6 +766,7 @@
sizeof(styletable) / sizeof(styletable),
'A', style_unfinished_cb, 0);
+ w->editor->wrap_mode(1,40); /* TEST WRAP MODE */
w->callback((Fl_Callback *)close_cb, w);
Then, compile and link the editor demo program and enter the following text:
This is a very very very very very very very very very very very very very long line
The first line starts with "This" and ends with the word "line" - this is the line to show the wrong wrapping. This can be seen in e01.gif (I hope that I will be able to attach the gifs to this message).
Now, shrink the editor window to show only about 6-7 lines (e02.gif).
Then, scroll the top 4 lines out of the display (e03.gif).
Then, use the vertical scroll bar (with the mouse) to scroll the top lines back into the display, one by one. The results can be seen in the files e04.gif - e07.gif). There appears an embedded <nl> in one line, then the lines are splitted again, but at a wrong position. Then, an empty line appears, before the scroll bar is at its top position (e05.gif). Moving the scrollbar further up doesn't change the display any more (e06.gif).
Now, clicking into the display, puts everything in order again (e07.gif).
This is more than a cosmetic problem, because users can't see the text they typed as they did.
Another effect is that the cursor can move outside the display (at the bottom) when typing text in a long/wrapped line.
I'll attach all the gifs in the file "wrap_mode.zip".
This is tested with 1.1.7 on windows.
14:52 Apr 27, 2006
|This is probably the reason why 'wrap_mode()' was never documented. It was simply not implemented all the way. Sigh. ;-) ||
09:39 Jun 13, 2006
|I think it's done ! :-) |
The attached patch file against FLTK 1.1 SVN r5191 will fix all scrolling and positioning bugs that I could find. There are also a _few_ modifications WRT debug statements and formatting.
The main problem was _simply_ :-) to remove "buffer()->" at about 7 (seven!) places. The hard thing was to find these.
I'm very confident that this patch fixes the bugs and has no drawbacks for the non-wrapping mode, because the modified functions all check, if wrap mode is on, and otherwise call the related buffer() method.
The patch file will be: Fl_Text_Display_r5191.patch
09:50 Jun 13, 2006
|There is one thing left, that is not a bug, but more a matter of taste. Now the keys Pos1 and End move to the start and end of a _real_ line break, as opposed to the start and end of a wrapped line on the display. |
I would tend to modify this, because this would be like a text processing program like OpenOffice _does_ handle it (just tested). IMHO, this would be the best choice, when the text is long with little or no real line breaks.
However, this may be different, if the text is something like a source file, where some lines just don't fit into the display area ...
BTW, this modification would have to be in Fl_Text_Editor.cxx.
12:11 Jun 13, 2006
|Fixed in Subversion repository. |
Thank you very much for your patch!
[ Return to Bugs & Features ]