[ Return to Bugs & Features ]

STR #1919

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  aaasdf 14:27 Apr 15, 2008	borkedtile.cxx 1k
	#2  aaasdf 02:33 Apr 18, 2008	tile_resizablechild.patch 1k
	#3  AlbrechtS 14:56 Jan 14, 2023	str-1919_fixedtile.cxx 1k

Trouble Report Comments:

	Name/Time/Date	Text
	#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: https://www.fltk.org/strfiles/1919/str-1919_fixedtile.cxx 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.

[ Return to Bugs & Features ]