[Lazarus] RegisterWSComponent documentation?

[Dmitry Boyarintsev]

The "logical" hierarchy of TWSxxx classes, drives the run time "virtual"
composition.
TWSCustomTreeView inherits from TWSCustomControl.

When "building" an actual (interface) class in run-time, the code tracks
every method declared at TWSCustomControl.
If the method is overridden by any platform-descendant class (i.e.
TCocoaWSCustomTreeVierw), then the run-time class will get the method from
the descendant. Otherwise the platform-class (i.e. TCocoaWSCustomControl)
method is used.
If platform-class doesn't implement a method, the actual method (of
TWSCustomControl) would be used.

As a result, the runtime built class "emulates the hierarchy" of
TCocoaWSCustromTree -> TCocoaWSCustromControl ->
...
even though the actual hierarchy is
TCocoaWSCustromTree ->  TWSCustromTree
TCocoaWSCustromControl ->  TWSCustromControl

It's not nice, but it works.
There are three drawbacks due to use of such approach:
* a complicated run-time "building" code
* "inherited" call should not be used in TPlatformWSxxx methods. Instead of
using inherited, an actual TPlatformWSParentClass should be used instead.
* FPC verify method call (-CR) check cannot be used with LCL. (since it the
check would always fail in run-time built classes)

What you want to do, are the following things:
1) Declare TWSFancyTreeView, as a descendant from TWSTreeControl
2) Declare TUITreeView (LCL control), it can be a descendant from TTreeView
3) Add an implementation TCocoaWSFancyTreeView descendant
from (TWSFancyTreeView).
4) In CocoaWSFactory, have a call to RegisterWSComponent( TUITreeView,
TCocoaWSFancyTreeView );
that should do the trick.

thanks,
Dmitry

On Tue, Nov 10, 2020 at 4:28 PM Zoë Peterson via lazarus <
lazarus at lists.lazarus-ide.org> wrote:

> Is there any documentation on how RegisterWSComponent works with
> creating classes at runtime?
>
> I'm specifically looking at TTreeView and TCustomControl, which both
> have WS classes, TWSTreeView and TWSCustomControl, and widgetset
> specific subclasses, TCocoaWSTreeView and TCocoaWSCustomControl.  It
> looks like it's creating new classes at runtime that somehow combine
> TCocoaWSTreeView and TCocoaWSCustomControl together, but it's not clear.
>
> If I have my own class (TUiTreeView) and I want to register a subclass
> of my own to customize some behavior, should TUiCocoaWSTreeView descend
> from TCocoaWSTreeView or TCocoaWSCustomControl?  Does it matter?  If I
> have a TUiCocoaWSCustomControl too, which has a bunch of behavior I want
> to share, can I have TUiCocoaWSTreeView descend from that?  Does the
> answer change if I add a new virtual method in TUiCocoaWSCustomControl?
>
> This is an issue for me because on macOS 10.14 and later, treeviews
> should use an NSVisualEffectView for their background rather than using
> a plain fillRect(clWindow).  I have that working in our own wrapper
> classes, but I'm not sure if I'm doing something dangerous.  I would
> love to submit the above back to the LCL for inclusion in stock Lazarus,
> but to allow descendants to hook it properly, I'd want a virtual method
> in TCocoaWSCustomControl that TCocoaWSTreeView could override, and I
> assume that isn't supported.
>
> Thanks,
> Zoë Peterson
> Scooter Software
>
> --
> _______________________________________________
> lazarus mailing list
> lazarus at lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201110/787f9406/attachment.html>