STR #1919

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 ]

STR #1919

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:3 - Moderate, e.g. unable to compile the software
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Fl_Tile uses resizable() interface for different functionality
Created By:aaasdf
Assigned To:AlbrechtS
Fix Version:None
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 aaasdf
14:27 Apr 15, 2008
#2 aaasdf
02:33 Apr 18, 2008
#3 AlbrechtS
14:56 Jan 14, 2023
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 aaasdf
14:27 Apr 15, 2008
There's also a bug that has been there for a long time and hasn't been fixed yet.  Setting a child widget of an Fl_Tile to be resizable leads to some weird stuff.
Let's say you have this tile layout:

|                |                   |
|    Box A       |      Box B        |
|   RESIZABLE    |                   |
|                |                   |
|                |                   |
|   Box C        |     Box D         |
|                |                   |

You can't resize Box A at all if you try dragging the border between Boxes A and B, or the one between Boxes A and C, i.e. the borders directly adjacent to Box A.  When your cursor is over the A-B or A-C borders, it doesn't change its appearance (it stays a 'normal' arrow while it should be that double-arrow thingy) and just won't let you resize.

Now you can resize Box A vertically by dragging the B-D border, but:
- shrinking will work fine (but Box A doesn't get redrawn),
- growing will NOT redraw Box A, and will leave a trail of whatever was there before (most likely a trail of the border being dragged)
Same goes for horizontal resizing: shrinking is OK, growing doesn't redraw.

Everything is drawn OK when you resize the window, though (shrinking AND growing).

Also, the "border" isn't drawn when Box A has been shrunk.

Attached: example of the problem
#2 aaasdf
02:38 Apr 18, 2008
I have posted a patch that works for me.

PS- This is not important but there's a mistake in borkedtile.cxx, the line:
   Fl_Tile* o = new Fl_Tile(0, 0, 350, 335);
should read
   Fl_Tile* o = new Fl_Tile(0, 0, 350, 330);
because if you let the tile's height as 335 while the window's height is 330, you will be able to mess with the bottom-most border of the tile.
#3 matt
13:07 Apr 21, 2008
The "resizable()" widget works differently in Fl_Tile than it does in Fl_Group. To quoate the Fl_Tile documentation:

"Fl_Tile allows objects to be resized to zero dimensions. To prevent this you can use the resizable() to limit where corners can be dragged to."

I do not like the abuse of some API for an entirely different functionality, but this is part of 1.1 and can't be changed. I will put this on the Bug list for 1.3.
#4 AlbrechtS
15:02 Jan 14, 2023
As Matt already wrote, Fl_Tile is a special widget with special features, even if (ab)using the resizable() widget in its own way is surprising and not a good choice in the first place.

However, it is documented and works as specified - if you use the resizable() widget as designed. I modified the program (borkedtile.cxx) to use an additional (invisible) Fl_Box widget as the resizable() of the Fl_Tile widget and this works fine. See this file:

The behavior of Fl_Tile will not be changed.

This STR is now closed w/Resolution because there's a solution to the problem of the OP.
bottom left image   bottom right image

Return to Bugs & Features ]


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