Disabled views re-enabling when focus of Shell is regained

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabled views re-enabling when focus of Shell is regained

G Krupa-2
All,

I'm disabling a view (PushButton) in my code, but it is re-enabled if the
owning Shell loses and subsequently regains focus.

To disable:

MyShell>>disableButton2
    ( self view viewNamed: 'Button2' ) disable

I do not ever re-enable the view in my code.  I'm not sure if this is
something in Dolphin's default View code (I haven't found anything yet) or
maybe Windows.

Has anyone encountered this?  Am I doing something wrong or not doing
something I should?

The button is in fact disabled after the method executes, but I can't figure
out why/how it's being enabled, since my code doesn't enabled it anywhere (I
haven't even written that method yet!).

Cheers,

--GK


Reply | Threaded
Open this post in threaded view
|

Re: Disabled views re-enabling when focus of Shell is regained

G Krupa-2
I've been poking around and must have been daft the first time.  The cause
is in fact to be found in Dolphin and has a reasonable explaination.

When a Shell receives focus, it re-validates all components.  For a
PushButton, this causes the button's command (see #command method) to be
re-queried to make sure it's still valid.  I believe this is also the code
used when the button is first displayed (i.e., #validateUserInterface).

If the command query is successful, the control is enabled, otherwise it's
disabled.

So for it to work as expected, I'd have to change the view's command as well
as disabling it, so ensure it isn't re-enabled when it's owning shell gets
focus.

Cheers,

--GK


Reply | Threaded
Open this post in threaded view
|

Re: Disabled views re-enabling when focus of Shell is regained

Blair McGlashan-2
In reply to this post by G Krupa-2
"G Krupa" <[hidden email]> wrote in message
news:3fa72fc0$[hidden email]...
> All,
>
> I'm disabling a view (PushButton) in my code, but it is re-enabled if the
> owning Shell loses and subsequently regains focus.
> ...

Dolphin has a unified framework for managing the enablement of commands from
menus, toolbars, buttons, etc. The class comment of CommandDescription
explains all.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Disabled views re-enabling when focus of Shell is regained

Ian Bartholomew-18
In reply to this post by G Krupa-2
GK,

> Has anyone encountered this?  Am I doing something wrong or not doing
> something I should?

Dolphin has a separate mechanism for enabling/disabling widgets that
send commands - buttons, menus etc.  You actually enable/disable the
_command_ rather than the widget itself - which has a number of
advantages.

It's all done via a method called #queryCommand:and there are a lot of
examples in the base image.  It has also been mentioned in the newsgroup
a number of times, a trawl through the archive for #queryCommand: should
get a lot of hits.

(very) Basically -

You add a #queryCommand: method to a Presenter.
This method is called every time Dolphin wants to the user interface and
is called once for every command that can be generated from that
Presenter.
The command being queried is passed within the argument (a CommandQuery)
You enable/disable (or check/uncheck) the command using the argument

queryCommand: aCommandQuery
    | command |
    command := aCommandQuery command.
    command == #myTestButton
        ifTrue: [
            aCommandQuery isEnabled: self shouldEnableTestButton.
            ^true].
    command == #anotherTestButton
        ifTrue: [
            aCommandQuery isEnabled: self shouldEnableAnotherTestButton.
            ^true].
    ^super queryCommand: aCommandQuery

--
Ian


Reply | Threaded
Open this post in threaded view
|

Re: Disabled views re-enabling when focus of Shell is regained

G Krupa-2
Thanks Ian.

Is there a preferred way to have the button re-validated other than calling
#validateUserInterface when I want to disable the control (assuming the
subsequent #queryCommand: will disabled it)?  I originally though
invalidating the PushButton view would work, but it didn't.

The only other thing I could think of was to disable it like before, but
having added the #queryCommand: method, rely on that to keep it disabled.
Seemed sort of kludgish, though.

I only ask because not too many people seem to send #validateUserInterface
except those you'd expect, like Presenters, and various subclasses.

Cheers,

--GK


Reply | Threaded
Open this post in threaded view
|

Re: Disabled views re-enabling when focus of Shell is regained

Ian Bartholomew-18
GK,

> Is there a preferred way to have the button re-validated other than
> calling #validateUserInterface when I want to disable the control
> (assuming the subsequent #queryCommand: will disabled it)?

In normal circumstances Dolphin does a pretty good job of making sure
that the UI is kept up to date, validating whenever the UI may have
changed.  If your application does something in the background that may
require an extra UI update then sending #validateUserInterface to the
topShell seems a reasonable thing to do.  Sending
#invalidateUserInterface is probably the preferred way (as it waits
until the next idle time before validating) but it doesn't always seem
to work as expected.

You _may_ be able to get something working by enabling/disabling buttons
and ensuring that the #queryCommand method reinforces the required state
but I've always found that this sort of thing, trying to sync two
different ways of doing something, usually leads to problems.

--
Ian