button command keyword selectors?

 From the View Composer, is there a way to have a button command be a keyword
selector with arguments?

For example, I would like to convert #onAKeyPressed to #onPressedKey: $A.



Shaping

Shaping,

> From the View Composer, is there a way to have a button command be a
> keyword selector with arguments?
>
> For example, I would like to convert #onAKeyPressed to #onPressedKey: $A.

The menu command dialog accepts a Smalltalk statement in the Command field,
so just enter ...

Message selector: #onPressedKey: argument: $A

Dolphin will always convert it into the multiple argument format so if you
prefer you can enter that instead ...

Message selector: #onPressedKey: arguments: #($A)

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Thanks.  I'm assuming also that blocks are acceptable.

Shaping

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...

How does one set the accelerator key for a button?  I need to use Shift,
Ctrl, and Alt modifier keys in the accelerators.


Shaping


"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...

> Thanks.  I'm assuming also that blocks are acceptable.

Nope.  If you try it you will see that Dolphin ignores the new entry in the
dialog and reverts to the previous value.  You can only use Symbols or
Messages, classes that conform to the #commandMessage protocol.

If you really need a block then put it in the command method.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Shaping,

> How does one set the accelerator key for a button?  I need to use Shift,
> Ctrl, and Alt modifier keys in the accelerators.

The properties dialog for each menu item contains a box named "Accelerator
Key".  Select that and press the key combination that you want to use -
Dolphin does the rest.  The key combination will also be added to the menu
items descriptive text.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Shaping,

I've just realized that you are talking about buttons and not menus.  I must
_really_ learn to read before replying.

For buttons the command still has to be a Symbol or a Message.  Things like
blocks will be accepted as the #command but will walkback when the button is
displayed.

I don't know about accelerator keys in buttons.  I've just had a quick try,
using the AcceleratorKey setting in the button's CommandDescription,  and it
doesn't seem to work, I may well be missing something though.

It looks like the easiest way (for a standalone button) would probably be to
add an #additionalAccelerators method to your Shell. As in

additionalAccelerators
    ^#(
        #(#hello 'CTRL+SHIFT+H')
        #(#world 'ALT+F5'))

If you duplicate the command defined here with the command sent by the
button then the effect should be the same as if each button has an
accelerator.  I can't say I've ever used this method though.

Note that if you have a menu option that sends the same command as the
button then you could add the accelerator there.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

I tried adding such a method, as well as a #defaultAdditionalAccelerators on
the class-side of the presenter connected to the view containing the button,
but neither seems to work.

>
> If you duplicate the command defined here with the command sent by the
> button then the effect should be the same as if each button has an
> accelerator.  I can't say I've ever used this method though.

There must be something else that must be done.  Does anyone know?


Shaping

Shaping wrote:

> There must be something else that must be done.  Does anyone know?

Just overriding #defaultAdditionalAccelerators (and doing nothing else) works
for me in a quick test.  However, I must admit that I'm pleasantly surprised
whenever any kind of accelerator works with buttons -- there seems to be some
sort of deep Windows nastiness that makes them flaky.

FWIW, I've had most luck by /not/ attempting to tell Dolphin about the
accelerators, but just use an '&' in the button's label.  E.g. a button
labelled "Do &Something" will -- by some internal Windows magic -- respond to
ALT+S by firing itself.

One downside to letting Windows handle it is that it doesn't respect Dolphin's
normal/default Chain-of-Command for command routing, so that a button will fire
even if the focus is a sub-view that's unrelated to the one containing the
button.  I find the inconsistency irritating, though not (quite) so irritating
that I've ever taken the time to sort out what's /really/ going on and work out
how to control it.

    -- chris

Shaping,

> I tried adding such a method, as well as a #defaultAdditionalAccelerators
> on the class-side of the presenter connected to the view containing the
> button, but neither seems to work.

I did try #additionalAccelerators before I posted and it seemed to work OK.
That was adding the method and target directly to a Shell so the problem
might be that your presenter is not being included as a target.  Try adding
a method, of the same name and just containing a breakpoint, to your shell
class and see if that is reached when the key combination is pressed.

You may need an #addToCommandRoute: in there somewhere.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Chris,

> FWIW, I've had most luck by /not/ attempting to tell Dolphin about the
> accelerators, but just use an '&' in the button's label.  E.g. a button
> labelled "Do &Something" will -- by some internal Windows magic -- respond
> to ALT+S by firing itself.

That's the way I tend to do it as well, KISS strikes again :-)

