Form Resizing Lagging

[Weitentaaal]

Hello

I have a lot of Components on my Main Form and i have a Resize Function wich works Fine but why is it Lagging so hard when i resize the Window ?

Thanks in advice

[lucamar]

It's impossible to say without first seeing what your code is doing but, one of the usual culprits? your code triggering multiple nested paint cycles due, usually, to resizing the form/controls inside a paint event or similar "shenanigans" (with all due respect ) 

[Weitentaaal]

It's impossible to say without first seeing what your code is doing but, one of the usual culprits? your code triggering multiple nested paint cycles due, usually, to resizing the form/controls inside a paint event or similar "shenanigans" (with all due respect ) 

I have a TImage which i use to paint. it will repaint the whole thing everytime the Image gets refreshed. Could i somehow block this ? i guess then the painting itslef wouldn't be the Same ? Is there a Workaround ?

blocked it with a Variable but its Still lagging... maybe bc i have Some Pictures wich get loaded every time ?.

All other Components are standard Lazarus components (Tedit, Labels, Buttons(Colored Buttons from custom Drawn Package), normal Buttons...).
Graphic performance

[balazsszekely]

@Weitentaaal

You're under windows land of unlimited possibilities . You can try something like this:

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

1. uses windows;
2.  
3. var
4.   PrevWndProc: WNDPROC;
5.  
6. function WndCallback(AHWND: HWND; uMsg: UINT; wParam: WParam; lParam: LParam): LRESULT; stdcall;
7. begin
8.   case uMsg of
9.     WM_ENTERSIZEMOVE:
10.       Form1.DisableAlign;
11.     WM_EXITSIZEMOVE:
12.       Form1.EnableAlign;
13.   end;
14.   Result := CallWindowProc(PrevWndProc, Ahwnd, uMsg, WParam, LParam);
15. end;
16.  
17. procedure TForm1.FormCreate(Sender: TObject);
18. begin
19.   PrevWndProc := Windows.WNDPROC(SetWindowLongPtr(Form1.Handle, GWL_WNDPROC, PtrInt(@WndCallback)));
20. end;

PS: If EnableAlign/DisableAlign does not work, switch to LockWindowUpdate(Form1.Handle) and LockWindowUpdate(0) respectively.

[Weitentaaal]

@Weitentaaal

You're under windows land of unlimited possibilities . You can try something like this:

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

1. uses windows;
2.  
3. var
4.   PrevWndProc: WNDPROC;
5.  
6. function WndCallback(AHWND: HWND; uMsg: UINT; wParam: WParam; lParam: LParam): LRESULT; stdcall;
7. begin
8.   case uMsg of
9.     WM_ENTERSIZEMOVE:
10.       Form1.DisableAlign;
11.     WM_EXITSIZEMOVE:
12.       Form1.EnableAlign;
13.   end;
14.   Result := CallWindowProc(PrevWndProc, Ahwnd, uMsg, WParam, LParam);
15. end;
16.  
17. procedure TForm1.FormCreate(Sender: TObject);
18. begin
19.   PrevWndProc := Windows.WNDPROC(SetWindowLongPtr(Form1.Handle, GWL_WNDPROC, PtrInt(@WndCallback)));
20. end;

PS: If EnableAlign/DisableAlign does not work, switch to LockWindowUpdate(Form1.Handle) and LockWindowUpdate(0) respectively.

I Can't use Windows cuz it will cause more Problems then it would Solve

EDIT: Works but i can't use CopyFile anymore ? and writing arrays like this: [.., .., ..] does not work either(which is no problem its just a bit weird ?). there are more than 1 Copy file now wich is the right 1 ? the param names do not tell me anything  .

[balazsszekely]

@Weitentaaal

I Can't use Windows cuz it will cause more Problems then it would Solve

EDIT: Works but i can't use CopyFile anymore ? and writing arrays like this: [.., .., ..] does not work either(which is no problem its just a bit weird ?). there are more than 1 Copy file now wich is the right 1 ? the param names do not tell me anything 

Windows must be first in the uses list in the interface section. If still not works(which I doubt), then FileUtil.CopyFile(...).

[Weitentaaal]

@getmem worked Thanks

So the Sequence of the units does play a Role .. got it

[lucamar]

So the Sequence of the units does play a Role .. got it

As documented in the Free Pascal Reference Guide, Section 16.1:

The order in which the units appear is significant, it determines in which order they are initialized. Units are initialized in the same order as they appear in the uses clause. Identifiers are searched in the opposite order, i. e. when the compiler searches for an identifier, then it looks first in the last unit in the uses clause, then the last but one, and so on. This is important in case two units declare different types with the same identifier.
[Added by me: Or functions/procedures with the same name and signature]

[howardpc]

The order of unit initialization can be counter-intuitive when you have interdependent units.
Consider a project with 3 units, a, b, c.
The .lpr uses c.
c uses b, a
b uses a
The initialization sequence will be a > b > c before the .lpr code runs.
A cursory look at unit c might indicate that b's initialization would run before a's, since it comes first in c's uses clause. However, since b uses a, a's initialization will run before b's.

[Weitentaaal]

Thanks @howardpc and @lucamar and @getmem

[PascalDragon]

The order of unit initialization can be counter-intuitive when you have interdependent units.
Consider a project with 3 units, a, b, c.
The .lpr uses c.
c uses b, a
b uses a
The initialization sequence will be a > b > c before the .lpr code runs.
A cursory look at unit c might indicate that b's initialization would run before a's, since it comes first in c's uses clause. However, since b uses a, a's initialization will run before b's.

True, but for the problem that Weltentaaal experienced that is irrelevant, cause the identifier resolution inside a unit has nothing to do with the order of the initialization and is always from right to left.

[furious programming]

I have a lot of Components on my Main Form and i have a Resize Function […]

Do not use OnResize event — use Anchor Editor and define the behavior of all components when resizing a window or parent component. It should work efficiently, and besides, you'll be able to test the anchor settings in the designer (no need to compile and run the program).