Getting access to arrows signals

Hello,

I have re-written my own canvas class and I would like to get the information when the arrows: kkey_left, kkey_right… are pressed. And I want this working on linux ans mac_os.

The problem I have with the “standard” way to do in HandleInput(EEventType event, Int_t px, Int_t py)

is that on my mac, when I am pressing the arrows, the px and py values are not corresponding to the KeySymbols but to the x and y positions on my canvas. I still have the possibility to check wether the x is lower than the previous recorded one but its not optimal and does not work for kkey_Up and down.

A solution I have found is to use the EventProcessed(Event_t *ev, Window_t) method, with:

char input[10];
UInt_t keysym;
gVirtualX->LookupString(event, input, sizeof(input), keysym);
if(keysym == kkey_left) {...}

But I realized that on some computer, for a reason that I cannot understand, this LookupString method crash, so I cannot use it anymore as my software is used by a large community.

I have seen that the event->fcode is different if I press the different arrows, but for what I have understood, the fcode can be different on different architectures, so I cannot use it neither.

Do you see another way to grab the arrows infos ?

Thanks in advance

Jérémie

Hi Jérémie, I’ll check on Windows and I’ll let you know.
Cheers, Bertrand

Can you provide a working reproducer of the problem you have that doesn’t work for you?

Hi Bertrand,

thanks for your answer. The simpler thing is that with such a macro:

#include <iostream>
#include "TCanvas.h"

using namespace std;

void ProcessedEvent(Int_t event, Int_t x, Int_t y, TObject *selected);

void GrabArrow()
{
    TCanvas *c = new TCanvas();
    c->Connect("ProcessedEvent(Int_t,Int_t,Int_t,TObject*)",0,0,"ProcessedEvent(Int_t,Int_t,Int_t,TObject*)");
}


void ProcessedEvent(Int_t event, Int_t x, Int_t y, TObject *selected)
{
    cout << event << " " << x << " " << y << " " << selected << endl;
}

pressing the arrows will not give the kkey_Left, kkey_Right… info but only kArrowKeyPress.

How would you do to get these information ?

Jérémie

I think you already asked the same kind of question a while back: How to grab the ProcessedEvent(Event_t*) from a TCanvas and I think the answer is still valid. Or did I miss something?

The fact is that, for a reason that I cannot understand, the method: gVirtualX->LookupString(event, input, sizeof(input), keysym); crashes on some users architectures. So I wanted to find a way to not use this LookupString method.

The problem is that I cannot reproduce this crash myself but they obtain something like this:

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0 0x00007ff1150e307a in __GI___waitpid (pid=13078, stat_loc=stat_loc
entry=0x7ffc545e6580, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
#1 0x00007ff11505bfbb in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:148
#2 0x00007ff1163a5ed0 in TUnixSystem::StackTrace() () from /illdata/applications/fipps/root/root-6.20.00_install/lib/libCore.so
#3 0x00007ff1163a8934 in TUnixSystem::DispatchSignals(ESignals) () from /illdata/applications/fipps/root/root-6.20.00_install/lib/libCore.so
#4 <signal handler called>
#5 0x00007ff10ea94107 in XLookupString () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ff0fab4ffc5 in TGX11::LookupString(Event_t*, char*, int, unsigned int&) () from /illdata/applications/fipps/root/root-6.20.00_install/lib/libGX11.so
#7 0x00007ff116b25e64 in CXMainWindow::ProcessedKeyEvent (this=0x33581e0, event=0x7ffc545e9b80) at /illdata/applications/fipps/gammaSoftware/LYON/gw/src/root/gui/cubix/src/CXMainWindow.cpp:1253
#8 0x00007ff038cb4034 in ?? ()
#9 0x0000000000000000 in ?? ()
===========================================================

this works for me:

#include <iostream>
#include "TCanvas.h"

void EventProcessed(Event_t *event);

const char *keysym_to_string(Int_t keysym)
{
   static char other[10];
   switch ((EKeySym)keysym) {
      case kKey_Home:
         return "kKey_Home";
         break;
      case kKey_End:
         return "kKey_End";
         break;
      case kKey_Left:
         return "kKey_Left";
         break;
      case kKey_Up:
         return "kKey_Up";
         break;
      case kKey_Right:
         return "kKey_Right";
         break;
      case kKey_Down:
         return "kKey_Down";
         break;
      case kKey_PageUp:
         return "kKey_PageUp";
         break;
      case kKey_PageDown:
         return "kKey_PageDown";
         break;
      default:
         sprintf(other, "%d", keysym);
         return other;
         break;
   }
}

void GrabArrow()
{
   TCanvas *c = new TCanvas();
   gClient->Connect("ProcessedEvent(Event_t *, Window_t)", nullptr, nullptr, "EventProcessed(Event_t*)");
}

void EventProcessed(Event_t *event)
{
   char input[10];
   UInt_t keysym;
   if (event->fType == kGKeyPress) {
      gVirtualX->LookupString(event, input, sizeof(input), keysym);
      std::cout << "Processed Key Event : " << keysym_to_string(keysym) << std::endl;
   }
}

Here is the output

root [0]
Processing GrabArrow.C...
root [1] Processed Key Event : kKey_Up
Processed Key Event : kKey_Right
Processed Key Event : kKey_Down
Processed Key Event : kKey_Left
Processed Key Event : kKey_Up
Processed Key Event : kKey_Left
Processed Key Event : kKey_Right
Processed Key Event : kKey_Down
Processed Key Event : kKey_Left
Processed Key Event : kKey_Up
Processed Key Event : kKey_End
Processed Key Event : kKey_Home
Processed Key Event : 104

But I still agree it’s not a perfect solution. Maybe one could add another signal in TCanvas with the relevant information

Yes this works also for me… I am trying to find a user for whom this LookupString is crashing to try to understand why and find a patch that works for everyone… but it’s really not easy to test developments on a computer that you don"t have.

Bienvenue au club !

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.