0

The short version -

I have an OpenGL Window which is created using WinApi calls. I would prefer to keep it this way, instead of wrapping OpenGL into a VCL Form.

To provide some preference menus and file dialogs, I resorted to using VCL forms, and the typical dialogs (TOpenDialog, TSaveDialog).

What I'm wondering is - how do I get these Forms and Dialogs to see my OpenGL Window as their owner?

I have attempted to pass my window handle over to the forms, but I feel certain that I'm doing this improperly, as it has no effect.

Form1 := TForm1.Create(nil);   
Form1.ParentWindow := hwnd; //handle to OpenGL Window

What is it that a VCL form requires in order to see a native window as it's owner?

The Long Version -

My application has two modes. Standalone mode, where it runs by itself. Secondarily, there's a Plugin Mode that runs in the process space of a host application.

When in standalone mode, I have no issues with the VCL forms and Dialogs. Even though their ownership is uncertain, it doesn't affect usability in any way.

When in plugin mode, I am finding that the host application will take control of my VCL Forms, and the Open&Save Dialogs.

So, when running in a host's process space, my VCL Forms are rendered very strangely. I've attempted to repair them manually, but they will not respond to style changes.

Edit - Details on Dialogs

My main concern is the rendering of the VCL Forms, but here are some more details on the Dialogs, if it's of any use.

I'm executing dialogs like this:

if FileOpenDialog.Execute(hwnd) then
Begin
  //open up file
End;

And it has no effect. The dialog will act the same as though I had not passed a handle to it. Bear in mind that I am using Delphi 2006, and this version of Delphi is still utilizing the old file dialogs, which were introduced in Windows XP.

Finally - when running as a Plugin, my Open/Save dialogs will appear as though they belong to the host application on the taskbar. So, the host has a taskbar Tab. My application also has it's own Tab. My Open Dialog appears attached to the Host's Tab, when I execute it.

Images

Preference Menu In Standalone Mode:

Preference Menu In Standalone Mode

Preference Menu as Plugin in Host:

Preference Menu In Host

If I could simply change the color of the black text, that would be good enough, but I can't seem to do it.

AudioGL
  • 494
  • 4
  • 18

1 Answers1

2

For the VCL forms you need to override CreateParams and set Params.WndParent to the owning window. That will be your OpenGL window as I understand.

procedure TMyForm.CreateParams(var Params: TCreateParams);
begin
  inherited;
  Params.WndParent := MyOpenGLWindow;
end;

The common dialog classes have an Execute overload that receives a window handle. Pass the handle of your OpenGL window and that OpenGL window will be the owner window of the dialog.

On the subject of your forms rendering strangely it's hard to give definitive advice. My guess is that the strangeness is due to the host app not enabling themes. If you control the host fix it there. Otherwise you need to use activation contexts. My answer to this question gives sample code: Possible to do runtime optional toggling of **runtime themes** by adding an application manifest at runtime?

Community
  • 1
  • 1
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • I added some details to the original question. But I'm currently doing this, to no avail. – AudioGL Apr 05 '13 at 18:35
  • Doesn't this answer the question regarding window owner? You seem to have gone very quiet. – David Heffernan Apr 05 '13 at 20:29
  • Sorry, I was having lunch! I'll try this out. – AudioGL Apr 05 '13 at 20:30
  • Tried it, and the overridden procedure was being called at form create. Still - no change in the unusual rendering behavior. Is it possible that something is missing from the OpenGL Window's Message Loop? Is there a message that I need to be responding to that's being overlooked? It's a custom loop. – AudioGL Apr 05 '13 at 20:39
  • Also - the Edit about runtime themes is an interesting possibility. I'll try playing around with it. – AudioGL Apr 05 '13 at 20:45
  • I answered the questions about ownership. Do you really expect anyone to solve definitively a problem described as "strange rendering"? Surely you can be more specific. Did you notice my most recent update. Is the strangeness that the forms render like Windows Classic? – David Heffernan Apr 05 '13 at 20:46
  • Not necessarily, although I thought it might be a generic issue with an easy fix. I'll put up some images to show you the differences. Also, disabling themes did have an effect, but it was also a mess. I'll play around with it some more. – AudioGL Apr 05 '13 at 20:59
  • I'm not proposing you disable themes. I suggest enabling them. – David Heffernan Apr 05 '13 at 21:00
  • (I tried both to see what would happen. Enabling themes led to no change.) Uploading some images now. – AudioGL Apr 05 '13 at 21:06
  • That's down to the host. We can't help I think. You'll need to work with the host. I'm sorry I've not helped. It's a shame because I thought the issue you were concerned about was ownership. – David Heffernan Apr 05 '13 at 21:18
  • Sorry - I thought the rendering issue and the ownership issues were one in the same, but it appears as though I've asked two questions. Thanks for your help, I have a better idea of how to resolve these issues. – AudioGL Apr 05 '13 at 21:27
  • I would simply take over the rendering of the text myself. Two minutes and I can write my own "group box" and stop using the Win32 common controls. – Warren P Apr 06 '13 at 15:20