| | [ Return to Bugs & Features | SVN ⇄ GIT ]
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 |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | aaasdf |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | None |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #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 ]
|
| |
