[RE: [RE: [[lazarus] CreateComponent]]]

Samuel Liddicott sam at campbellsci.co.uk
Mon Aug 23 07:45:16 EDT 1999




> -----Original Message-----
> From: Michal Bukovjan [mailto:mbukovjan at netscape.net]
> Sent: 17 August 1999 04:45 PM
> To: lazarus at miraclec.com
> Subject: Re: [RE: [RE: [[lazarus] CreateComponent]]]
>
> Hello,
>
> > RecreateWnd itself will not be needed for GTK, but the things
> it uses to do
> > its tricks will be needed, as in above about moving listbox to another
> form.
> > But its just donky work, nothing difficult about it.  And the slow-down
> only
> > occurs when it is used - rarely but when it is used it is needed and a
> > work-around would be even worse.  I will manage/check this if you want.
>
> I am not sure what tricks you mean (for GTK).

Listbox.Parent:=OtherForm;

Think what that involves.  The listbox needs to appear intact on another
form with contents intact.  In Win32 this involves saving its contents,
destroying the handle, changing "parent" TWControl and then re-instantiating
which creates a new widget and reloads the control.

> Since in GTK just
> aboout every
> widget may be considered a "form" in a way (yes, thanks to an error I once
> made I created 10 list items, each with its own gradient caption
> and looking
> like a form :-),

Oh, good!  This actually makes things easier!

> and any GtkContainer descendant may contain children, the
> only trick is to re-assign children's parent and realign (not
> 100% sure here,
> but ...).

excellent!

> Basically, GTK widgets behave much like Delphi controls. You just
> care about
> its parent and the size (align policy). You work with (sort of) class
> instances, not handles to class instances.

Fine, but we don't actually worry about this too much.  For all we know the
windows handle is a class-instance (Delphi instances are generally pointers
to the hidden instance) but we communicate using non-object methods.  All we
actually care about is we "somehow" talk to the instance, and that the hwnd
is the key to doing it.  Even if they were both raw instances directly
callable by FPC we could be sure the method names would be different, so it
_does_ just come down to that the HWND is the link to the object and that it
is used in different ways depending on the widget manager.

> The Win32 stuff is propably much more complex, though.
> Nevertheless, the TControl and this hierarchy should remain as widget-set
> neutral as possible.

Its not complex.  In Delphi if you set the "Top" property, it goes like
this:

If HaveWidget then
  tell widget new top
else
  make note of new top


The event handler receives a message to tell it that the widget has changed
its "top" so it then updates its internal copy to match.

And when the widget is instantiated, top is set to the internal value.


So we see that where possible, the widget is called to do the action and
report back to the control that just keeps a copy.

Sam






More information about the Lazarus mailing list