STR #1507

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 #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
Created By:jharms
Assigned To:matt
Fix Version:1.1-current (SVN: v5606)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 jharms
23:43 Nov 22, 2006
#2 greg.ercolano
11:03 Nov 23, 2006
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#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, (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
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: 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):

..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.
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 ''.