for a macro (see attachment) I want to process keyboard events. I have
two difficulties with this task:
1: after calling Draw() for some histogram in an event handler, the mouse has to be moved before keyboard events are processed again. This is because in TCanvas::HandleInput(), the long switch statement has a “return” for the kKeyPress case if there is no selected object. As after Draw(), the selected object is apparently “forgotten”, the event signal “ProcessedEvent()” is not emitted for key presses until the canvas found a selected object again, e.g. when the mouse is moved.
Q: I “fixed” this by calling Pick() (line 98 ), but I wonder if it is okay if the third argument is always 0. This way some object might miss a method call.
Q: I do not understand why the switch statement in TCanvas::HandleInput uses “return” instead of “break”.
Q: Why is the selected object forgotten at all? It could be found again automatically by making a Pick() after every Draw() in TCanvas.
2: When I click into the TNumberEntry at the lower left, it receives focus. Then, keyboard events are not delivered from the TCanvas::ProcessedEvent signal until I resize the window.
Q: Is there any other way than window resizing to get the keyboard events again?
BTW: I use version 5.26.00 and I like very much that Ctrl-L does some cleanup now. But I am a little bit disappointed that when searching the history via Ctrl-R and stopping with the cursor keys, there is some garbage (e.g., ‘[D’ in the case of cursor-left) appended to the commandline AGAIN! Several years ago (in root 3.24 or so) I had sent a patch to fix that, and now the problem is back. I suspect that it lies somewhere near line 363 in core/editline/search.cxx in the handling of the escape key, which is also a prefix for several special keys in a terminal (xterm, …). It is just a suspicion, though.
The best bugs always come back We’re now using a different library (editline) for the terminal input, and that decided to use ESC as a way to cancel the search. I agree that this is not optimal; pressing arrow keys is far more common. Ideally one could test whether the ESC key is part of a sequence or entered all by itself - I’d welcome a patch. But for now I fixed it to do what you asked for.
[quote]
1: after calling Draw() for some histogram in an event handler, the mouse has to be moved before keyboard events are processed again. This is because in TCanvas::HandleInput(), the long switch statement has a “return” for the kKeyPress case if there is no selected object. [/quote]
When I execute your macro I see that the mouse focus is given to the Graphics Pad then you have to click on the command line window to get the focus again on the input line. This is the normal behavior on Linux (and Mac). I saw that on windows the logic is a bit different. This also strongly depend on the way your window manager has been set up. I also tried to comment out the “return” line you mentioned but this does not changed the behavior.
So I am not entirely sure what you do not like and what behavior you would like. Can you be more specific ? what interaction should I do ?
[quote=“couet”][quote]
1: after calling Draw() for some histogram in an event handler, the mouse has to be moved before keyboard events are processed again. This is because in TCanvas::HandleInput(), the long switch statement has a “return” for the kKeyPress case if there is no selected object. [/quote]
… mouse focus is given to the Graphics Pad … command line … what interaction should I do ?[/quote]
Sorry. I did not think of the window focus, but of where ROOT sends the key events. Also I did not think about the ROOT command line, the macro expects key presses in the canvas window: it should change which y bins are projected when the cursor/arrow up or down keys are pressed. This is handled in MatNav::CanvasEvent, lines 83–99.
To reproduce:
start the macro with some matrix, e.g. matnav(m_test)
window manager focus on the macro’s window
go up and down with cursor keys
click in the numberentry at the lower left
now the cursor is blinking there, up/down changes only the numberentry
the only way (I found) to get the old up/down again, i.e. events being reported to MatNav::CanvasEvent, is to resize the window
Can you reproduce this? Can you suggest a nice way out?
[quote=“couet”][quote]
6. the only way (I found) to get the old up/down again, i.e. events being reported to MatNav::CanvasEvent, is to resize the window
[/quote]
Just click on the plot and you are back into the arrow mode.[/quote]
Hmm, clicking alone really does not work here for me. If I first click in the numberentry and then in the plot without ever moving the mouse outside the window, the cursor keep blinking at the numberentry and the up/down keys do not cause a call to MatNav::CanvasEvent.
But if I do move the mouse outside the macro’s window and in again, the up/down keys work again. Probably it was also the effect of moving the mouse outside the window that I saw when I was resizing. Although I find this is strange behaviour, moving around the mouse is much better than resizing the window, so things are usable now.
Thanks for your help!
Alexander
[quote]
If I first click in the numberentry and then in the plot without ever moving the mouse outside the window, the cursor keep blinking[/quote]
If I do that is it ok for me. The cursor stop blinking.
Several years ago (in root 3.24 or so) I had sent a patch to fix that, and now the problem is back. I suspect that it lies somewhere near line 363 in core/editline/search.cxx in the handling of the escape key, which is also a prefix for several special keys in a terminal (xterm, …). It is just a suspicion, though.
We’re now using a different library (editline) for the terminal input, and that decided to use ESC as a way to cancel the search. I agree that this is not optimal; pressing arrow keys is far more common. Ideally one could test whether the ESC key is part of a sequence or entered all by itself - I’d welcome a patch. But for now I fixed it to do what you asked for.