TaskMessageDlg('.... behind form?

[Ian Branch 121]

Hi Guys,

I am only going on hearsay reports from Users att, I haven't experienced it myself, yet.

Is there any reason a TaskMessageDlg('.....  would appear under/behind a Delphi form?

Users have reported that they have experienced this.  Seems the App appears to freeze, one User happened to have his form just to one side of the screen and saw the dialog appear half exposed and half behind his form. :-(

He responded to the dialog appropriately and all was good.

I asked a couple of other Users to move their form aside slightly and they have seen/experienced the same thing.

Unfortunately, it is not consistent.  :-(

I have asked the to try to do a screen capture and send it to me but they haven't as yet. :-(  Hence the opening 'hearsay'.

Any thoughts/Suggestions?

 

Regards,

Ian

[Remy Lebeau 1256]

14 hours ago, Ian Branch said:

Is there any reason a TaskMessageDlg('.....  would appear under/behind a Delphi form?

Yes - if the dialog was not being assigned that Form's HWND as its owner window (in Win32 API terms, not VCL terms).  A dialog can never appear behind its owner window, it stays on top of the owner.  By default, VCL dialog components typically use the HWND of the currently active TForm that has focus, otherwise they may use the MainForm's HWND, or even the TApplication's hidden HWND.  So, if the owner of the dialog is not the Form you are expecting, that would cause the symptom you describe.

 

The main thing to know about TaskMessageDlg() is that it is just a wrapper.  Internally, it performs a few system checks to decide whether to use the Win32 TaskDialogIndirect() function vs the VCL's own TMessageForm class.

 

So, for instance, if you wanted to work around this issue, and you knew your app was always running on systems that support TaskDialogs, you could use the VCL's TTaskDialog component (or even TaskDialogIndirect() directly), explicitly passing it your intended Form's HWND as the dialog owner, eg:

procedure TMyForm.DoSomething;
begin
  // TaskMessageDlg(...);
  TaskDialog1.Title := ...;
  TaskDialog1.Text := ...;
  ...
  TaskDialog1.Execute(Self.Handle);
end;

procedure TMyForm.DoSomething;
var
  config: TASKDIALOGCONFIG;
begin
  // TaskMessageDlg(...);
  config.cbSize := sizeof(config);
  config.hwndParent := Self.Handle;
  config.pszWindowTitle := ...;
  config.pszMainInstruction := ...;
  config.pszContent := ...;
  ...
  TaskDialogIndirect(config, ...);
end;

 

Edited January 29, 2021 by Remy Lebeau

[Ian Branch 121]

HI Remy,

Thank you for the clear and informative response.  Another thing I have learnt today.

If/when they provide actual evidence of the issue, again it is only hearsay att, I will implement the 

"TaskDialog1.Execute(Self.Handle);" method to see if that 'cures' it.

 

Regards & Tks again,

Ian

[TurboMagic 91]

Strange! I found this post because I have exactly the same issue, but the solution above doesn't fix my issue 😞

Given:

 

- D11.1

- a datamodule containing a TTaskDialog

- a main form

- two other forms, each having a button for showing that TTaskDialog

- both forms have the same popup mode, border style etc.

- both are created at runtime and shown via ShowModal and when created both get the main form set as owner

- in one form the TaskDialog shows in the foreground, in the other it stays in the background

- calling execute with self.handle as param doesn't help

 

Now I copied the Taskdialog from the datamodule directly on the form where it doesn't work and called that directly.

Result: still doesn't work 😞

 

Anybody any clue?

[David Heffernan 2290]

Can you cut this down to a minimal reproduction 

[TurboMagic 91]

I might try later on, but it might prove difficult. I already tried to do a minimal demo for something else I saw in that project and reported as QP 38385,
but the minimal demo failed to show the effect. In the German DP somebody said something that all new forms seem to have some popupparent issue
as if always the main form would be used as popup parent...

 

I haven't done any investigation of that theory yet, as I just read it. Could that be related?

Edited June 4, 2022 by TurboMagic

[David Heffernan 2290]

It might well be difficult. But unless you are able to debug this yourself what option do you have. In fact if this was my code and I was debugging it, making a minimal reproduction would be how I would tackle it. 

[TurboMagic 91]

Your idea is of course how one might find it, if it shows in a reduced demo.
My first question would be: what's different between those two forms that one shows this
problem and the other works as expected.

 

So which properties or behavior can influence that?

Both forms have set:

- BorderIcons := [biSystemMenu,biMinimize,biMaximize]

- BorderStyle := bsSingle

- DefaultMonitor := dmActiveForm

- FormStyle := fsNormal

- PopupMode := pmNone also pmAuto doesn't change this

- PopupParent := nil, but also setting it to TCustomForm(AOwner) in the constructor didn't change anything

- Position := poOwnerFormCenter

- WindowState := wsNormal

 

The form itsself only has an OnShowEvent, where one control gets set the focus.

 

Any other properties known which might play a role here?

[TurboMagic 91]

Ok, I invested the time to try to replicate this in a reduced demo, but there the problem doesn't happen!

[David Heffernan 2290]

1 hour ago, TurboMagic said:

Ok, I invested the time to try to replicate this in a reduced demo, but there the problem doesn't happen!

Start from the actual program and remove things bit by bit. When you remove something and the behaviour changes, that's evidence. 

[david_navigator 12]

I had a similar problem recently and it turned out to be due to a third party control on another form within my project.
The 3rd party control did something in it's constructor that resulted in not only message dialogs opening behind, but popups, such as calendars doing similar - it of course didn't happen in normal use, but just when I happened to have two unrelated 3rd party controls in my app. (Thinfinity & TMS Planner)