STR #2131

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 | Post Text | Post File | Prev | Next ]

STR #2131

Application:FLTK Library
Status:5 - New
Priority:3 - Moderate, e.g. unable to compile the software
Scope:3 - Applies to all machines and operating systems
Subsystem:Example Programs
Summary:test/help: The 'search window' doesn't work for text within <PRE>
Created By:greg.ercolano
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 greg.ercolano
18:19 Jan 21, 2009
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 greg.ercolano
18:19 Jan 21, 2009
Was playing around with the 'search' window in the test/help program;
seems like text within <PRE> is invisible to the search function.

Attached 'foo.html' seems to show the problem; running:

./help foo.html

..and then searching for 'google' and hitting ENTER seems to work.
But type in 'README' or 'adjuster' and hit ENTER, it doesn't find it.
#2 greg.ercolano
16:51 Sep 26, 2010
Problem seems to be this line in Fl_Help_View::find():

topline(b->y - b->h);

..which is executed when there's a match to attempt to scroll the display to the matching string.

The search is working; it's finding the text.
But the (b->y - b->h) seems to be wrong; when doing a match for "README" in the example HTML, b->y is 150 and b->h is 3696. This causes a negative value to be passed to topline(), causing the screen not to move.

Seems that b->y is the y position of the text for the top of the current html 'block' (which in this case is the <PRE> block), and b->h is the height of the entire <PRE> block.

So unless the block is very small, the above code doesn't work.

I think what's needed is to calculate the y position, taking into account the line heights and the number of crlf's encountered to properly calculate the position of the matching text.

Not sure how to do that properly, since line height can vary even within a line (due to multiple font sizes), so I guess taking the 'max' of the char height for all chars in each line, and adding that to the runing position whenever a crlf is encountered might be correct.
#3 greg.ercolano
12:01 Sep 27, 2010
This will probably be painful to fix, since getting the proper position involves calculating line heights.

The way I can think of would be to make some of the logic currently in draw() accessible to search so that the code that parses the HTML can also be used to search for a string, so that the y position of the matching text can be found with the same logic used to draw it.

This would probably mean moving all the code out of draw() to a separate function that could take a few extra arguments (such as an optional search string that would eg. disable the fltk drawing code), and call that function from draw() with the search field set to NULL.

This probably is less hard than it sounds, but..

If no one beats me to it, I'll try to find some time to flesh this out. Comments from devs welcome who are familiar with this code.
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


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