How to add the F5 refresh functionality?

Hi All,

    I was reading one of the Ian's answers here and wonder how to take
advantage of making the refresh feature on my developments.

    I've tried this

    Shell>>onKeyPressed: aKeyEvent
"Note that F5 key is calling a user refresh that can be custimized on each
presenter."

aKeyEvent code == VK_F5

ifTrue:

[self onUserRefreshRequest.

^0].

^ super onKeyPressed: aKeyEvent

But it never happend bacause the sub presenter with focus is capturing the
keyEvents.

How could be made a shell level capture of this keyEvent? For instance, the
main shell could implement it's own onUserRefreshRequired or each dialog
that the application uses in it's own fashion.

best regards,


--
Sebastián Sastre
[hidden email]
www.seaswork.com.ar

"Sebastián Sastre" <[hidden email]> wrote in message
news:c39rr4$25ggav$[hidden email]... the
> main shell could implement it's own onUserRefreshRequired or each dialog
> that the application uses in it's own fashion.

See my posting in the thread "Changing the environment".

Regards

Blair

Dear Blair,

    this is OK but I get the same result as Ian's solution.

    The problem here comes when subpresenters "eats" the keyEvent (let's say
som tree or list view inside the main shell) in the window you add a
binding.

    I saw the binding action only when I click on some edge of the main
window because of this.

    The only solution to this is to hook every subpresenter to make them
notify the main window you want to refresh?

    regards,

--
Sebastián Sastre
[hidden email]
www.seaswork.com.ar


"Blair McGlashan" <[hidden email]> escribió en el mensaje
news:c3a1pr$25ts0f$[hidden email]... each
> > ...snip...
> > But it never happend bacause the sub presenter with focus is capturing
the

"Sebastián Sastre" <[hidden email]> wrote in message
news:c3cvk5$261u7d$[hidden email]...
> Dear Blair,
>
>     this is OK but I get the same result as Ian's solution.
>
>     The problem here comes when subpresenters "eats" the keyEvent (let's
say
> som tree or list view inside the main shell) in the window you add a
> binding.
>
>     I saw the binding action only when I click on some edge of the main
> window because of this.
>

Nope, that will not happen with an accelerator key binding. Accelerator keys
are dispatched directly from the message loop before they are delivered to
the subview with focus* therefore an accelerator key binding in the shell
will override any processing of they key press in the subview. What could
happen is that the command you have associated with the accelerator key
binding is understood by one or more of the subviews, and therefore gets
handled by them because they are earlier in the chain-of-command. The
commands associated with a key binding are routed just like any other
command. This allows accelerator keys to behave in a context sensitive way,
but only if there are multiple potential targets for the command. If the
command is uniquely understood by the shell view, then it will be handled by
the shell no matter which subview has focus, as long as Dolphin's message
loop is in control (and subject to the #queryCommand: implementation of
course).

You can see what I mean by trying this experiment with two workspaces. First
try entering 'Sound bell' in one and pressing Ctrl+E. The bell should ring.
Now go to the other and press Ctrl+O to open up a FileOpenDialog. This will
take control of the message loop away from Dolphin, and accelerator keys
defined in Dolphin will no longer work. Alt+Tab back to the original
workspace, and try pressing Ctrl+E again on the 'Sound bell' expression. You
should see that the text will be indented, because the RichEdit control
itself is now getting an opportunity to process the key, i.e. RichEdit
defines its own binding for Ctrl+E, but this is overridden by Dolphin's
normal binding of that key sequence to the #evaluateIt command.

Regards

Blair

*This is a slight simplification because each view in the parent chain is
given an opportunity to 'pre-translate' the keyboard message, but this is
not generally significant. This can all be examined by starting browsing
from InputState>>pumpMessage:

[ ... ]
> You can see what I mean by trying this experiment with two workspaces.
First
> try entering 'Sound bell' in one and pressing Ctrl+E. The bell should
ring.
> Now go to the other and press Ctrl+O to open up a FileOpenDialog. This
will
> take control of the message loop away from Dolphin, and accelerator keys
> defined in Dolphin will no longer work. Alt+Tab back to the original
> workspace, and try pressing Ctrl+E again on the 'Sound bell' expression.
You
> should see that the text will be indented, because the RichEdit control
> itself is now getting an opportunity to process the key, i.e. RichEdit
> defines its own binding for Ctrl+E, but this is overridden by Dolphin's
> normal binding of that key sequence to the #evaluateIt command.
>

Aha! This is exactly what I reported a while back. Finally understand what
causes it. Now see if I can reproduce what causes this situation when I'm
switching between windows.

Thanks Blair for this (unintended) clarification

Ted

Dear Blair,

    the one who knows, just knows...

    thank you,

--
Sebastián Sastre
[hidden email]
www.seaswork.com.ar

"Blair McGlashan" <[hidden email]> escribió en el mensaje
news:c3d7u0$26sorb$[hidden email]... keys
> are dispatched directly from the message loop before they are delivered to
> the subview with focus* therefore an accelerator key binding in the shell
> will override any processing of they key press in the subview. What could
> happen is that the command you have associated with the accelerator key
> binding is understood by one or more of the subviews, and therefore gets
> handled by them because they are earlier in the chain-of-command. The
> commands associated with a key binding are routed just like any other
> command. This allows accelerator keys to behave in a context sensitive
way,
> but only if there are multiple potential targets for the command. If the
> command is uniquely understood by the shell view, then it will be handled
by
> the shell no matter which subview has focus, as long as Dolphin's message
> loop is in control (and subject to the #queryCommand: implementation of
> course).
>
> You can see what I mean by trying this experiment with two workspaces.
First
> try entering 'Sound bell' in one and pressing Ctrl+E. The bell should
ring.
> Now go to the other and press Ctrl+O to open up a FileOpenDialog. This
will
> take control of the message loop away from Dolphin, and accelerator keys
> defined in Dolphin will no longer work. Alt+Tab back to the original
> workspace, and try pressing Ctrl+E again on the 'Sound bell' expression.
You