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.

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

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

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.

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

Michal Bukovjan