On 27.11.2011 10:28, Jean-Louis Faucher wrote:
> After thoughts, I think this part of my previous mail is not so obvious :
> "Obviously, the overwritting should not happen."
>
> If declaring CSELF is like doing expose CSELF, then it's normal to have a
> specific value at each
> scope.
> Exposed variables are not inherited, so the assignment of DictWidget seems
> ok, knowing that the
> link DictWidget-->DictWindow has been created. I suppose that there is no
> need of specific
> ordering when linking the dictionaries ?
>
> If that's correct, then I think the CSELF value should be managed with two
> methods get and set,
> whose scope is GTWIDGET. That way, the CSELF value would be always stored in
> DictWidget.
In the past there have been a few posts about CSELF, where Rick would give
hints and explanations.
Unfortunately, I have not found a way to look for subject-values in the
developer list archive,
hence a copy and paste of some of those explanations here:
* -------- Original Message --------
Subject: Re: [Oorexx-devel] CSELF Problem
Date: Sun, 10 Aug 2008 19:35:00 -0400
From: Rick McGuire <object.r...@gmail.com>
Reply-To: Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
To: Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
This is why I added the ObjectToCSelf() api. Use
GdkWindow *parentWidget = (GdkWindow *)context->ObjectToCSelf(parent);
This does the same CSELF drilling that the CSELF argument does.
Rick
On Sun, Aug 10, 2008 at 2:54 PM, David Ashley <dash...@us.ibm.com> wrote:
> Rick -
>
> I am having a problem trying to integrate CSELF into RexxGTK. The problem
is
> not CSELF itself, but a side affect. Consider the following:
>
> RexxMethod2(int, // Return type
> GrxWidgetSetParentWindow, // Object_method name
> RexxObjectPtr, parent, // New parent widget
> OSELF, self) // Self
> {
> GtkWidget *myWidget = (GtkWidget *)context->GetObjectVariable("CSELF")
> GdkWindow *parentWidget = (GdkWindow
> *)context->functions->GetObjectVariable(parent, "CSELF);
>
> gtk_widget_set_parent_window(myWidget, parentWidget);
>
> return 0;
> }
>
> Fetching the parent this way causes a compile problem since parent is not
an
> instance. How should I be fetching the CSELF of parent?
>
> Thanks,
> W. David Ashley
> IBM Systems and Technology Group Lab Services
> Open Object Rexx Team
> Mobile Phone: 512-289-7506
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
* -------- Original Message --------
Subject: Re: [Oorexx-devel] CSelf and mixin classes
Date: Mon, 24 Aug 2009 18:52:25 -0400
From: Rick McGuire <object.r...@gmail.com>
Reply-To: Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
To: Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
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.
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.
Rick
On Mon, Aug 24, 2009 at 6:41 PM, Mark Miesfeld<miesf...@gmail.com> wrote:
> I'm a little confused about how CSelf will work with mixin classes.
>
> (Right now I'm just using structs for the CSelf, in the future I
> intend to move to C++ classes.) Take this abbreviated example from
> ooDialog which uses mixin classes a lot.
>
> ::class 'WindowBase' public mixinclass object
>
> ::method init_windowBase external "LIBRARY oodialog wb_init_windowBase"
> ::attribute hwnd get external "LIBRARY oodialog wb_getHwnd"
>
> ::class 'PlainBaseDialog' public inherit WindowBase ResourceUtils
>
> ::class 'DialogControl' public inherit WindowBase WindowExtensions
>
> Since CSelf gets set as an object variable and since an object
> variable in WindowBase is not seen by DialogControl, (or
> PlainBaseDialog,) I though I would need separate CSelf structs for
> WindowBase and say DialogControl.
>
> So, the C++ code for an API implementation of init_WindowBase() looks
> something like this:
>
> RexxMethod1(logical_t, wb_init_windowBase, OSELF, self)
> {
> dbgPrintClassID(context, self);
>
> RexxBufferObject obj = context->NewBuffer(sizeof(CWindowBase));
> pCWindowBase pcs = (pCWindowBase)context->BufferData(obj);
> // initialization ...
> context->SetObjectVariable("CSELF", obj);
> return 0;
> }
>
> My dbgPrint shows:
> Class: TestDialog
>
> When I sort of thought it would be WindowBase. TestDialog is actually
> a subclass of PlainBaseDialog.
>
> If I now go to set a different struct in DialogControl::init():
>
> RexxMethod2(uint32_t, dlgctrl_init, OPTIONAL_POINTER, args, OSELF, self)
> {
> RexxBufferObject cdcBuf = c->NewBuffer(sizeof(CDialogControl));
> // initialziation, etc.
> context->SetObjectVariable("CSELF", cdcBuf);
> // ...
> }
>
> My WindowBase code no longer works, for example:
>
> RexxMethod1(RexxStringObject, wb_getHwnd, CSELF, pCSelf)
> {
> return pointer2string(context, ((pCWindowBase)pCSelf)->hwnd);
> }
>
> Remember, wb_getHwnd is mapped to WindowBase::hwnd(). But pCSelf
> seems to now be a pointer to a CDialogControl struct, rather than a
> pointer to a CWindowBase struct.
>
> Is this perhaps a bug, or am I more than usually confused?
>
> --
> 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
If you need more snippets, infos, please let me know. Maybe Rick or David can
clarify in the meantime.
HTH,
---rony
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
