[Lazarus] RegisterWSComponent documentation?
skalogryz.lists at gmail.com
Wed Nov 11 05:06:20 CET 2020
The "logical" hierarchy of TWSxxx classes, drives the run time "virtual"
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
4) In CocoaWSFactory, have a call to RegisterWSComponent( TUITreeView,
that should do the trick.
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.
> Zoë Peterson
> Scooter Software
> lazarus mailing list
> lazarus at lists.lazarus-ide.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lazarus