WbPro5.5, VA4.5 EwTableList problem

3 views
Skip to first unread message

Lothar Mischke

unread,
Oct 11, 2000, 3:00:00 AM10/11/00
to
Hi!

After upgrading WbPro to 5.5 we encounter the following problem:
We have a WbApplication holding an EwTableList. The default action
callback is hooked to a method which does some processing on the
selected item and then closes the WbApplication.

When the callback is triggered by double clicking everything works fine.
But when the return key is pressed an additional method call is made
from the CwDrawingArea to itself (#keyPress:clientData:callData:) after
triggering the callback for the EwTableList. As a result of the
previously launched callback all widgets are destroyed (window is
closed), and we get an exception.

Is there a fix for this bahaviour, or am I missing something?

TIA

Lothar

Eric Clayberg

unread,
Oct 11, 2000, 3:00:00 AM10/11/00
to
"Lothar Mischke" <mis...@self.de> wrote in message
news:39E4714F...@self.de...

>
> After upgrading WbPro to 5.5 we encounter the following problem:
> We have a WbApplication holding an EwTableList. The default action
> callback is hooked to a method which does some processing on the
> selected item and then closes the WbApplication.
>
> When the callback is triggered by double clicking everything works fine.
> But when the return key is pressed an additional method call is made
> from the CwDrawingArea to itself (#keyPress:clientData:callData:) after
> triggering the callback for the EwTableList. As a result of the
> previously launched callback all widgets are destroyed (window is
> closed), and we get an exception.

Sounds like a simple timing problem. The easy fix would be to delay the
action in the first callback using #asyncExecInUI:. That should allow the
second callback to complete its business before the window is destroyed.

-Eric Clayberg
Sr. Vice President of Product Development
Instantiations, Inc.
mailto:clay...@instantiations.com
http://www.instantiations.com

Lothar Mischke

unread,
Oct 12, 2000, 3:00:00 AM10/12/00
to
Eric Clayberg wrote:
<snip>
> Sounds like a simple timing problem. The easy fix would be to delay the
> action in the first callback using #asyncExecInUI:. That should allow the
> second callback to complete its business before the window is destroyed.
>
> -Eric Clayberg
> Sr. Vice President of Product Development
> Instantiations, Inc.
> mailto:clay...@instantiations.com
> http://www.instantiations.com

We had a similar idea. But how come the callback order has been changed
(or is the order of executing these automatically created callbacks just
chosen randomly)?

Regards

Lothar

Eric Clayberg

unread,
Oct 12, 2000, 3:00:00 AM10/12/00
to
"Lothar Mischke" <mis...@self.de> wrote in message
news:39E56FDD...@self.de...

>
> > Sounds like a simple timing problem. The easy fix would be to delay the
> > action in the first callback using #asyncExecInUI:. That should allow
the
> > second callback to complete its business before the window is destroyed.
>
> We had a similar idea. But how come the callback order has been changed
> (or is the order of executing these automatically created callbacks just
> chosen randomly)?

I don't know that the callback order was changed. It could simply be a case
of a new callback being added in the later version. The order is not random,
however. Callbacks fire in the order in which they were added to the widget.

-Eric

Lothar Mischke

unread,
Oct 13, 2000, 3:00:00 AM10/13/00
to
O.K. Thank you for your explanantion, Eric. We tried the fix you
suggested, and it works.

Best regards

Lothar

Reply all
Reply to author
Forward
0 new messages