We need OnChangingBounds event..
lazarus / 31-LCL

----------------------------------------------------------------------
jamie · 2019-11-22 01:08

Currently we have OnChangeBounds which gets triggered after the fact.

 if one decides it does not like what it has then one could change the
size and thus this will of course trigger another event.

 Now I know the LCL is processing the WM_WINDOWPOSCHAINGING message
and thus if we
could gain access to the WNDOWPOS record so that one could update the
record on return to reset the values.

 This would then prevent unneeded flickering and slowness of the GUI
in many cases when things get busy on the screen..

 I am sure the constraints use this message period to limit the size
of the form because I see it handles it very well without flicker, so
we need this event to be exposed to a common event so the coder can
also adjust the sizes..

 I have some apps I have always used the WM_SIZING so that I can
maintain an aspect ratio of the form without flickering junk on the
screen. It works nicely, I can smoothly enlarge and shrink a form
there by adjusting the opposite side to maintain the ratio without any
junk that takes place because I also have a lot of busy graphics on
the form that gets updated.

 So a OnChangingBounds with a parameter VAR WINDOWSREC, for example so
we can alter it before the LCL does any drawing.

----------------------------------------------------------------------
440bx · 2019-11-22 03:16

I thought it was possible to declare a message method which is "tied"
to any Windows message you want.  Wouldn't that do what you're asking
for ?

(Note: this is what I think based on what I've read in the
documentation.  I've never used that stuff and hopefully never will.)

----------------------------------------------------------------------
ASerge · 2019-11-22 21:45

Quote from: jamie on November 22, 2019, 02:08:24 am Now I know the LCL
is processing the WM_WINDOWPOSCHAINGING message and thus if we
could gain access to the WNDOWPOS record so that one could update the
record on return to reset the values.
I see no difficulty in that:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i unit
Unit1; {$mode objfpc}{$H+} interface uses  Classes, SysUtils, Forms,
Controls, LMessages; type  TForm1 = class(TForm)  private   protected 
  procedure WndProc(var TheMessage: TLMessage); override;  end; var 
Form1: TForm1; implementation uses LCLType; {$R *.lfm} procedure
TForm1.WndProc(var TheMessage: TLMessage);var  P: PWindowPos;begin 
inherited;  if TheMessage.msg = LM_WINDOWPOSCHANGING then  begin    P
:= PWindowPos(TheMessage.lParam);    if P^.x > 200 then    begin //
Ignore sizing      P^.flags := SWP_NOSIZE;      TheMessage.Result :=
0;    end;  end;end; end.

----------------------------------------------------------------------
jamie · 2019-11-22 21:53

That is what I do now, I even process the WM_SIZING and MOVING
message. I can make very smooth updating forms.

 The issue is, I do this for just about for every app now that has
busy screen objects.

 With Delphi I use to implement the message using the standard
practice which does not work with the LCL forms so there was never an
issue with this and I had full control over the GUI drawing.

 I just thought It would be a nice way to make this cross platform so
we can detect early changes of metrics and make changes before they
get applied to the GUI objects, which makes a message if they are not
the values you want used.

----------------------------------------------------------------------
jamie · 2019-11-23 00:58

Quote from: ASerge on November 22, 2019, 10:45:23 pmQuote from: jamie
on November 22, 2019, 02:08:24 am Now I know the LCL is processing the
WM_WINDOWPOSCHAINGING message and thus if we
could gain access to the WNDOWPOS record so that one could update the
record on return to reset the values.
I see no difficulty in that:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i unit
Unit1; {$mode objfpc}{$H+} interface uses  Classes, SysUtils, Forms,
Controls, LMessages; type  TForm1 = class(TForm)  private   protected 
  procedure WndProc(var TheMessage: TLMessage); override;  end; var 
Form1: TForm1; implementation uses LCLType; {$R *.lfm} procedure
TForm1.WndProc(var TheMessage: TLMessage);var  P: PWindowPos;begin 
inherited;  if TheMessage.msg = LM_WINDOWPOSCHANGING then  begin    P
:= PWindowPos(TheMessage.lParam);    if P^.x > 200 then    begin //
Ignore sizing      P^.flags := SWP_NOSIZE;      TheMessage.Result :=
0;    end;  end;end; end.
Btw,  you can't over write the flags like that because other flags
maybe set too.

I vote for the inclusion of this message that supplies the complete
record via  a reference. A lot can be done in this message before
unwanted drawing and movement is taking place.

----------------------------------------------------------------------
Zoran · 2019-11-23 06:24

Quote from: jamie on November 23, 2019, 01:58:52 amI vote for the
inclusion of this message that supplies the complete record via  a
reference. A lot can be done in this message before unwanted drawing
and movement is taking place.

Make a feature request in bugtracker.