From: Mark M. <mie...@gm...> - 2009-08-24 23:06:54
|
On Mon, Aug 24, 2009 at 3:52 PM, Rick McGuire<obj...@gm...> wrote: > The code for CSELF searches through all of the scopes of the objects > in inheritance order looking for the first occurrence of a CSELF > variable in the object, and that occurrence is the value returned for > all CSELF references. This is essentially first one found wins, but > it is the mechanism that allows subclasses to access the CSELF value > defined by the base class. Okay, that is pretty much what I understood. So in this definition ::class 'WindowBase' public mixinclass object ::method init_windowBase external "LIBRARY oodialog wb_init_windowBase" ::attribute hwnd get external "LIBRARY oodialog wb_getHwnd" ::class 'DialogControl' public inherit WindowBase WindowExtensions I expected that a CSELF in a DialogControl method would find the CSELF I set in WindowBase, as long as I did not set a CSELF in DialogControl. Which is what we want, and does work that way. > I suspect this really should have been defined by starting with the > scope of the current method and searching back along that inheritance > chain instead. I would hesitate to call this a bug, but it is > something we could add to trunk for the next release. It really is > bad for a mixin class to see a CSELF value for anything other than > scopes along its own inheritance chain. Now, if I add a CSELF to DialogControl, I expected my WindowBase code to still pick up the WindowBase CSELF and the DialogControl code to pick up the DialogControl CSELF. We don't have to call it a bug, <grin>, but it does seem like a good thing to change in trunk for the next release. -- Mark Miesfeld |