Bug #1473
closedwt-3.2.3-rc1 Resizing layout problem within StdGridLayoutImpl2.js
0%
Description
If a widget is hidden within a grid cell not all cells are resized correctly if the browser window size is changed. To reproduce this behaviour use the following test app:
http://pastebin.com/ZJXcMU7w
After hitting the "Apply" Button the middle right-most widget "Details" will be hidden. When you now resize the browser window the top and bottom cells (rows 0 and 2) are not resized anymore. If you hit the "Apply" button again the "Details" widget will show up again and the resizing works fine.
Files
Updated by Koen Deforche over 11 years ago
- Status changed from New to Resolved
- Assignee set to Koen Deforche
- Target version set to 3.2.3
Hey,
It was the overspanned cells that were confused by the column that disappeared (because the only widget in it got hidden). In general, you will find that more things may not work reliable with these overspanned widgets, and I would recommend to simply use nested layouts in this case (WVBoxLayout + WHBoxLayout) for the 3rd row, which has exactly the same functionality. This should (will?) also solve the glitch that the resize handle is not removed when you hide the column.
Regards,
koen
Updated by Stefan Ruppert over 11 years ago
Koen Deforche wrote:
and I would recommend to simply use nested layouts in this case (WVBoxLayout + WHBoxLayout) for the 3rd row, which has exactly the same functionality. This should (will?) also solve the glitch that the resize handle is not removed when you hide the column.
Hi Koen,
I tried a WVBoxLayout + WHBoxLayout combination and it works fine except if I open a dialog with a positionAt(widget) where the widget is in a WHBoxLayout I get the result shown in the attached screenshot. Also the listview of a WComboBox will move the WTableView to a wrong position. Any idea?
Stefan
Updated by Koen Deforche over 11 years ago
- Status changed from Resolved to InProgress
Hey Stefan,
No, no idea, but positionAt() indeed needs to deal properly with absolutely positioned ancestors, so I guess something is not quite right there.
Regards,
koen
Updated by Stefan Ruppert over 11 years ago
Hi Koen,
Koen Deforche wrote:
No, no idea, but positionAt() indeed needs to deal properly with absolutely positioned ancestors, so I guess something is not quite right there.
I think this is a side effect of the bug reported with #1483. I hope when #1483 is fixed this problem should be away also! ;-)
Stefan
Updated by Koen Deforche over 11 years ago
- Status changed from InProgress to Feedback
Hey Stefan,
And, was it a side effect or do you still have this problem ?
Regards,
koen
Updated by Stefan Ruppert over 11 years ago
Hi Koen,
yes it was the side effect. The problem was fixed with the changes of #1483.
Thanks,
Stefan
Updated by Koen Deforche over 11 years ago
- Status changed from Feedback to Resolved
Great !
Regards,
koen
Updated by Koen Deforche over 11 years ago
- Status changed from Resolved to Closed