Registering a global event listener?
Locked
Registering a global event listener?
 
|
Hi
I would like to define a class called EventListener that implements the method #mouseMovedEvent:. The #mouseMovedEvent: should be called whenever I move the mouse around on the screen, without effecting the behaviour of the rest of the system. Until now I only found out that "InputState default grabInputFor: EventHandler new" is not the way to go. Any suggestions? Cheers, michael |
AW: Registering a global event listener?
|
|
Michael,
in the next version of VisualWorks (7.5) there will be a possibility to get a Smalltalk method called on any Windows event. With that you can do want you want. Can you wait for that? Georg -----Ursprüngliche Nachricht----- Von: Michael Meyer [mailto:[hidden email]] Gesendet: Samstag, 23. September 2006 12:53 An: [hidden email] Betreff: Registering a global event listener? Hi I would like to define a class called EventListener that implements the method #mouseMovedEvent:. The #mouseMovedEvent: should be called whenever I move the mouse around on the screen, without effecting the behaviour of the rest of the system. Until now I only found out that "InputState default grabInputFor: EventHandler new" is not the way to go. Any suggestions? Cheers, michael |
Re: AW: Registering a global event listener?
|
|
Hi Georg
thanks for the reply. Unfortunately I can't wait for vw7.5 since my problem should be solved tonight. Or at least in the next couple of days :-) I was hoping that this is a possible solution to my "A window that is always on top?" question. michael Georg Heeg schrieb: > Michael, > > in the next version of VisualWorks (7.5) there will be a possibility to get > a Smalltalk method called on any Windows event. With that you can do want > you want. > > Can you wait for that? > > Georg > > -----Ursprüngliche Nachricht----- > Von: Michael Meyer [mailto:[hidden email]] > Gesendet: Samstag, 23. September 2006 12:53 > An: [hidden email] > Betreff: Registering a global event listener? > > Hi > I would like to define a class called EventListener that implements the > method #mouseMovedEvent:. > The #mouseMovedEvent: should be called whenever I move the mouse around on > the screen, without effecting the behaviour of the rest of the system. > > Until now I only found out that "InputState default grabInputFor: > EventHandler new" is not the way to go. Any suggestions? > > Cheers, michael > > > |
Re: AW: Registering a global event listener?
|
|
Michael,
I think the only way to get the always on top behaviour is to ask the operating system for it. Which means that you will have to use DLLCC to hook into the correct operating system library. On Windows you would do this by setting a window handle's type to reserved. I did this once, but unfortunately I don't recall exactly which DLL you need to import and I don't have an image available to look it up at the moment so I can't be any more precise. Hope that I at least have given you a hint of a possible way forward. /Magnus Michael Meyer wrote: > Hi Georg > thanks for the reply. Unfortunately I can't wait for vw7.5 since my > problem should be solved tonight. Or at least in the next couple of days > :-) > I was hoping that this is a possible solution to my "A window that is > always on top?" question. > > michael > > Georg Heeg schrieb: > >> Michael, >> >> in the next version of VisualWorks (7.5) there will be a possibility >> to get >> a Smalltalk method called on any Windows event. With that you can do want >> you want. >> >> Can you wait for that? >> >> Georg >> >> -----Ursprüngliche Nachricht----- >> Von: Michael Meyer [mailto:[hidden email]] Gesendet: Samstag, 23. >> September 2006 12:53 >> An: [hidden email] >> Betreff: Registering a global event listener? >> >> Hi >> I would like to define a class called EventListener that implements the >> method #mouseMovedEvent:. >> The #mouseMovedEvent: should be called whenever I move the mouse >> around on >> the screen, without effecting the behaviour of the rest of the system. >> >> Until now I only found out that "InputState default grabInputFor: >> EventHandler new" is not the way to go. Any suggestions? >> >> Cheers, michael >> >> >> > > -- Magnus Jakt email: [hidden email] web: http://magnus.jakt.org.uk phone: +49 231 86 28 759 ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com |
Re: Registering a global event listener?
|
|
In reply to this post by Michael Meyer-6
On Sep 23, 2006, at 3:52, Michael Meyer wrote:
You may find this link interesting: add a method to InputState, something like: InputState>>verboseSend: window eventMouseMoved: event self send: window eventMouseMoved: event. Transcript print: x; nextPut: $,; print: y; space; space; endEntry Note that it just calls the original method, but then prints the current mouse point to the transcript. Then evaluate: InputState.EventDispatchTable at: 6 put: #verboseSend:eventMouseMoved: When you get tired of the annoying output to the transcript, just evaluate: InputState.EventDispatchTable at: 6 put: #send:eventMouseMoved: Hopefully, that's enough to point you in the right direction. The grand assumption of all of this, is that your happy doing this when VisualWorks has focus only. The VisualWorks InputState object only gets ui events funneled through it, when events are to go to one of its windows. This works great, until for example, you select an OSX Finder window and bring it to front. At that point... no more transcript updates. -- Travis Griggs Objologist "Is success the potential of what could be, or the reality of what is?" DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
Re: Registering a global event listener?
|
|
Wow, there is some cool stuff hidden in the image :-) Forwarding events like this really is dead easy.
I was really hoping that this could be a solution for having windows that are always on top. Unfortunately I didn't consider that the window that I #map takes focus: InputState>>mondrianSend: window eventMouseMoved: event self send: window eventMouseMoved: event. self floatingWindows do: [ :floatingWindow | floatingWindow primMap ] (#floatingWindow returns a collection of ScheduledWindows with windowType set to #popUp). Thanks anyway. Learning the low-level details of the event system was interesting non the less :-) michael Travis Griggs schrieb: > You may find this link interesting: > > http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3262015434 > > > It is... on rereading it, rather longish. I'm making an assumption here > about what you want to accomplish, but if the assumption is true, the > following two lines of code should illustrate how one can add "global > and in addition to" event handling, for mouse movement, or for anything > for that matter. > > add a method to InputState, something like: > > InputState>>verboseSend: window eventMouseMoved: event > self send: window eventMouseMoved: event. > Transcript > print: x; > nextPut: $,; > print: y; > space; > space; > endEntry > > Note that it just calls the original method, but then prints the current > mouse point to the transcript. Then evaluate: > > InputState.EventDispatchTable at: 6 put: #verboseSend:eventMouseMoved: > > When you get tired of the annoying output to the transcript, just evaluate: > > InputState.EventDispatchTable at: 6 put: #send:eventMouseMoved: > > Hopefully, that's enough to point you in the right direction. > > The grand assumption of all of this, is that your happy doing this when > VisualWorks has focus only. The VisualWorks InputState object only gets > ui events funneled through it, when events are to go to one of its > windows. This works great, until for example, you select an OSX Finder > window and bring it to front. At that point... no more transcript updates. > > -- > Travis Griggs > Objologist > "Is success the potential of what could be, or the reality of what is?" > > > > |
RE: Registering a global event listener?
|
|
In reply to this post by Travis Griggs
One note of caution; The method in Travis’s example runs
in the InputState IO process. If there is any problem in it, your image
may hang such that it cannot be debugged. When working with window
events, you should always make sure that no user processing can
occur within the IO process. The first problem with user code executing
in the IO process is that a bug can cause the image to hang. The
second problem is that application code should be excuted under the control
of a window manager process. If it also runs in the IO process then you
can have multithreading problems. Terry From: Travis Griggs
[mailto:[hidden email]] On Sep 23, 2006, at 3:52, Michael Meyer wrote:
Hi I would like to define a class called EventListener that implements the
method #mouseMovedEvent:. The #mouseMovedEvent: should be called whenever I move the mouse around
on the screen, without effecting the behaviour of the rest of the system. Until now I only found out that "InputState default grabInputFor:
EventHandler new" is not the way to go. Any suggestions? You may find this link interesting: It is... on rereading it, rather longish. I'm making an assumption here
about what you want to accomplish, but if the assumption is true, the following
two lines of code should illustrate how one can add "global and in
addition to" event handling, for mouse movement, or for anything for that
matter. add a method to InputState, something like: InputState>>verboseSend: window eventMouseMoved: event self
send: window eventMouseMoved: event. Transcript print:
x; nextPut:
$,; print:
y; space; space; endEntry Note that it just calls the original method, but then prints the
current mouse point to the transcript. Then evaluate: InputState.EventDispatchTable at: 6 put: #verboseSend:eventMouseMoved: When you get tired of the annoying output to the transcript, just
evaluate: InputState.EventDispatchTable at: 6 put: #send:eventMouseMoved: Hopefully, that's enough to point you in the right direction. The grand assumption of all of this, is that your happy doing this when
VisualWorks has focus only. The VisualWorks InputState object only gets ui
events funneled through it, when events are to go to one of its windows. This
works great, until for example, you select an OSX Finder window and bring it to
front. At that point... no more transcript updates. -- Travis Griggs Objologist "Is success the
potential of what could be, or the reality of what is?"
DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
| Free forum by Nabble | Edit this page |