Alexander, Martin
[Alexander wrote]
> While CVS is non-available I am looking for a summary of what's still
> to be done related to the "BaseClass" changes:
>
> - there was this thread "RE: lesstif-CVS bug: Broken pipe with Grace "
> w/o a final conclusion. As Martin told me his last suggestion isn't
> the way to go (-> realize called twice)
[Martin wrote]
> Yes, sorry, I was being dense not seeing that wc changes.
>
> Since VSEP_RealizeCallback needs a specific class, why not check for
> XmIsVendorShellExt(ext->widget)?
Sorry, BellSouth did us the favor of changing area codes in our switch
Friday, which brought down the ISDN link. Thanks for the pointer
to mail-archive, Alexander - handy to see what I missed.
Ok, here's some more explanation:
XmDialogShell inherits from TransientShell, which inherits from
VendorShell (xc/lib/Xt/Shell.c). XmDialogShell has a VSEP,
because initialize_prehook() is XmInherited up the chain too.
XmDialogShell defines realize() as XtInheritRealize. TransientShell
defines a realize method, which calls
transientShellWidgetClass->core_class.superclass->core_class.realize
(whew!), which is VendorShell's realize.
Because of the BaseClass hooks, RealizeWrapper is called twice.
The widget passed to RealizeWrapper() in both cases is the dialog
shell; in both invocations it has a VSEP object. So in other words,
XmIsDialogShell(w) == true
and
XmIsVendorShellExt(ext->widget) == true
*both* times the function is called. So to avoid calling
VendorExtRealize() twice, you need to check and see when the widget
class is really vendor. I suppose a better check would be
wc == vendorShellWidgetClass
might make more sense.
(wanders away to read Xt code in R6).
Uh, oh. I think there's another problem here. People who use
the threadsafe version of libXt may see a segfault when the
callback is called - XtCallCallbackList in this case needs
XtWidgetToApplicationContext() to work, which it doesn't for
ExtObjs. It works ok as long as you don't use the threadsafe
version.
Mitch
