[Lazarus] Re: OSX: Handles and WindowRefs

Duncan Parsons lazarus at dsparsons.co.uk
Mon Jan 12 15:13:11 CET 2009


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 looking at OSX. Since 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

Marc Weustink wrote:

> Duncan Parsons wrote:
> > 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.
> 
> Indeed, that is why a Reference property as Handle replacement is 
> introduced.
> 
> > 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.
> 
> 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.
> 
> > 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?
> 
> See other replies.
> 
> Marc
> 
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus



-- 





More information about the Lazarus mailing list