Greetings,
 
I would like to use the SPIExceptionHandler
(http://library.gnome.org/devel/at-spi-cspi/stable/at-spi-cspi-SPI-main-
loop-and-initialization.html#SPIExceptionHandler), I have encountered
some problems and had some success.
 
1. The return type is SPIBoolean, but the documentation does not say
what are the consequences of returning SPI_TRUE or SPI_FALSE.  I have
some experimental results, below.
 
2. I cannot find any evidence in the LDTP that SPI Exception handling is
being tested.  I'm looking here:
http://cgit.freedesktop.org/ldtp/ldtp/tree/src.  Are there other places
to look?  I'm looking at this because when I asked Nagappan where he
found documentation that "window:destroy" was a valid event he said he
looks at the at-spi test code.
 
3. I followed the instructions for installing the exception handler,
which seemed to succeed.  I put this line of code in my test program:
 
    SPI_registerGlobalEventListener(genericListener, "window");
 
Which causes this error message on stderr:

(sbq:24945): GLib-GObject-CRITICAL **: g_signal_lookup: assertion `name
!= NULL' failed
** (sbq:24945): WARNING **: Invalid signal type (null)
 
I was hoping that this exception would be sent to my new exception
handler, but it is not, the messages are still displayed on stderr.  Is
there any way, other than redirecting stderr, to prevent this message
from displaying?
 
 
On the positive side, I recalled an email from Nagappan:
 
    Sent: Wednesday, November 19, 2008 1:23 PM
    Subject: Re: [g-a-devel] Unknown CORBA exception?


    Hi Will,

    This happens in most of the Ubuntu / RHEL systems, some of the
application is listed as <dead> in accerciser. In Python, we don't
notice them, as we can handle this in try / except block, but in C, we
have this limitation :)

 
So I wrote a routine to display all the children of the desktop.  My
exception handler did indeed get called for the 9th child application,
the one that is causing this message to display on stderr:
 
Warning: AT-SPI error: pre method check: add: Unknown CORBA exception
id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0'
 
If the exception handler returns SPI_FALSE, this message will continue
to display on stderr.  If it returns SPI_TRUE, this message is not
displayed.  In both cases my application seemed to behave as expected.
So I'm going to return SPI_TRUE from the handler (I'm logging the
exception to a logfile).  Any advice from someone who knows exactly how
exception handling works would be appreciated.
 
-Sam
 
 
 
_______________________________________________
Gnome-accessibility-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

Reply via email to