Another cursor glitch?

[Cees de Groot]

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?

[Rob Gayvert]

Post by Cees de Groot
Hi,
In the ok button handler (an action method of a pluggable button), we
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.

[Cees de Groot]

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.

Yup, you're right, when I move it after hitting [enter] on a dialog the
busy cursor pops away.