STR #1507: Fl_Input in Fl_Tile in Fl_Scroll gets no FOCUS

STR #1507

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_Input in Fl_Tile in Fl_Scroll gets no FOCUS
Version:	1.1-current
Created By:	jharms
Assigned To:	matt
Fix Version:	1.1-current (SVN: v5606)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	jharms 23:43 Nov 22, 2006

rt.cc
2k

#2	greg.ercolano 11:03 Nov 23, 2006

simplified.cxx
1k

Trouble Report Comments:

#1	jharms 23:43 Nov 22, 2006

I run the Table of Cells-Demo and cannot click on widgets on the line before the last line after scrolling. without scrolling everything is working fine. The widget s a Fl_Input inside a Fl_Tile inside Fl_Sroll. (Fl_Tile, RateTable, http://seriss.com/people/erco/fltk/#CellTable (Ercos Cheat Page )) I tried the Versions: 1.1-5479, 1.1-5539 Installation: ./configure --prefix=$HOME/ --enable-xft && make && make install to compile attached file: $HOME/bin/fltk-config --compile rt.cc OS: ubuntu 6.06 GCC: 4.0.3

#2	greg.ercolano 11:02 Nov 23, 2006

FLTKer's note: this is *not* Fl_Table, just a regular layout of FLTK widgets in a scroll. Interesting bug.. it seems to be a redraw problem of some kind, possibly to do with Fl_Tile, Fl_Scroll, or the mix of Fl_Tile + Fl_Scroll. If I comment out the Fl_Tile from the hierarchy, then it works fine. See attached 'simplified.cxx' which also shows the problem. I wouldn't rule out a bug in how I'm using Fl_Tile, but I think I'm using it correctly. It almost seems like a redraw problem: after I scroll many widgets won't work correctly; when I click and start typing, no cursor or text appears, though the mouse changes as if the widget was actually working. But if I resize the window just a little bit (even one pixel), the text I typed suddenly appears, and all the widgets starting working normally (until I scroll again).

#3	wilson.afn 17:24 Nov 23, 2006

This appears to be another manifestation of the "gap-tooth tesselation" problem: http://www.fltk.org/str.php?L1497 except that Greg knocked out *all* the teeth on the right hand side of the split.

#4	greg.ercolano 01:46 Nov 24, 2006

BTW this doesn't appear to be recent.. I can replicate in 1.1.4, 5, 6, 7 and current. I'm thinking it's purely a redraw problem in Fl_Group::draw() caused by Fl_Scroll. I can 'fix' the program by making a timer that calls tile's redraw() every 5 seconds; when I scroll and then type into the widgets, no text appears until the timer triggers.. then the screen starts working again; all widgets operate normally untill I scroll again.. then things won't work again until the timer goes off. It's also interesting that even just scrolling a single pixel suddenly seems to cause /all/ the Fl_Inputs to stop drawing correctly when eg. typing into them, even though the widgets appear to be operating correctly (just not drawing the changes). So events are all working correctly, focus changes are occuring. Also, if I scroll a LARGE amount quickly, then it seems like only the widgets that were 'revealed' by the scroll work ok, but the widgets that were 'scrolled' (had their pixels "slid around" onscreen without redrawing) don't continue to operate. Kinda smells like Fl_Scroll sets a clip of some kind that causes fl_not_clipped() to return 0 on all the widgets that were scrolled but not redrawn. I verified this by adding some printf()s to Fl_Group::draw_children() and Fl_Group::udpdate_child(). (I was pointed at Fl_Group because Fl_Tile derives from Fl_Group) It seems that: 1) All widgets that *were* draw()n after a large scroll that operate correctly all pass the fl_not_clipped() test (fl_not_clipped() returns '1' for these widgets), so they get redraw()n correctly. 2) All widgets that were just 'slid around' onscreen *fail* the fl_not_clipped() test (it returns '0'), and don't get their draw() method called, even though their damage() might be set. I'm afraid I'm not smart enough to point to the actual offending code, but it /seems/ like whatever stack fl_not_clipped() is walking is left a /tiny/ window after the scrollbar is moved. If I change the Fl_Tile to an Fl_Group things work again, so it almost seems like the bug is in Fl_Tile somehow, but Fl_Tile doesn't look like it does stuff to the clip stack.. and that's where I lost the trail. (I haven't taken the time to understand Fl_Tile's implementation, in particular its resize() function) The only thing that seems suspicious is Fl_Tile::resize() doesn't call Fl_Group::resize(), it moves the children around itself. In particular: void Fl_Tile::resize(int X,int Y,int W,int H) { [..] // resize this (skip the Fl_Group resize): Fl_Widget::resize(X,Y,W,H); [..] } ..that seems weird because that is probably bypassing a bit of clipping logic in Fl_Group that maybe 'fixes' things. But I'm guessing at this point. I'm pretty sure though about the clip stack being left in a bad state after a scroll of the Fl_Tile widget. HTH

#5	matt 13:33 Nov 24, 2006

No, the problem is the same issue as the Fl_Scroll inside an Fl_Scroll: Fl_Tile reimplements "position()", giving it an entirely new meaning. Fl_Scroll must call "position()" to scroll, but now call the overriden (and wrong) function. The only fix here is to change the API.

#6	danh 11:03 Dec 04, 2006

I've been having troubles with nested Fl_Scroll widgets. I tried renaming the Fl_Scroll::position method to something else, and it appears to solve my problem. It would be really nice if this could be fixed. Although, I don't know if a solution that doesn't change the API is possible.

#7	mike 11:53 Dec 04, 2006

position() is not a virtual method, so the fact that Fl_Tile provides its own implementation will not cause this problem. (position(x,y) is an inline function mapped to resize(), which *is* virtual...)

#8	matt 02:04 Jan 18, 2007

Fixed in Subversion repository. By calling "redraw" on all children inside the tile, a damage region was created before the scrolling was applied, so the actual redraw ended up happening somwhere else, not where the damaged widget was.