Shaping did mention that he wanted to use CTRL and SHIFT as accelerators as
well and, as far as I know, there's no way of specifying them in the label -
is there?

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Shaping wrote:

> There must be something else that must be done.  Does anyone know?

Just a thought: is the presenter with the additional accelerators one of your
dynamically added sub-components ?   If so then you will probably have to
ensure that the containing ShellView's #updateCombinedAcceleratorTable method
is called when you plug/unplug a sub-component.

    -- chris

Ian,

> Shaping did mention that he wanted to use CTRL and SHIFT as accelerators
> as well and, as far as I know, there's no way of specifying them in the
> label - is there?

Not that I know of either -- I'd forgotten or failed to notice the bit about
other modifiers :-(

OTOH, I think that I (if I were a user of this system) would prefer to have
simple accelerators for operations wherever possible -- at least for the ones
that were important enough to justify taking up screen space for a whole
button.  (Though I can imagine exceptions to that "rule" too.)

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:425a5503$0$38038$[hidden email]...
> Ian,
>
>> Shaping did mention that he wanted to use CTRL and SHIFT as accelerators
>> as well and, as far as I know, there's no way of specifying them in the
>> label - is there?
>
> Not that I know of either -- I'd forgotten or failed to notice the bit
> about
> other modifiers :-(

One of the problems is that I have a genuine need for multiple uses of the
same keys, like the number keys.  I really do need three variations, as in
'1' 'Shift-1', and Ctrl-1.  Or, if I had to settle:  Alt-1 (which I verified
works by use of & in the button label), 'Shift-1', and 'Ctrl-1'.


Shaping

>> There must be something else that must be done.  Does anyone know?
>
> Just a thought: is the presenter with the additional accelerators one of
> your
> dynamically added sub-components ?

No, all the Windows GDI stuff happens /around/ the OGL pluggable view.  I
have a bunch of buttons on the top-level shell view, and I put method


additionalAccelerators
    ^#(#(#myMethodInTheShell 'CTRL-1')
      )

in that shell.


I started the app, and pressed CTRL-1.  The breakpoint in myMethodInTheShell
was not hit.  Also, the breakpoint in #additionalAccelerators was not hit.
The info in this method is not even being used.  So how can this possibly
work?

Shaping

Is there any reason you have to use buttons and commands rather than just
key events (e.g., keyPressed:) hooked up to the presenter (or the view)?
Something in #createSchematicWiring like:

     myPresenter when: #keyPressed: send: #onKeyPressed: to self

Then you could just check for your keyboard states in the KeyEvent that gets
passed as the argument.

Don


"Shaping" <[hidden email]> wrote in message
news:[hidden email]...

> Is there any reason you have to use buttons and commands rather than just
> key events (e.g., keyPressed:) hooked up to the presenter (or the view)?
> Something in #createSchematicWiring like:
>
>     myPresenter when: #keyPressed: send: #onKeyPressed: to self
>
> Then you could just check for your keyboard states in the KeyEvent that
> gets passed as the argument.


This sounds good, and I tried it, but it didn't work.

MyShell>>createSchematicWiring
  self when: #keyPressed: send: #onKeyPressed: to: self

does not produce a send of #onKeyPressed: when a key is pressed when MyShell
is up.

The forwarding of #keyPressed: from the View looks to be in place, but I
cannot trap on any key pressed event in MyShell.


Shaping

My wiring appears circular, anyway.  And wiring to the view instead doesn't
make sense, because the keystrokes seem to be passed from View to Presenter,
anyway.

Is there a general scheme in place for handling key strokes?  If so, how
does this scheme relate to Presenters and Views, as sources and targets of
such events?  There is the additional issue of the distinction between
#keyPressed: (trigger) and #onKeyPressed: (response).


Shaping

This didn't work because #createSchematicWiring was not sent, because I
neglected to super send it in my Shell's override of
Presenter>>onViewOpened.


Shaping

View>>onKeyPressed: aKeyEvent
"Default handler for a key press event.
Accept the default window processing."
self presenter trigger: #keyPressed: with: aKeyEvent.
^self defaultWindowProcessing: aKeyEvent

This method retriggers the event in the presenter, to which I linked in the
Presenter via

self when: #keyPressed: send: #onKeyPressed: to: self

Note also that

Presenter>>onKeyPressed: aKeyEvent
"Default handler for the receiver's view receiving a key press event."
^self view onKeyPressed: aKeyEvent

retriggers in the View.

I have in MyShell an #onKeyPressed: preventing this.  Still this method is
not hit.



Shaping