search for: setgraphicseventhandlers

...rom flickering, which restricts me to the "cairo" X11 device. I'd like to be able to add interactivity to the oscilloscope display, for instance to bind a key to save the current plot to a file, or to bind keys for adjusting the time scale etc. However, I ran into two problems: (1) setGraphicsEventHandlers only works on the "Xlib" X11 device, which doesn't support buffering via dev.hold() - it flickers. (2) getGraphicsEvent and friends lack some interface features which are needed to use the functions in an asynchronous fashion. Typically, event listener library functions have a "...

Hi Is the correct patch to remove the setting of the gettingEvent flag or would it be better to flip the TRUE/FALSE setting (set to TRUE before handling then reset to FALSE after handling) ? Also, for this patch and for the other two you sent, one difficulty will be with testing the patches. I have no testing code for this, so would need at least a test or two from you (ideally someone

...he event handlers or for a user-interrupt for it to halt (as per the R manual). The only way that I've thought of to make this work is using setTimeLimit to kill the function after a set time - here's a (messy) example: setTimeLimit(cpu = 1) plot(0, 0) eventEnv <- getGraphicsEventEnv() setGraphicsEventHandlers(prompt = 'Test') while(TRUE) { err <- try(q <- getGraphicsEvent(), silent=TRUE) print(err) } # Not run setTimeLimit(cpu = Inf) but setTimeLimit doesn't seem to kill getGraphicsEvent() properly, as running this code just ends up with the repeated returned error of "Err...

... I just realized that setGraphicsEventHandlers or getGraphicsEvent could have an 'onIdle' callback, to be called somewhere in the polling loop of gevents.c:163 - I think this would solve my problem #2 in a minimally disruptive way. On Mon, Jun 06, 2016 at 06:38:45PM -0700, frederik at ofb.net wrote: > Hi R-Devel, > > I've...

doKeybd() gets called in CHelpKeyIn() and NHelpKeyIn() in library/grDevices/src/devWindows.c, where the call is encapsulated in an 'if (dd->gettingEvent)' block. So the only times this code ever calls doKeybd() is when gettingEvent is in fact set. Further, it's called in two locations in X11_eventHelper(), in modules/X11/devX11.c, where the state of gettingEvent seems to be moot

Hi Frederik, >>>>> <frederik at ofb.net> >>>>> on Tue, 7 Jun 2016 15:20:05 -0700 writes: > ... I just realized that setGraphicsEventHandlers or > getGraphicsEvent could have an 'onIdle' callback, to be > called somewhere in the polling loop of gevents.c:163 - I > think this would solve my problem #2 in a minimally > disruptive way. I hope you will get some feedback about this by one of the graphics/d...

Hey all. As in general it's a bad idea to allow an event handler to generate an event, and as comments in the code seem to suggest this isn't the intention either, I was wondering about recursion in getGraphicsEvent(). In main/gevents.c, both doMouseEvent() and doKeybd() have the following line; dd->gettingEvent = FALSE; /* avoid recursive calls */ And they reset it to TRUE

...facing as problem already known and linked to the use of getGraphicsEvent(prompt = "Waiting for input", ???????????????? onMouseDown = NULL, onMouseMove = NULL, ???????????????? onMouseUp = NULL, onKeybd = NULL, ???????????????? onIdle = NULL, ???????????????? consolePrompt = prompt) setGraphicsEventHandlers(which = dev.cur(), ...) getGraphicsEventEnv(which = dev.cur()) setGraphicsEventEnv(which = dev.cur(), env) The problem rises when trying to get interrupts generated by pressing mouse buttons and, at the same time, interrupts coming from widgets. The idea is to locate points under a spectrum and...

...? The startup message now includes the platform and if used, sub-architecture: this is useful where different (sub-)architectures run on the same OS. ? The getGraphicsEvent() mechanism now allows multiple windows to return graphics events, through the new functions setGraphicsEventHandlers(), setGraphicsEventEnv(), and getGraphicsEventEnv(). (Currently implemented in the windows() and X11() devices.) ? tools::texi2dvi() gains an index argument, mainly for use by R CMD Rd2pdf. It avoids the use of texindy by texinfo's texi2dvi >= 1.157, sinc...

...? The startup message now includes the platform and if used, sub-architecture: this is useful where different (sub-)architectures run on the same OS. ? The getGraphicsEvent() mechanism now allows multiple windows to return graphics events, through the new functions setGraphicsEventHandlers(), setGraphicsEventEnv(), and getGraphicsEventEnv(). (Currently implemented in the windows() and X11() devices.) ? tools::texi2dvi() gains an index argument, mainly for use by R CMD Rd2pdf. It avoids the use of texindy by texinfo's texi2dvi >= 1.157, sinc...