I thought that all is ok but unfortunately not.
I have a problem with the new autosize, it is difficult to me to create a bug report because the application is quite big and the error does not occur always.

In short:
I have assigned to the panel (stringgrid.parent=panel) three stringgrid objects, all have align = alClient and they are displayed separately (all three objects are created, only I switch visible). With the new autosize at some point when loading data to stringgrid and when I set Visible = true then sometimes stringgrid don't shows. It is strange because it happens not always on different systems. Often I have a problem on Vista (Intel Core Duo) and Windows 2000 on VirtualBox, on system where I compile a program Windows XP, it happened maybe once.
With -dOldAutoSize all is ok. Maybe multi-threading in my application makes this problem ? I tried to find the problem and I suspect that stringgrid not quite finished loading the data when I try to view it. However, I put "sleep" before Visible := true and does not help. Maybe someone has some tips ?

best regards
faber

which revision are you on?

Because afaik on the latest Lazarus the -dOldAutoSizedoes nothing anymore (the option was removed, new autosize is always used) So maybe you need to update first and try again?

Martin

Yes I now, I stoped on 24705 (snapshots) because OldAutoSize was removed.

Yes I now, I stoped on 24705 (snapshots) because OldAutoSize was removed.

and of course tested on latest (yesterday)

Yes, OldAutoSize was removed a week ago in revision 25190. Please update and test with current version.

About multithreading: All LCL operations should be done in the main thread.
Does hiding the other stringgrids work?
Have you checked what size the new stringgrid gets? Check the OnResize event of the stringgrids.

Mattias

Other grids works ok, hm...
the difference between them is that good grids changes control on the main form (where panel with grids) but the problematic grid is showing automatically after closing the second form.
I have an idea,I'll test it again and try to do a small test project.

