1,5 year later...
I installed a more recent distribution of GTK (the all-in-one bundle from
http://www.gtk.org/download/win32.php), made a rebuild and still get the
same problem.
window = .GTKWindow~new(.gtk~GTK_WINDOW_TOPLEVEL)
window~show()
CSELF is null when executing the native method GrxWidgetShow.
Reminder of the inheritance (from super to subclass) :
GtkWidget ~show
GtkContainer
GtkWindow ~new ~init ~set_title
What I see under debugger :
When running .GTKWindow~new, the scope of the native method GrxWindowNew is
GTKWINDOW. The value of CSELF is stored in a dictionnary (say DictWindow)
whose scope is GTKWINDOW. This dictionary is referenced by the window :
window.objectVariables == DictWindows
When running window~show, the scope of the native method GrxWidgetShow is
GTKWIDGET. When RexxNativeActivation::processArguments search for CSELF,
the search is started from the scope GTKWIDGET (see below, the reference to
DictWindow has been overwritten), and NULL is returned.
Why the search start from scope GTKWIDGET :
In RexxNativeActivation::cself, there is a call to methodVariables().
Since RexxNativeActivation.objectVariables == NULL (I think it's normal),
the next line in methodVariables is executed :
this->objectVariables =
this->receiver->getObjectVariables(method->getScope())
but here, the method's scope is GTKWIDGET...
In RexxObject::getObjectVariables, no dictionary at this scope is found,
and a new one (say DictWidget) is created at scope GTKWIDGET. Its next
dictionnary is set to DictWindow (bad order, no ? : superclass -->
subclass). And the current reference to DictWindow is overwritten (the
receiver is the window) :
window.objectVariables = DictWidget
Obviously, the overwritting should not happen. But difficult for me to say
what to fix :
- method->getScope() in RexxNativeActivation::methodVariables ?
- the sequence of actions in RexxObject::getObjectVariables ?
- the way how the native methods and CSELF are used in RexxGtk ?
Jean-Louis
2010/5/14 David Ashley <david.ashley....@gmail.com>
> **
> Very strange. This has just started with the recent fixes to GTK applied
> by Fedora on my system. It worked fine until recently.
>
> Still trying to figure out what has changed but this may be a GTK bug.
>
> David Ashley
>
>
> On 05/14/2010 01:37 PM, Jean-Louis Faucher wrote:
>
> I'm testing RexxGtk and I get an assert error in test2-1.rex.
> Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed
> David, is it working for you ?
>
> Maybe I'm totally wrong, but it seems that the CSELF assignment should be
> moved to GtkWidget.
>
> When debugging "show", I see that CSELF is NULL
> If I understand correctly, the CSELF variable is searched from subclass to
> superclass.
> When ~show is called, is it the pool of GtkWidget which is used as
> starting point ?
>
> The inheritance is like that (from super to subclass) :
> GtkWidget ~show
> GtkContainer
> GtkWindow ~new ~init ~set_title
>
>
> Jean-Louis
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Oorexx-devel mailing
> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
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
