View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0031122||Lazarus||Widgetset||public||2016-12-15 17:24||2020-04-25 19:30|
|Reporter||Julio Jiménez Borreguero||Assigned To||Michl|
|Product Version||1.7 (SVN)|
|Summary||0031122: Restoring a minimized modal form doesn't draw its content|
|Description||If you minimize a model form, then maximize/restore it, a empty form is shown or a form with not all the components.|
If you drag/move the modal form window then all is displayed again.
It happens under windows (XP, Win 7 and win 10 tested)
Tested with fpc 3.0.1 fixes and lazarus trunk
|Additional Information||I'm not sure when this changed but time ago it was ok.|
|Tags||No tags attached.|
|Fixed in Revision||53716, 53761|
Can you please add a minimal example and explain the steps to show the bug?
Here on Windows 7, 32bit Lazarus 1.7 trunk revision 53693 on FPC trunk, I can't see that bug.
It works well with GTK2 and QT bindings.
Can you please bisect the revision that broke it on Windows.
I fell into similar issue:
Main form is a hidden zero-size window, all children are full-screen forms.
A minimize/maximize bring empty child form. Any resize restores drawing.
Problem relates only to win32 and persists under XP,Win7,Win10.
I will try to create simpler test.
IMO it is related with restoretopmost or restoremodal.
@Juha Manninen I have almost located what rev broke it. It was last november. No time today so I hope tomorrow I will send the revision number.
It affects win32 (GTK2 and QT are ok)
||Maybe r53308 ? It's reverted back again in r53674 so if you're not using current trunk please test.|
||@Zeljan Rikalo: No. Problem persist in rev 53694|
||In that case please create example project and attach here.|
||I can see, if I have two forms and Form1 is main form and Form2 is maximized modal shown and I minimize Form2 and maximize it, it is shown normal, not maximized anymore. That changed of course from 1.6 to 1.7 trunk (maybe related bug).|
I too have such problems and for a while now, I thought it was me!
At first it appears to be a random problem but, I was able to track down
After a resize, even if it's min/max or just resizing, the Canvas.handle
regions attached to it.
I have a app that uses a PaintBox as the drawing surface for updates of what
ever using the OnPaint event.
After a resize event, If I try to set the Cliprect and then read it back
it will not always be what I set it to. In other words it refuses to set it.
But, the next repaint event then allows me to set the Canvas.Cliprect to
what I need.
THis is what I did to work around this problem just after a resize event in the paint events..
That removes all the regions assigned to the hDc. Canvas.Handle
I will keep that line of code in my app with a not until you guys fix it.
The problem I have is most likely the same as the reporter, when bringing up
his form, the Canvas has regions assigned to it that are excluding the surface
until you do a resize again then it gets corrected.
I just try using the PaintBox.Canvas.Clipping := False; which also fixes it.
@Juha Manninen. I have found the revision.
-r53333 is ok
-r53334 Introduced this bug:
Commited by Mattias:
lcl: delay autosize when form is minimized, bug 30826
testbug0031122.zip (144,630 bytes)
I have attached example to reproduce the bug and images of the sequence.
Download and compile the aplication (there is a win32 profile if you do crosscompiling like I do)
1 - Run the Application. Press 'Show modal form' button
2 - Form 2 is shown with all components visible. Press minimize button window
3 - You can see the minimized window then press maximize/double cick on minimized window/restore...
4 - Modal form is visible again but not all components are visible (this is the bug. for some forms no components are visible... all empty)
5 - If you drag the window or resize.. all components are visible again.
All is ok under Linux Gtk2
||Reassigned to Mattias, since r53334 is commited by him.|
I can confirm the bug. It happens for me even with the (nonmodal) application main form. I tested with current trunk (r53714).
Edit: reverting r53334 fixes it.
||Then revert 53334 and fix problem inside win32 ws ?|
||It looks like Michl is working on it - let's give hime some time. The issues seem to have started with my work on 0029308.|
> Then revert 53334 and fix problem inside win32 ws ?
The patch there (in 0030826) was a workaround and was partially inserted and fixes nothing now.
> reverting r53334 fixes it.
This is the first step, that should be done. If you have time, you can do it. I'm on a business travel and have no time now (just writing on phone).
> It looks like Michl is working on it - let's give hime some time.
Yes, I'll look at issue 0030826 later, when I'm in the hotel.
This bug here, of course, could be fixed now, by reverting r53334.
||I reverted r53334 as requested by Michl.|
Experienced this problem even with main form.
Now with 53719 the form appears after restoring but child controls with DoubleBuffered set to True produce a black flicker which is not very nice.
With older releases such as r50093 (Laz4Android 1.5) this ugly flicker does not appear.
The ugly behavior can be observed eg. with my KMemoEditor demo (download and install KControls: https://bitbucket.org/tkweb/kcontrols) and open Demos/KMemoEditor/KMemoEditorLaz.lpi.
> Now with 53719 the form appears after restoring but child controls with
> DoubleBuffered set to True produce a black flicker which is not very nice.
What is the behaviour with revision 53715? If the behaviour there is the same, please open a new bug report.
> What is the behaviour with revision 53715?
1.r50093: Everything fine. Main form restores normally from minimized state and paints correctly (no ugly flicker).
2.r53715: Form does not restore normally, get empty form. Need to move or resize it a bit to show its controls.
3.r53719: Form restores normally, its controls painted. But controls with Doublebuffered property set to true produce ugly black flicker just after the form is restored.
Don't think it is matter for new bug report, just for a better fix of this case.
EDIT: Now tried on Windows 7 and there is no ugly black flicker. Only on Windows 10. r50093 ok on both.
As I wrote before, this issue is solved and should be closed, if it works.
> Don't think it is matter for new bug report, just for a better fix of this case.
No, one bug report for one bug is the best! It becomes harder to read all the comments, if the last bug wouldn't be fixed and someone later want to fix it.
However, I searched a long time for the bug, you see. I don't see it. I tested your package and demo on Windows 10 and Windows 7. The behaviour on Windows 10 and 7 with aero theme is the same. On Windows 7 with classic theme, the background isn't painted black, so a repaint isn't so obvious. Also a difference between double buffered or not, I can't see.
The only thing I found, is one more background erasing, what is inside since revision 51711.
I changed the order of enabling the forms, so that one is gone. But I don't know, if that was that flickering you see.
Please test revision 53761. If your bug isn't fixed please open a new bug report!
||Tested now with 53774. No ugly black flicker visible now, so I assume your modification fixed this. Thank you!|
|2016-12-15 17:24||Julio Jiménez Borreguero||New Issue|
|2016-12-15 20:29||Michl||LazTarget||=> -|
|2016-12-15 20:29||Michl||Note Added: 0096813|
|2016-12-15 20:29||Michl||Assigned To||=> Michl|
|2016-12-15 20:29||Michl||Status||new => feedback|
|2016-12-15 20:41||Juha Manninen||Note Added: 0096814|
|2016-12-15 20:50||Anton Kavalenka||Note Added: 0096816|
|2016-12-15 21:01||Julio Jiménez Borreguero||Note Added: 0096817|
|2016-12-15 21:01||Julio Jiménez Borreguero||Status||feedback => assigned|
|2016-12-15 21:18||Zeljan Rikalo||Note Added: 0096818|
|2016-12-15 21:30||Julio Jiménez Borreguero||Note Added: 0096819|
|2016-12-15 21:43||Zeljan Rikalo||Note Added: 0096820|
|2016-12-15 22:00||Michl||Note Added: 0096822|
|2016-12-16 03:19||jamie philbrook||Note Added: 0096824|
|2016-12-16 03:43||jamie philbrook||Note Edited: 0096824||View Revisions|
|2016-12-16 09:53||Julio Jiménez Borreguero||Note Added: 0096825|
|2016-12-16 10:29||Julio Jiménez Borreguero||File Added: testbug0031122.zip|
|2016-12-16 10:29||Julio Jiménez Borreguero||File Added: 1.png|
|2016-12-16 10:30||Julio Jiménez Borreguero||File Added: 2.png|
|2016-12-16 10:30||Julio Jiménez Borreguero||File Added: 3.png|
|2016-12-16 10:30||Julio Jiménez Borreguero||File Added: 4.png|
|2016-12-16 10:31||Julio Jiménez Borreguero||File Added: 5.png|
|2016-12-16 10:35||Julio Jiménez Borreguero||Note Added: 0096826|
|2016-12-16 10:36||Julio Jiménez Borreguero||Note Edited: 0096826||View Revisions|
|2016-12-16 10:37||Julio Jiménez Borreguero||Note Edited: 0096826||View Revisions|
|2016-12-16 11:03||Zeljan Rikalo||Assigned To||Michl => Mattias Gaertner|
|2016-12-16 11:03||Zeljan Rikalo||Note Added: 0096827|
|2016-12-16 11:22||Mattias Gaertner||Relationship added||related to 0030826|
|2016-12-18 11:20||Ondrej Pokorny||Note Added: 0096885|
|2016-12-18 11:27||Ondrej Pokorny||Note Edited: 0096885||View Revisions|
|2016-12-18 11:31||Zeljan Rikalo||Note Added: 0096887|
|2016-12-18 11:43||Ondrej Pokorny||Note Added: 0096888|
|2016-12-18 13:10||Michl||Note Added: 0096893|
|2016-12-18 13:11||Michl||Note Edited: 0096893||View Revisions|
|2016-12-18 13:12||Michl||Note Edited: 0096893||View Revisions|
|2016-12-18 13:22||Ondrej Pokorny||Fixed in Revision||=> 53716|
|2016-12-18 13:22||Ondrej Pokorny||Note Added: 0096895|
|2016-12-18 13:22||Ondrej Pokorny||Status||assigned => resolved|
|2016-12-18 13:22||Ondrej Pokorny||Resolution||open => fixed|
|2016-12-18 13:22||Ondrej Pokorny||Assigned To||Mattias Gaertner => Michl|
|2016-12-18 19:39||TK||Note Added: 0096906|
|2016-12-18 20:51||Michl||Note Added: 0096915|
|2016-12-18 20:51||Michl||Status||resolved => feedback|
|2016-12-19 14:20||TK||Note Added: 0096937|
|2016-12-20 13:32||Michl||Status||feedback => assigned|
|2016-12-22 22:40||Michl||Fixed in Revision||53716 => 53716, 53761|
|2016-12-22 22:40||Michl||Note Added: 0097018|
|2016-12-22 22:40||Michl||Status||assigned => resolved|
|2016-12-22 22:44||Michl||Status||resolved => assigned|
|2016-12-22 22:44||Michl||Resolution||fixed => reopened|
|2016-12-22 22:44||Michl||Relationship added||related to 0026463|
|2016-12-22 22:45||Michl||Status||assigned => resolved|
|2016-12-22 22:45||Michl||Resolution||reopened => fixed|
|2016-12-25 18:55||TK||Note Added: 0097078|