Lazarus 1.6 - Released

[JuhaManninen]

Hope this hasn't created much fuss from my side.

No fuss. I am interested in speedups and optimization. That's why I asked.
FPC 3.0 indeed creates smaller and faster code but the effect in IDE is small because most of the GUI stuff happens in widgetsets. But yes, in some operations it can make a difference. I have not timed / compared -O3 optimized versions of the IDE but it would be an interesting comparison. For example CodeTools does not depend on widgetset and the speedup may be visible when browsing and completing code in editor.

One issue is the compilation speed of FPC. It is often mentioned because Delphi's compiler has traditionally been so super fast. FPC speed will never match it but I believe it has room for some improvement. Let's see.

[JimKueneman]

I would not try to compare with 1.4.4, despite only some month between the releases, the actual difference is about a full year.
1.4.4 only is on the 1.4 branch which was created a year ago, and the 1.4 branch only received a subset of all the changes made since.

You will need an svn client to get different sources from trunk (step by step / or intersecting, by going back half way since the branch, and then keep halfing).

Ok, I see it.  For OS X users if you use ShowModal in any of your production code I would not use 1.6 yet, you may get some unhappy users.  Some change in the LCL have caused a ShowModal form to have a higher priority than _any_ other window on the system.  That can cause issues if you try to pop a system dialog from this modal form.  The modal form has higher priority and the system dialog will not be accessible. 

Simply drop two forms in a fresh application. Put one button on one form that simply calls Form2.ShowModal.  Drag that form down near the Applications Icon on the Dock.  Now go to the dock and press the Applications button.  The form shows on top of the popup from the Dock.   Also if you Command-Tab to another application it can't get on top of the modal form.

I compared the Carbon Interface files for the show modal code and they are virtually identical between 1.4.4 and 1.6 so it has to be somewhere in the window class creation which I have not found where this is exactly.

Jim

[VTwin]

Thanks Jim,

For OS X users if you use ShowModal in any of your production code I would not use 1.6 yet, you may get some unhappy users.

 

This is bad news. I verified your test, and it explains the problem with the system dialogs. Unfortunately I use ShowModal fairly often for input dialogs.

A patch or workaround would be most welcome.

Cheers,
VTwin

[JuhaManninen]

I compared the Carbon Interface files for the show modal code and they are virtually identical between 1.4.4 and 1.6 so it has to be somewhere in the window class creation which I have not found where this is exactly.

Can you find the revision that caused the problem? Use trunk as Martin suggested, then binary search by testing a revision, splitting the range in half, compiling and testing again. O(log2(n)).
Hint: "git bisect" command makes this task easy and fun.

[JimKueneman]

Ok found the change that broke things I believe it is in the

{Lazarus}/lcl/include/customform.inc

1.4.4

Code: Pascal  [Select][+][-]

1. procedure TCustomForm.CreateParams(var Params : TCreateParams);
2. begin
3.   inherited CreateParams(Params);
4.   with Params do
5.   begin
6.     if (Parent = nil) and (ParentWindow = 0) then
7.     begin
8.       // define Parent according to PopupMode and PopupParent
9.       if not (csDesigning in ComponentState) then
10.       begin
11.         if (Application.MainForm <> Self) then
12.         begin
13.           case PopupMode of
14.             pmNone:;
15.             pmAuto:
16.               if (Screen.ActiveForm <> nil) then
17.                 WndParent := Screen.ActiveForm.Handle;
18.             pmExplicit:
19.               if (PopupParent <> nil) then
20.                 WndParent := PopupParent.Handle;
21.           end;
22.         end;
23.         if (WndParent = 0) and
24.            (((Self = Application.MainForm) and Application.MainFormOnTaskBar) or (GetEffectiveShowInTaskBar = stAlways)) then
25.           ExStyle := ExStyle or WS_EX_APPWINDOW;
26.       end;
27.       Style := Style and not Cardinal(WS_GROUP or WS_TABSTOP or WS_CHILD);
28.     end;
29.   end;
30. end;
31.  

1.6.0

Code: Pascal  [Select][+][-]

1. procedure TCustomForm.CreateParams(var Params : TCreateParams);
2. var
3.   APopupParent: TCustomForm;
4. begin
5.   inherited CreateParams(Params);
6.   with Params do
7.   begin
8.     if (Parent = nil) and (ParentWindow = 0) then
9.     begin
10.       // define Parent according to PopupMode and PopupParent
11.       if not (csDesigning in ComponentState) then
12.       begin
13.         if (Application.MainForm <> Self) then
14.         begin
15.           APopupParent := GetRealPopupParent;
16.           if APopupParent <> nil then
17.             WndParent := APopupParent.Handle;
18.         end;
19.         if (WndParent = 0) and
20.            (((Self = Application.MainForm) and Application.MainFormOnTaskBar) or (GetEffectiveShowInTaskBar = stAlways)) then
21.           ExStyle := ExStyle or WS_EX_APPWINDOW;
22.       end;
23.       Style := Style and not Cardinal(WS_GROUP or WS_TABSTOP or WS_CHILD);
24.     end;
25.   end;
26. end;
27.  

We have this new "GetRealPopupParent"

Code: Pascal  [Select][+][-]

