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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |