STR #1227

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

STR #1227

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:Fl_Text_Display::wrap_mode() doesn't work correctly
Created By:AlbrechtS
Assigned To:matt
Fix Version:1.1-current (SVN: v5194)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 AlbrechtS
11:41 Apr 03, 2006
#2 AlbrechtS
09:41 Jun 13, 2006
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 AlbrechtS
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[0]),
                              '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 "".

This is tested with 1.1.7 on windows.

#2 matt
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. ;-)  
#3 AlbrechtS
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

#4 AlbrechtS
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.

Thoughts, anybody?

#5 matt
12:11 Jun 13, 2006
Fixed in Subversion repository.

Thank you very much for your patch!
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.