Hi,

I seem to have run into a problem with what is essentially nomenclature..

Since LCL has used Delphi as its template, there's a lot of Windows based conventions, but that doesn't totally map to other systems.

For instance, TForm.Handle in windows repesents the tag that the OS gives to the rectangle I see on screen. I would have thought that each underlying widgetset interface would then use this to maintain some consistency at a higher level, eg on OSX, this would be filled with the WindowRef that OSX uses. However, I cannot see this happening (unless I'm looking in the wrong place). TCarbonWindow has a fWindowRef field and property that references it, but this is at widgetset level, and so not visible to TForm.

I see the HandleAllocated and GetReferenceAllocated code lying around, but they don't seem to tell me what I'm after. What I'd like to know is if I have a function in OSX that is asking for a form's WindowRef, do I pass it self.Handle, or is there something else I should be using. At the moment it is not working as I would hope. For instance calling GetWindowAttributes(WindowRef(self.Handle),myAttributes) gives me an exception each time.

Any ideas on what I should be looking for?

ATB, DSP

Afaik in the Carbon interface TWincontrol.Handle can be typecast to TCarbonWidget (declared in CarbonDef) which has the property "Widget" of type HiViewRef.

so

var
  AHiView: HiViewRef;
begin
...
AHiView := TCarbonWidget(Form1.Handle).Widget);
...
end;

Hope this helps,

Andrew

Duncan, what Lazarus version are you using?

In earlier versions of Carbon widget set, WindowRef could be acquired in the style Andrew has described.

var
 AWindow: WindowRef;
..
begin
...
AWindow  := WindowRef(TCarbonWidget(Form1.Handle).Widget);
...
end;

it was recently changed, so Widget property of TCarbonWindow is also HIViewRef control. You should use the following code, if you use latest svn version of LCL:

var
 AWindow: WindowRef;
..
begin
...
AWindow  := TCarbonWindow(Form1.Handle).Window;
...
end;

Thanks,
Dmitry

Indeed, that is why a Reference property as Handle replacement is introduced.

Each Widgetset is free to return whatever it likes ad Handle to their underlying data structures.
As you can see in other replies, for carbon it was

   AWindow  := WindowRef(TCarbonWidget(Form1.Handle).Widget);

and now

   AWindow  := TCarbonWindow(Form1.Handle).Window;

The idea behind TWInControl.Reference is to abstract this and to allow direct widgetaccess the same time. In the future retrieving the window would become something like:

   AWindow := WinControl.Reference as ICarbonHiView).Window;

or similar for gtk
   AWindow := WinControl.Reference as IGdkWindow).Window;

etc..

Ofcoarse this is all future and depends a bit on when I feel like doing such big change.

I see the HandleAllocated and GetReferenceAllocated code lying around,

THats indeed the start.

See other replies.

Marc

The (Windows) Handle already *is* an abstraction. Why not use it for every widgetset?

It may depend on the widgetset, what can be done with a Handle. This is where general methods (for every widgetset) and specific methods should be separated. We might sort out "true" Windows specific methods, and implement the remaining set of procedures/functions for every widgetset.

DoDi

thx for the replies gentlemen :-)

I'll give a little background... various plugin APIs allow for a custom UI to be shown by the host application, and to do so provide a system reference point (HWND on Windows, WindowRef on Darwin, can't speak for *nix).
To implement this, CreateParented needs to be called into play. As LCL currently stands, this is essentially a dummy procedure. I have done the work to get it operational on Windows; since all widgetsets get the TParams structure passed around, I have used the WndParent member, so this is a simple affair on Windows, since that STRUCT is just given to the OS and it does the work for us. Hurrah!

So I'm now WindowRef is just an unsigned 32bit
integer, I can push into WndParent that supplied value, and I have written the code to ensure the window is compositing, get the parentpane, create the userpane, and place the userpane on the parent (and remove it at destruction). This is fine for a plugin.

However, if I wish to implement host code, I need to be able to pass the WindowRef. I don't want to clutter up higher level code with widgetset details, and so don't want to have to include MacOSAll, CarbonPrivate, etc in what would hopefully be XPlatform code. I would like there to be a single point of contact which holds the OS value, but in a non-specific fashion. So if (as a host) I wish to get a plugin's UI, I just use
Host.OpenPluginUi(HostChildWindow.<InsertPropertyHere>). Now we have 'Handle' which looks like it could do the job nicely - it's an unsigned 32bit integer, but called HWND. Since I don't particularly want to do loads of casting, maybe deferring to a 'Window' property isn't such a bad idea, but just have it declared as longword.

btw, I don't see the Win32 Widgetset using .Window just yet - I assume that it will be a direct mapping to .Handle

My intention is to have this all hammered out, then submit an issue to mantis, with a patch covering basic lcl, then robust widgetset implementations for win32 and OSX; I have a test application to demonstrate before and after. I am having trouble with the OSX 'hosting' since I'm still not able to get the form's WindowRef reliably.

so again, thx for the help so far, and an idea of the direction planned.

DSP