I'm testing on r25388.
Unfortunately I can't get this issue on sample similar small project. On my app i put this line to OnResize event

 debugln(inttostr(TStringGrid(Sender).Height)+'-:-'+inttostr(TStringGrid(Sender).Width)+'
'+booltostr(TStringGrid(Sender).Visible));

and on good working I get the same as in wrong working, twice this line "459-:-688 -1", so I get width and height and visibility but I don't see grid (only I see panel).

and on old rev. with dOldAutoSize i get something else: 100-:-200 -1
100-:-200 -1
100-:-200 -1
459-:-688 -1

Zitat von faber :

Hint: You can use:
debugln([dbgsName(Sender),' ',dbgs(TControl(Sender).BoundsRect)]);

and on good working I get the same as in wrong working, twice this line "459-:-688 -1", so I get width and height and visibility but I don't see grid (only I see panel).

Ok. Maybe the visible flag is not sent to the interface. Are there any exceptions that you catch with a try..except?

Mattias

Zitat von Mattias G?rtner :

I found a place where an exception would not reset a flag. I fixed that and the LCL now gives a debugln if that happens.

Mattias

With r25400 still without success.
Yes I've try..except OdDrawCell but I don't get debugln from Revision
25397. I also remove my try..except but this does not help. Can use more debugging output to see more ?

Zitat von faber :

Please update to svn 25401 and compile with -dVerboseShowing (in the configure build lazarus dialog, advanced, Options).

Mattias

Please update to svn 25401 and compile with -dVerboseShowing (in the configure build lazarus dialog, advanced, Options).

Unfortunately I don't get any more debug with this option. I changed the order (first hide the current grid then show other) and it doesn't hide first, so the problem is not only with showing grid. But I think I found workaround for this problem

before:
SG1.Visible:=true;
SG2.Visible:=false;
after:
SG2.Visible:=false;
Application.ProcessMessage;
SG1.Visible:=true;

I do not know how good is this solution. I'm going testing.

Zitat von faber :

> Please update to svn 25401 and compile with -dVerboseShowing (in the > configure build lazarus dialog, advanced, Options). Unfortunately I don't get any more debug with this option.

It should write a lot of output.
Are you sure, you are using the right LCL ppus?
Do you have local modifications, so that the svn update was incomplete? Search for IFDEF VerboseShowing in
lcl/include/wincontrol.inc.
Do you see any debugln output?

If this works, maybe it is an invalidate/painting problem in the win32 interface.

Mattias

Zitat von Mattias G?rtner :

Sorry. I just saw, that my svn commit failed. Try svn 25402.

Mattias

OK, a get this.

This is my code:
    ...
    Second form closes and ends with some calculations
    ...
    debugln('set sr1 to visible true');
    SR1.Visible:=true;
    SG1.Visible:=false;
    if Assigned(SR1) AND SR1.Visible then begin
       OptsR.Parent:=SR1;
       OptsR.Top:=1;
       OptsR.Left:=11;
       OptsR.ArrowType:=atDown;
       OptsR.Height:=19;
       OptsR.Width:=19;
       OptsR.Visible:=true;
    end;
    StopA.Visible:=false;

and LCL debug from app on WinXP (works ok):

set sr1 to visible
450-:-743 -1 //debug from OnResize
450-:-743 -1
ChangeShowing SR1:TStringGrid1 new FShowing=True
TWinControl.CMShowingChanged SR1:TStringGrid1 HandleAllocated=True [] TWinControl.DoSendShowHideToInterface SR1:TStringGrid1 FBoundsRealized= x1=2,y1= 21,x2=745,y2=471 New=True
ChangeShowing :TStringGrid1 new FShowing=False
TWinControl.CMShowingChanged :TStringGrid1 HandleAllocated=True [] TWinControl.DoSendShowHideToInterface :TStringGrid1 FBoundsRealized= x1=2,y1=21, x2=745,y2=471 New=False
TWinControl.UpdateShowing OptsR:TArrow handle not allocated ChangeShowing OptsR:TArrow new FShowing=True
TWinControl.CMShowingChanged OptsR:TArrow HandleAllocated=True [] TWinControl.DoSendShowHideToInterface OptsR:TArrow FBoundsRealized= x1=11,y1=1,x 2=30,y2=20 New=True
ChangeShowing StopA:TButton new FShowing=False
TWinControl.CMShowingChanged StopA:TButton HandleAllocated=True [] TWinControl.DoSendShowHideToInterface StopA:TButton FBoundsRealized= x1=432,y1=3 ,x2=523,y2=24 New=False

and LCL debug from app on Vista (not works correct):

ChangeShowing StopA:TButton new FShowing=False
TWinControl.CMShowingChanged StopA:TButton HandleAllocated=True [] TWinControl.DoSendShowHideToInterface StopA:TButton FBoundsRealized= x1=432,y1=3 ,x2=523,y2=24 New=False
set sr1 to visible
ChangeShowing :TStringGrid1 new FShowing=False
TWinControl.CMShowingChanged :TStringGrid1 HandleAllocated=True [] TWinControl.DoSendShowHideToInterface :TStringGrid1 FBoundsRealized= x1=2,y1=21, x2=745,y2=470 New=False
TWinControl.UpdateShowing OptsR:TArrow handle not allocated 449-:-743 -1
449-:-743 -1
ChangeShowing OptsR:TArrow new FShowing=True
TWinControl.CMShowingChanged OptsR:TArrow HandleAllocated=True [] TWinControl.DoSendShowHideToInterface OptsR:TArrow FBoundsRealized= x1=11,y1=1,x 2=30,y2=20 New=True
ChangeShowing SR1:TStringGrid1 new FShowing=True
TWinControl.CMShowingChanged SR1:TStringGrid1 HandleAllocated=True [] TWinControl.DoSendShowHideToInterface SR1:TStringGrid1 FBoundsRealized= x1=2,y1= 21,x2=745,y2=470 New=True

And sometime I get this (on Vista):
ChangeShowing ChangeShowing ChangeShowing
TWinControl.UpdateShowing.ChangeShowing failed for ERROR in LCL: TControl.EnableAutoSizing
Creating gdb catchable error:
$00490288
$00529883
$00527DA9
$0044C0FD
$0045EA9A
$0052EEA8
$005A627F
$76B0FD72
TApplication.HandleException Division by zero
Stack trace:
$004902B2
...

but it is only noticed when I enabled debug VerboseShowing

Maybe I found the reason for this bug (arrow handle not allocated). Can you test with svn rev 25541?

Mattias

Maybe I found the reason for this bug (arrow handle not allocated). Can you test with svn rev 25541?

Unfortunately the problem still exists. Tested with rev25544. I tested with and without Tarrow. But with no arrow problem occurred on the third run. But sometimes the problem occurred not on the first time .

best regards
faber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/0eb11fee/attachment.html>

Is the array handle not allocated message still there?

Mattias

Is the array handle not allocated message still there?

Yes.

ChangeShowing StopA:TButton new FShowing=False
TWinControl.CMShowingChanged StopA:TButton HandleAllocated=True [] TWinControl.DoSendShowHideToInterface StopA:TButton FBoundsRealized= x1=432,y1=3
,x2=523,y2=24 New=False
set sr1 to visible
ChangeShowing :TStringGrid1 new FShowing=False
TWinControl.CMShowingChanged :TStringGrid1 HandleAllocated=True [] TWinControl.DoSendShowHideToInterface :TStringGrid1 FBoundsRealized= x1=2,y1=21,
x2=745,y2=470 New=False
TWinControl.UpdateShowing OptsR:TArrow handle not allocated 449-:-743 -1
449-:-743 -1
ChangeShowing OptsR:TArrow new FShowing=True
TWinControl.CMShowingChanged OptsR:TArrow HandleAllocated=True [] TWinControl.DoSendShowHideToInterface OptsR:TArrow FBoundsRealized= x1=11,y1=1,x
2=30,y2=20 New=True
ChangeShowing SR1:TStringGrid1 new FShowing=True
TWinControl.CMShowingChanged SR1:TStringGrid1 HandleAllocated=True [] TWinControl.DoSendShowHideToInterface SR1:TStringGrid1 FBoundsRealized= x1=2,y1=
21,x2=745,y2=470 New=True
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/53c2dd6d/attachment.html>

I wonder the bad sequence (order):
my code
 debugln('set sr1 to visible true');
   SR1.Visible:=true;
   SG1.Visible:=false;
   if Assigned(SR1) AND SR1.Visible then begin
      OptsR.Parent:=SR1;
      OptsR.Top:=1;
      OptsR.Left:=11;
      OptsR.ArrowType:=atDown;
      OptsR.Height:=19;
      OptsR.Width:=19;
      OptsR.Visible:=true;
   end;
   StopA.Visible:=false;

and debug:
hide StopA

   debugln('set sr1 to visible true');
   hide :TStringGrid1 --- SG1 ?
   debug from onresize
   show Arrow
   show SR1

why show SR1 is on the end ? In code I set SR1 to visible at the beginning. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/39c84d00/attachment.html>

BTW on Windows XP with out that problem order is correct. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/62029e49/attachment.html>

> Is the array handle not allocated message still there? Yes.

Ehm. Should it be visible? If not, then the message is correct. I will extend the verbosity.

Is SR1 not visible or is the other stringgrid not hidden?

Mattias

When autosizing is delayed then changes to Visible are delayed too (for example via DisableAlign/EnableAlign). When the autosizing is enabled again all changes are applied. Hide comes before Show.

Mattias

BTW on Windows XP with out that problem order is correct.

What happens when you enclose the sequence in DisableAlign/EnableAlign?

Mattias

Yes, it should be visible

Is SR1 not visible or is the other stringgrid not hidden?

SR1 not visible

What happens when you enclose the sequence in DisableAlign/EnableAlign?

my English is not very good. If you mean something like this:
    SR1.Align:=alNone;
    SR1.Visible:=true;
    SG1.Visible:=false;
    SR1.Align:=alClient;

then this not fix the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/475fac6e/attachment-0001.html>

Ok. So a handle creation failed. That would be pretty bad under gtk. I wonder why the winapi widgetset can live with that.

> Is SR1 not visible or is the other stringgrid not hidden? SR1 not visible

Strange. The LCL tells the widgetset to show it and the correct bounds are sent too.

DisableAlign;
...
...
EnableAlign;

Mattias

Unfortunately it did not help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/fd2ca6f6/attachment.html>

I guess it is a win32 interface bug, because you wrote it works on some windows and not on windows XP.
The calls are in lcl/interfaces/win32/win32wscontrols.pp

TWin32WSWinControl.ShowHide

Add there a debug line:

  debugln(['TWin32WSWinControl.ShowHide ',dbgsname(AWinControl),' ',AWinControl.HandleObjectShouldBeVisible]);

Run it.
Is the stringgrid made visible there?

Mattias

TWin32WSWinControl.ShowHide SR1:TStringGrid1 True - and I don't see SR1

but what I observed, sometime on good working WinXP there is also problem with showing Arrow also, as example, that debug:

TWin32WSWinControl.ShowHide StopA:TButton False
TWin32WSWinControl.ShowHide :TStringGrid1 False
449-:-743 -1
449-:-743 -1
TWin32WSWinControl.ShowHide OptsR:TArrow True
TWin32WSWinControl.ShowHide SR1:TStringGrid1 True

don't show Arrow but show SR1.
But what's important, I observed that the problem occurs only when the order of debug lines is wrong (on autosizing delayed). When I get that debug: set sr1 to visible
449-:-743 -1
449-:-743 -1
TWin32WSWinControl.ShowHide SR1:TStringGrid1 True
TWin32WSWinControl.ShowHide :TStringGrid1 False
TWin32WSWinControl.ShowHide OptsR:TArrow True
TWin32WSWinControl.ShowHide StopA:TButton False
then everything is always ok.

And during the testing, I got this error once:

set sr1 to visible
449-:-743 -1
449-:-743 -1
TWin32WSWinControl.ShowHide SR1:TStringGrid1 True
TWin32WSWinControl.ShowHide :TStringGrid1 False
TWin32WSWinControl.ShowHide TWin32WSWinControl.ShowHide TWin32WSWinControl.ShowH
ide StopA:TButton False
TApplication.HandleException Disk Full
Stack trace:
$00492E9D
$0049241F
$005A5BFD
$00520C8B
$005211E9
$0040B93A
$0051BD00
$00523948
$0051A179
$0051A0D7
$00518CE6
$00518CA7
$00518CA7
$00518CA7
$00518B4B
$0052A914
$0052A904
:TBitBtn True
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100521/defc4cf4/attachment.html>

Zitat von faber :

Thanks for testing.

Weird.
The order should not matter for the winapi. I hope some winapi expert has seen something like this and can give some hint. Maybe the SR1 is not at the right position.
In the unit lcl/interfaces/win32wscontrols.pp in procedure TWin32WSWinControl.SetBounds after the line AdaptBounds you can add a debugln:

debugln(['TWin32WSWinControl.SetBounds ',dbgsname(AWinControl),' l=',IntfLeft,' t=',IntfTop,' w=',IntfWidth,' h=',IntfHeight,' suppress=',suppressMove]);

Is SR1 getting the right bounds?

Either your disk was full or there is too much output so that there is a congestion that windows can not handle fast enough. You are writing the output to a file, don't you?

Mattias

on good working:

set sr1 to visible
450-:-743 -1
TWin32WSWinControl.SetBounds SR1:TStringGrid1 l=2 t=21 w=743 h=450 suppress=False
450-:-743 -1
TWin32WSWinControl.ShowHide SR1:TStringGrid1 True
TWin32WSWinControl.ShowHide :TStringGrid1 False
TWin32WSWinControl.SetBounds OptsR:TArrow l=11 t=1 w=19 h=19 suppress=False TWin32WSWinControl.ShowHide OptsR:TArrow True
TWin32WSWinControl.ShowHide StopA:TButton False

on not good working:

TWin32WSWinControl.ShowHide StopA:TButton False
set sr1 to visible
TWin32WSWinControl.ShowHide :TStringGrid1 False
449-:-743 -1
TWin32WSWinControl.SetBounds OptsR:TArrow l=11 t=1 w=19 h=19 suppress=False TWin32WSWinControl.SetBounds SR1:TStringGrid1 l=2 t=21 w=743 h=449 suppress=False
449-:-743 -1
TWin32WSWinControl.ShowHide OptsR:TArrow True
TWin32WSWinControl.ShowHide SR1:TStringGrid1 True

so it's probably too much output, I write output to console, I thought it does not matter whether to the file or to the console.

best regards
faber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100521/ed05d16f/attachment.html>

WOW. I found that Windows standard composition is the problem. When I switch to Classic Windows on XP then everything is OK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100521/96efd369/attachment.html>

Zitat von faber :

Thanks. So in both cases the bounds are correct and are sent before the Show. (Please double check that there are no ShowHide or SetBounds after this for the grid).
The only difference seems to be the time when the button and the the other grid is hidden.
Maybe there is something wrong with the parent control or the paint event for the grid does not work (or you have a memory bug).

Paul, do you have seen something like that before? What can prevent a window to appear?

Mattias

WOW. I found that Windows standard composition is the problem. When I switch to Classic Windows on XP then everything is OK.

What is "Windows standard composition"?

Mattias

What is "Windows standard composition"?

As standard I mean theme : "Windows XP".
Works good on theme "Windows Classic" even if autosize delay occurs. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100522/169f25a7/attachment.html>

Mattias G?rtner wrote

Paul, do you have seen something like that before?

I had something similar with TPageControl but that was because of we removed WS_VISIBLE flags on control creation and set visibility now after the CreateHandle call. This bug was fixed for TPageControl.

What happens if you add WS_VISIBLE to TWinControl.CreateParams style? Does this solves the problem of the grid visibility (I believe that not because it works with the classing theme as the reporter said)?

What can prevent a window to appear?

I need a test application to look what could that be.

Best regards,
Paul Ishenin.

I was not able to do small application where the problem occurred. This is quite a big commercial project so the source code is the problem.The binary ver. is enough ?
or I could try truncate the code but this will be a lot of work. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100522/a25664c2/attachment.html>

faber wrote

I was not able to do small application where the problem occurred.

What if you leave only 1 form with that 4 grids and a button?

This is quite a big commercial project so the source code is the problem. The binary ver. is enough ?

We need small 1 form application. The binary will give no infor about the problem.

or I could try truncate the code but this will be a lot of work.

Maybe this help you to find the error if it is in your code.

Best regards,
Paul Ishenin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100522/19057369/attachment.html>

OK. I try to prepare that code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100522/3f119b59/attachment.html>