The CSELF lookup is an unscoped lookup, so essentially, and object
instance can only have ONE cself variable per object instance and all
references to CSELF in any native methods will resolve to the same
instance. If you have multiple inheritance levets setting this value,
then the top of the inheritance hierarchy will be the one that wins
(in your case, you'll always see the one set by the UserDialog class).
The CSELF is really designed for sitiations where there is just a
single native pointer values and methods at all levels of the
hierarchy are accessing the same value. If you wish to use multiple
native values, you'll need to do the unwrapping yourself, For
example, in your case, if you call GetObjectVariable('CSELF') in any
of your init methods, you'll retrieve the value set by that level of
the inheritance hiearchy. You'll then need to call the appropriate
PointerValue() or BufferValue() API yourself to unwrap this to the
native pointer.
Rick
On Tue, Sep 8, 2009 at 1:41 PM, Mark Miesfeld<miesf...@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 4:13 PM, Rick McGuire<object.r...@gmail.com> wrote:
>
>> Nope, in that definition, if the CSELF variable is set in the
>> DialogControl class, it will hide the one set by the WindowBase class
>> for all methods because that will be the first scope searched for the
>> variable. This essentially saws off the one involved with WindowBase.
>> You can still access each of these different CSELF incarnations, but
>> you'll need to manually retrieve the CSELF variable using
>> GetObjectVariable() and do the unwrapping of the value yourself.
>>
>> The changes required for this are fairly trivial, but there is one
>> gotcha. The ObjectToCSelf() API doesn't have a starting scope,
>> because there's no method context involved when you are potentially
>> accessing a CSELF value in another object. I suspect we'll need to
>> add an API that also allows the scoped lookup of the CSELF value.
>
> I sort of hit a dead end here, maybe relating to needing an API that
> allows a scoped lookup of the CSELF value, or some other thing I don't
> understand.
>
> I essentially want to do this in UserDialog::init(). Forward to the
> superclass init() and on return get the CSelf pointer:
>
> RexxObjectPtr result = c->ForwardMessage(NULL, NULL, super, newArgs);
>
> pCPlainBaseDialog pcpbd = (pCPlainBaseDialog)c->ObjectToCSelf(self);
>
> where the class hierarchy is this:
>
> ::class PlainBaseDialog inherit Windowbase
> ::class BaseDialog subclass PlainBaseDialog
> ::class UserDialog subclass BaseDialog
>
> On return from the forward call in UserDialog::init(), I expected to
> get the CSelf pointer set in PlainBaseDialog, but instead I get the
> CSelf pointer of WindowBase:
>
> UserDialog::init() enter
> BaseDialog::init() enter
> PlainBaseDialog::init() enter
> initWindowBase() enter
> initWindowBase() unwrapped WindowBase cself=000007FFFF028840
> PlainBaseDialog::init() setting CSELF unwrapped cself=000007FFFF099EA0
> BaseDialog::init() returning 0
> UserDialog::init() got unwrapped cself=000007FFFF028840 (ObjectToCSelf(self))
>
> So, in UserDialog::init() I get an unwrapped CSelf pointer, but it is
> the one set in WindowBase::init() rather than the one set in
> PlainBaseDialog::init()
>
> I thought the inheritance chain would be:
>
> UserDialog -> BaseDialog -> PlainBaseDialog -> WindowBase
>
> and so the CSelf set in PlainBaseDialog would be before the one set in
> WindowBase, and first one wins.
>
> (I actually ran into this last week in a similar circumstance, but
> just worked around it for now so I could continue to make progress.
> But, here there is no good temp work around.)
>
> I'm not really sure of what to expect here.
>
> --
> Mark Miesfeld
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