1.  
2. function TCustomForm.GetRealPopupParent: TCustomForm;
3. begin
4.   Result := nil;
5.   if (fsModal in FormState) or // always set WndParent of modal windows
6.      (PopupMode in [pmAuto, pmExplicit]) // set WndParent of non-modal windows only for pmAuto, pmExplicit
7.   then
8.   begin
9.     case PopupMode of
10.       pmAuto:
11.       begin
12.         Result := Screen.ActiveForm;
13.         if (Result<>nil) and (Result.FormStyle = fsSplash) then // ignore fsSplash
14.           Result := nil;
15.       end;
16.       pmExplicit: Result := PopupParent;
17.     end;
18.     if (Result = nil) or not Result.HandleAllocated then
19.       Result := Application.MainForm;
20.   end;
21.   if (Result <> nil) and not Result.HandleAllocated then
22.     Result := nil;
23.   if (Result = Self) then
24.     Result := nil;
25. end;
26.  

With OS X it collapses into giving the Parent as Application.MainForm when ShowModal is used.  In 1.4.4 CreateParams exited with the WndParent = 0.

I am no where near enough of an OS X low level window management expert to understand why this makes a difference but it sure seems like it does.

Jim

[VTwin]

Ok found the change that broke things

Nice detective work! Swapping in CreateParams from 1.4.4 works. Any idea if that might create side effects?

Cheers,
VTwin

[zeljko]

That was Ondrej's patch to fix popupparent behaviour, so pls open an issue about it. It's regression for carbon ws (and probably cocoa).

[JimKueneman]

I checked the window handle relationships and it seems in theory it should be the correct thing to do.  What I believe is going on is that OS X does not like a window to be created that has a WndParent assigned but it does not have the CreateParam flags set with the WS_CHILD flag. 

VTwin could you try changing

Code: Pascal  [Select][+][-]

1. Style := Style and not Cardinal(WS_GROUP or WS_TABSTOP or WS_CHILD);

to

Code: Pascal  [Select][+][-]

1. Style := Style and not Cardinal(WS_GROUP or WS_TABSTOP or WS_CHILD);
2. if WndParent <> 0 then
3.   Style := Style or WS_CHILD;
4.  

in 1.6.0? 

I don't have access to a computer that I can recompile it today.

Jim

[JimKueneman]

That was Ondrej's patch to fix popupparent behaviour, so pls open an issue about it. It's regression for carbon ws (and probably cocoa).

Done.  Issue 0029694

[JimKueneman]

Code: Pascal  [Select][+][-]

1. Style := Style and not Cardinal(WS_GROUP or WS_TABSTOP or WS_CHILD);
2. if WndParent <> 0 then
3.   Style := Style or WS_CHILD;
4.  

Curiosity got the best of me.  Downloaded the source and tried this.  Yes this fixes it as well but I can see that could be an issue because CreateParams is for all windows.  Somehow the LCL would need to know that the window is a Form and that it is going to created as a child of another Form before the Handle is created.  I can image that is not something that is easy to do.  Maybe in the ShowModal call the LCL can set the ParentHandle then recreate the Window Handle before it is shown?

I just don't know the LCL enough to understand the issues doing something like this would cause.

Jim

[MSC]

Having installed Lazarus 1.6 (running ok) and thereafter IDE anchordockingdsgn package.
After restart, IDE didn´t show the Coolbar with the Save-, Run-, etc. buttons, only component-palette,object inspector and editor were visible.
I had to enable the flag "Coolbar visible" within the IDE-settings (environment-->Coolbar visible) to make it visible.
Now anchordocking is working fine. 

I also wanted to point out another problem.
When I design a form in the IDE, it should look the same at runtime (same position, same size, etc. --> wysiwyg).
But on the last Lazarus versions, the form and also the components on it are shown approx. 30% right and 30% down its designed position and all is streched/enlarged also by approx. 30 %. Looks like all IDE-designed screen position values but not the values programmed by software have moved. This of course will destroy my form design!
I´m using a notebook with a FullHD resolution (1920x1080 pixel). On an older notebook with only HD resolution this  effect didn´t occur. I found this problem already in Lazarus 1.4.4 (couldn´t test it on older versions).
To overcome this problem, I had to enable "dpi-dependent application (for vista+)" (dpi-abhängige Anwendung (für Vista+) in german) within the project settings.

Lazarus 1.6 32bit on Intel I3-6100 with HD-graphics 520 (1920x1080 pixel) running Windows 10 Home 64 bit.

[Hansvb]

Is something changed in TSQLScript?
I installed lazarus 1.6 win32 and tried to execute a program that works wel under lazaruss 1.4.2.

It compiles good but it stops running at

Code: Pascal  [Select][+][-]

1. SQLScript1.Execute

There is no warning, it just seems to be bussy but does northing.

[Ameta]

Thank you Lazarus Team!

[bytebites]

There is access violation in Json Data viewer when search string is not found. It happens in frmmain.pp line 856 ANode is nil.

[VTwin]

Code: Pascal  [Select][+][-]

1. Style := Style and not Cardinal(WS_GROUP or WS_TABSTOP or WS_CHILD);
2. if WndParent <> 0 then
3.   Style := Style or WS_CHILD;
4.  

Curiosity got the best of me.  Downloaded the source and tried this.  Yes this fixes it as well but I can see that could be an issue because CreateParams is for all windows.  Somehow the LCL would need to know that the window is a Form and that it is going to created as a child of another Form before the Handle is created.  I can image that is not something that is easy to do.  Maybe in the ShowModal call the LCL can set the ParentHandle then recreate the Window Handle before it is shown?

I just don't know the LCL enough to understand the issues doing something like this would cause.

Jim

Thanks Jim,

Hopefully someone with LCL and Carbon expertise can shed some additional light on this. I'll use the 1.4.4 patch for now. Thanks for tracking it down.

Cheers,
VTwin