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@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@lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus >
-- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus