Jump to content
programmerdelphi2k

New Behaviour Weird: My new VCL Forms (ALL) (in new projects) using "SHOW" procedure always in TOPMOST on ZOrder after SetWindowPos usage

Recommended Posts

hi People,

 

I don't know what to think to solve the current problem I got myself into!

From the beginning...

 

doing some tests with the "SetWindowPos(...)" MSWin-API function, I realized that my new forms created and called from the main form, using the "SHOW" procedure, were no longer being in the background!!! That is, the new forms are always in the foreground, regardless of whether or not the "FormStyle = fsStayOnTop" is set!!!!

to clarify further:

  1. all new forms are "FormStyle=fsNormal"... ALL, either formMain, or a formSecond called in formMain!
  2. none of the form properties (at all) were changed, it's all default by Delphi. nothing nothing nothing is being changed
  3. The new VCL projects are creating forms always in TOPMOST after my tests with the function call "SetWindowPos(...)" that I made in a test project!!!

 

After a moment of total madness (laughs), I tried checking the Embarcadero Registry (HLM/HCU) to see if any properties were defined during the tests, but I didn't find anything strange....

 

I tried to check some configuration file in the Embarcadero folder (in the user's system folders), but I didn't find anything that gave any information either!

 

Finally, I went to the extreme and completely uninstalled RAD Studio, deleted folders, files and keys in the Registry... everything! And I did a reinstall from scratch! But nothing solved it... my new forms still having the TOPMOST property, this way, creating and calling the sub-forms through the "SHOW" procedure, always placing the sub-forms on the application's main form!

 

Finally, my suspicion is that I bugged MSWindows and now Delphi will always be using create forms as TOPMOST...

 

Has anyone been through this situation or can indicate a way to reverse this situation?

 

watch the two videos using same code 

 

Video 1:   before tests with SetWindowPos

  1. Form1 (main form) call Form2  (second form) using  Form2.SHOW; 
  2. clicking in Form2, it came to front
  3. clicking in Form1, it came to front
  4. OK!!! all it's working!

 

Video 2: after tests with SetWindowPos

  1. Form1 (main form) call Form2  (second form) using  Form2.SHOW;
  2. clicking in Form2, it came to front
  3. clicking in Form1, it DONT came to front
  4. now FORM2 is always on TOP....   😭

 

Here the code used in my tests, nothing more than this

2 forms in tests (main and second forms) had all properties default and none code, basically empty!

 

this code was in my Form1

procedure TMeuFormParaTest.Button1Click(Sender: TObject);
begin
  SetWindowPos(Handle, HWND_TOPMOST, Left, Top, Width, Height, SWP_NOACTIVATE or SWP_NOMOVE or SWP_NOSIZE);
end;

procedure TMeuFormParaTest.Button2Click(Sender: TObject);
begin
  SetWindowPos(Handle, HWND_BOTTOM, Left, Top, Width, Height, SWP_NOACTIVATE or SWP_NOMOVE or SWP_NOSIZE);
end;

after this code, all changed in my Delphi... new projects have its forms using "FormXXX.SHOW"  as TOPMOST, and over my form caller (normally my Form-Main)

 

AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!   Im crazy with this!

 

attached my project test with 2 forms and almost none code!

VCL_Forms_always_TOPMOST_Now_in_New_Projects.zip

 

...

bds_We6UIJCUX7.gif

bds_q2g7yBLWEx.gif

Edited by programmerdelphi2k

Share this post


Link to post

This behavior exists for quite some versions and is usually bound to the Application.MainFormOnTaskbar := True; command in the project file.

  • Thanks 1

Share this post


Link to post

hi @Uwe Raabe

 

but the weird is: I dont change nothing nothing nothing in my IDE (11.3 only one in my MSWin), project, etc... I just useD the SetWindowPos(...) as above...

 

my projects (source-views) is never touched at all

I think that some in MSWindows was changed and now Delphi use it as default  ( I never see this before +20 years)

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

 

Edited by programmerdelphi2k

Share this post


Link to post

The behavior you describe happens if Form1's window is set as the owner window (in Win32 API terms, not VCL terms) of Form2's window.  A window cannot go behind its owner.

 

You can use GetParent() or GetWindow() to determine a window's owner.

 

In the first example, you can freely switch between Form1 and Form2 only if Form1 is not the owner of Form2.  SetWindowPos() DOES NOT change window ownership!  That can only be done with CreateWindow/Ex() when creating a new window, or with SetParent() or SetWindowLongPtr() on an existing window.

 

How a TForm determines which owner to use when creating its window is a bit complex (there are other conditions that can affect the following, but this is the basics - see the source code for TCustomForrm.CreateParams() if you want to see the full logic) :

 

If a TForm's PopupMode is pmNone (the default), then:

  • if Application.MainFormOnTaskBar is true, the Application.MainForm window will be the owner.
  • unless there is no MainForm, or Application.MainFormOnTaskBar is false, then the Application window will be the owner.

 

If a TForm's PopupMode is pmAuto, then:

  • the currently active TForm window will be the owner,
  • unless there is no active TForm, or its window is currently minimized or hidden, then
    • the Application.MainForm window will be the owner,
    • unless there is no MainForm, or Application.MainFormOnTaskBar is false, then the Application window will be the owner.

 

If a TForm's PopupMode is pmExplicit, then:

  • the PopupParent window will be the owner,
  • unless there is no PopupParent, then
    • the Application.MainForm window will be the owner,
    • unless there is no MainForm, then the Application window will be the owner.
Edited by Remy Lebeau
  • Like 2
  • Thanks 1

Share this post


Link to post

@Remy Lebeau

in my IDE or forms NOTHING WAS CHANGED since last project!!!

the behaviour appears after a test with SetWindowPos above;

but I dont changed nothing when creating a new project... I just added a new form (second form) and calling it in my button1 in form1 (main) all as before

 

look

 

bds_7IHxW2vc93.gif

Share this post


Link to post

SORRY BY MY SHAME     😩

 

I never had change this line (ADDed or SUBTRACTed ) before

I dont know how this happens at end...

begin
  Application.Initialize;
                                           // Application.MainFormOnTaskbar := True;  // NOW WORKS...
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

 

Edited by programmerdelphi2k

Share this post


Link to post
18 hours ago, programmerdelphi2k said:

// Application.MainFormOnTaskbar := True;

Alt method for showing forms is using createparams in the forms. Then you can reinstate the OnTaskbar switch.  

 


   protected
     procedure CreateParams(var Params: TCreateParams) ; override;
...
// This fixes alt tab issue showing selected form on top!
procedure TfrmView.CreateParams(var Params: TCreateParams);
begin
  inherited;
  Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW;
end;

 

 

 

Share this post


Link to post

hi @Pat Foley

 

the real problem was:

  • Application.MainFormOnTaskbar = true  

 

In my projects, the setting "Application.MainFormOnTaskbar := True" was not used by default, the same way it is not used in FireMonkey!!!!

 

However, all of a sudden, I realized that this had been changed in the creation of my new form, so it caused all this mental confusion I found myself in.

 

And, to make matters worse, I was more focused on the "SetWindowPos(...)" function than on any other possible cause of the fact itself.

 

This way, I couldn't think of another possible cause, and, I was putting the blame entirely on the "SetWindowPos" function, which, I now know, was not the real culprit of all this fuss.

 

But I'm still looking to leave everything as it was before...

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×