On Wed, 01 Dec 2004 10:32:57 +1300, Paul Murrell <[EMAIL PROTECTED]> wrote :
>Hi > > >Duncan Murdoch wrote: >> On Wed, 01 Dec 2004 08:55:27 +1300, Paul Murrell >> <[EMAIL PROTECTED]> wrote : >> >> >>>This sounds like the general problem of being able to capture keyboard >>>input on a graphics device (a key-stroke equivalent of dev_locator). >>>Robert has been keen on this for a while too. I've now committed the getGraphicsEvent function with mouse and keyboard support. So far only the windows screen device knows how to work with it, because that's all I've got. It's in the R-devel build I just uploaded, which should be downloadable by tomorrow. If someone wants to write support for other platforms, I'd be happy to help. I imagine the implementation will change a bit when we do the first one, because I don't know the other platforms at all, and have probably made some Windows-centric assumptions. But at least it's a starting point. Here's a quick summary of how it currently looks: The device is assumed to be based on the NewDevDesc structure. There are new fields canGenXXX to indicate that it can generate mouse or keyboard events; getGraphicsEvent aborts if you try to set an event on a device that doesn't support them. When getGraphicsEvent is active, it sets a gettingEvent field to TRUE, saves its environment into eventRho, and calls the getEvent callback. This callback is supposed to run an event loop, looking for user input. When it sees an event that it is supposed to handle, it calls a doMouseXXX or doKeybd function, and those translate the message into an R call to call the handler, and put the result in eventResult. The whole process can be aborted if the user interrupts (e.g. by hitting Esc in Rgui); in that case, another callback called onExit is called to clean up. Comments are welcome. Duncan Murdoch ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel