Another cursor glitch?

[Rob Gayvert]

Cees de Groot wrote:

> Hi,
>
> In the ok button handler (an action method of a pluggable button), we 
> have  a method that looks like:
>
> WxCursor withBusyCursorDo: [
>     disabler _ WxWindowDisabler.
>     ["... do stuff ..."]
>         ensure: [disabler delete]]
>
> What I've noticed is that if you hit enter on such a dialog, the busy  
> cursor stays up. If you click the button, the busy cursor stays up 
> until  you release the button - it then reverts to a normal button?
>
> Is that our problem, wxSqueak's or wxWidgets?

I think the problem is with wxWindowDisabler. If you add a short delay 
before creating the disabler (or make the event handler deferred), 
you'll see a busy cursor, but it reverts to a normal cursor as soon as 
you move the mouse.  And if you create the disabler first and then set 
the busy cursor, you'll never see a busy cursor. So in your dialog, if 
you hit enter and then move the mouse, does the cursor change? I suspect 
that a busy cursor won't show on a disabled window, at least once it's 
been updated by some kind of event.

So my guess is that it's a wx problem, but one that we have to find a 
way of dealing with.