[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #2131

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  greg.ercolano 18:19 Jan 21, 2009	foo.html 17k

Trouble Report Comments:

	Name/Time/Date	Text
	#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.

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