Keystrokes a la WM_CHAR

I need to receive notification each time a key is pressed and make a
decision whether or not to process it based on application criteria. In
classic Windows C code parlance I need to respond to WM_CHAR messages in the
Windows message stream. The closest thing I can see is a
CapturingInteractor -- the superclass of MouseTracker but this dosn't seem
to be quite it. Does Dolphin generate keyboard events that I can register
interest in with "when:send:to:" ? Any ideas where to start ? -- Thanks --
Geoff W

Geoff,

> I need to receive notification each time a key is pressed and make a
> decision whether or not to process it based on application criteria. In
> classic Windows C code parlance I need to respond to WM_CHAR messages in
the
> Windows message stream. The closest thing I can see is a
> CapturingInteractor -- the superclass of MouseTracker but this dosn't seem
> to be quite it. Does Dolphin generate keyboard events that I can register
> interest in with "when:send:to:" ? Any ideas where to start ? -- Thanks --

See if #keyTyped: meets your needs.  Views trigger it off of their
presenters.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Geoff Waddington wrote:

> I need to receive notification each time a key is pressed and make a
> decision whether or not to process it based on application criteria. In
> classic Windows C code parlance I need to respond to WM_CHAR messages in
> the Windows message stream. The closest thing I can see is a
> CapturingInteractor -- the superclass of MouseTracker but this dosn't seem
> to be quite it. Does Dolphin generate keyboard events that I can register
> interest in with "when:send:to:" ? Any ideas where to start ?

I suspect that you've already looked at this, and I'm hardly an expert on this
stuff anyway, but here goes, I'd appreciate any corrections...

If all you want is notification of keys pressed then the default View handling
(View>>onKeyPressed: and View>>onKeyTyped:) triggers corresponding #keyPressed:
events off the Presenter.  However I don't think that allows you to prevent the
default processing of those events.

If you are writing your own View class, then you can (obviously) override those
methods to do anything you want.  Architecturally, I think it's "OK" for a View
subclass to consume/discard an event (I do it, and it doesn't seem to cause
problems or be working against the way the system "wants" to work).

Othewise, I believe that the intended "clean" way to do this is to install your
own custom interactor into the View.  It should handle #onKeyPressed: as it
sees fit, and pass everything else on to the View's original interactor (which
is actually its Presenter by default).  You'll need to create your own subclass
of Interactor that overrides onKeyPressed: and install it like:

    presenter := ... whatever.
    interactor := MyInteractor forPresenter: presenter.
    presenter view interactor: interactor.

View>>interactor: answers the previous interactor should you need to be able to
remove your custom interactor (from the sound of it, that's not something that
you will need to do).   The default behaviour of the various Interactor methods
is just to pass events on to the original presenter.

    -- chris

Thanks Chris, the View class >> publishedEventsOfInstances method seems a
logical place to start. Although I'm an old Smalltalker (VAST VW) I haven't
had the luxury of using ST for 6 years and, as well, am just discovering the
excellent MVP paradigm (in a certain sense it's what we always bent MVC
around to anyway in practical situations using Application Model). Thanks
for bearing with me as the rust clears and the new vision comes into
focus -- Geoff
"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...

> Geoff Waddington wrote:
>
> > I need to receive notification each time a key is pressed and make a
> > decision whether or not to process it based on application criteria. In
> > classic Windows C code parlance I need to respond to WM_CHAR messages in
> > the Windows message stream. The closest thing I can see is a
> > CapturingInteractor -- the superclass of MouseTracker but this dosn't
seem
> > to be quite it. Does Dolphin generate keyboard events that I can
register
> > interest in with "when:send:to:" ? Any ideas where to start ?
>
> I suspect that you've already looked at this, and I'm hardly an expert on
this
> stuff anyway, but here goes, I'd appreciate any corrections...
>
> If all you want is notification of keys pressed then the default View
handling
> (View>>onKeyPressed: and View>>onKeyTyped:) triggers corresponding
#keyPressed:
> events off the Presenter.  However I don't think that allows you to
prevent the
> default processing of those events.
>
> If you are writing your own View class, then you can (obviously) override
those
> methods to do anything you want.  Architecturally, I think it's "OK" for a
View
> subclass to consume/discard an event (I do it, and it doesn't seem to
cause
> problems or be working against the way the system "wants" to work).
>
> Othewise, I believe that the intended "clean" way to do this is to install
your
> own custom interactor into the View.  It should handle #onKeyPressed: as
it
> sees fit, and pass everything else on to the View's original interactor
(which
> is actually its Presenter by default).  You'll need to create your own
subclass
> of Interactor that overrides onKeyPressed: and install it like:
>
>     presenter := ... whatever.
>     interactor := MyInteractor forPresenter: presenter.
>     presenter view interactor: interactor.
>
> View>>interactor: answers the previous interactor should you need to be
able to
> remove your custom interactor (from the sound of it, that's not something
that
> you will need to do).   The default behaviour of the various Interactor
methods
> is just to pass events on to the original presenter.
>
>     -- chris
>
>