View Issue Details

IDProjectCategoryView StatusLast Update
0031122LazarusWidgetsetpublic2020-04-25 19:30
ReporterJulio Jiménez Borreguero Assigned ToMichl  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
OSWindows 
Product Version1.7 (SVN) 
Summary0031122: Restoring a minimized modal form doesn't draw its content
DescriptionIf 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 InformationI'm not sure when this changed but time ago it was ok.
TagsNo tags attached.
Fixed in Revision53716, 53761
LazTarget-
WidgetsetWin32/Win64
Attached Files

Relationships

related to 0030826 closedMichl TWinControl.WMSize loop detected 
related to 0026463 resolvedZeljan Rikalo Application minimize not working with modal forms 

Activities

Michl

2016-12-15 20:29

developer   ~0096813

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.

Juha Manninen

2016-12-15 20:41

developer   ~0096814

It works well with GTK2 and QT bindings.
Can you please bisect the revision that broke it on Windows.
 http://wiki.freepascal.org/How_do_I_create_a_bug_report#Regression_caused_by_a_certain_revision

Anton Kavalenka

2016-12-15 20:50

reporter   ~0096816

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.

Julio Jiménez Borreguero

2016-12-15 21:01

reporter   ~0096817

@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)

Zeljan Rikalo

2016-12-15 21:18

developer   ~0096818

Maybe r53308 ? It's reverted back again in r53674 so if you're not using current trunk please test.

Julio Jiménez Borreguero

2016-12-15 21:30

reporter   ~0096819

@Zeljan Rikalo: No. Problem persist in rev 53694

Zeljan Rikalo

2016-12-15 21:43

developer   ~0096820

In that case please create example project and attach here.

Michl

2016-12-15 22:00

developer   ~0096822

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

jamie philbrook

2016-12-16 03:19

reporter   ~0096824

Last edited: 2016-12-16 03:43

View 2 revisions

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
so info.
 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..

 Windows.SetclipRgn(PaintBox.Canvas.Handle, 0);
 
 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.

EDIT:
  I just try using the PaintBox.Canvas.Clipping := False; which also fixes it.

Julio Jiménez Borreguero

2016-12-16 09:53

reporter   ~0096825

@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

Julio Jiménez Borreguero

2016-12-16 10:29

reporter  

testbug0031122.zip (144,630 bytes)

Julio Jiménez Borreguero

2016-12-16 10:29

reporter  

1.png (202,707 bytes)   
1.png (202,707 bytes)   

Julio Jiménez Borreguero

2016-12-16 10:30

reporter  

2.png (240,837 bytes)   
2.png (240,837 bytes)   

Julio Jiménez Borreguero

2016-12-16 10:30

reporter  

3.png (192,879 bytes)   
3.png (192,879 bytes)   

Julio Jiménez Borreguero

2016-12-16 10:30

reporter  

4.png (240,425 bytes)   
4.png (240,425 bytes)   

Julio Jiménez Borreguero

2016-12-16 10:31

reporter  

5.png (240,802 bytes)   
5.png (240,802 bytes)   

Julio Jiménez Borreguero

2016-12-16 10:35

reporter   ~0096826

Last edited: 2016-12-16 10:37

View 3 revisions

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)

Compile and:

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

Zeljan Rikalo

2016-12-16 11:03

developer   ~0096827

Reassigned to Mattias, since r53334 is commited by him.

Ondrej Pokorny

2016-12-18 11:20

developer   ~0096885

Last edited: 2016-12-18 11:27

View 2 revisions

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.

Zeljan Rikalo

2016-12-18 11:31

developer   ~0096887

Then revert 53334 and fix problem inside win32 ws ?

Ondrej Pokorny

2016-12-18 11:43

developer   ~0096888

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.

Michl

2016-12-18 13:10

developer   ~0096893

Last edited: 2016-12-18 13:12

View 3 revisions

> Then revert 53334 and fix problem inside win32 ws ?

Yes.

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.

Ondrej Pokorny

2016-12-18 13:22

developer   ~0096895

I reverted r53334 as requested by Michl.

TK

2016-12-18 19:39

reporter   ~0096906

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.

Michl

2016-12-18 20:51

developer   ~0096915

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

TK

2016-12-19 14:20

reporter   ~0096937

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

Michl

2016-12-22 22:40

developer   ~0097018

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!

TK

2016-12-25 18:55

reporter   ~0097078

Tested now with 53774. No ugly black flicker visible now, so I assume your modification fixed this. Thank you!

Issue History

Date Modified Username Field Change
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