Event message_type

Post questions, comments and feedback to our 3Dconnexion UNIX and Linux Development Team.

Moderator: Moderators

Post Reply
Absum
Posts: 53
Joined: Tue Apr 24, 2007 4:00 am
Location: Sweden
Contact:

Event message_type

Post by Absum »

I've noticed that the numbers i get on initiating the sdk:

Code: Select all

Magellan: xdrvpp.cc 
MotionEvent = 725
ButtonPressEvent = 726
ButtonReleaseEvent = 727
CommandEvent = 728
Like so!

Isn't the correct ones, for example the motion event should be 109 and button press should be 106, this ofcourse makes me think that CommandEvent also is way of and that something will not work as it should :O

Why is this and what could i possibly do to solve it?


Now ill go ask the internet.
Absum
Posts: 53
Joined: Tue Apr 24, 2007 4:00 am
Location: Sweden
Contact:

Post by Absum »

I've figured it out... i thought it wasn't but there where a difference between GdkEventClient's and XEvent.xclient's message_type variable so i had to use gdk_atom_intern instead to get the gdkatom. The only problem is that now the message_type on button event is set to press:107 and release:108 and command event to 109 and when i press and release a button i get 109 in message_type
jwick
Moderator
Moderator
Posts: 3331
Joined: Wed Dec 20, 2006 2:25 pm
Location: USA
Contact:

Post by jwick »

I might be wrong about this, but if those are the atom numbers, I don't think those numbers are meant to be persisted across X sessions. I believe you need to look them up (XInternAtom or something like that) each time the X server is run. The X server decides what they are each time it runs. They won't necessarily be the same each time.
UtaSH
Moderator
Moderator
Posts: 3754
Joined: Mon Nov 27, 2006 10:34 am
Location: Munich, Germany
Contact:

Post by UtaSH »

In addition to the previous post see the man page of XInternAtom(), which is used by the SDK to create the Atoms (if they don't exist):
Atom XInternAtom(Display *display, char *atom_name, Bool only_if_exists);

display - Specifies the connection to the X server.
atom_name - Specifies the name associated with the atom you want returned.
only_if_exists - Specifies a Boolean value that indicates whether the atom must be created.

The XInternAtom function returns the atom identifier associated with the specified atom_name string. If only_if_exists is False, the atom is created if it does not exist. [....]
This means you should not use fix numbers, but each time you start your program check if the Atoms exist and then use these numbers.
Absum
Posts: 53
Joined: Tue Apr 24, 2007 4:00 am
Location: Sweden
Contact:

Post by Absum »

jwick wrote:I might be wrong about this, but if those are the atom numbers, I don't think those numbers are meant to be persisted across X sessions. I believe you need to look them up (XInternAtom or something like that) each time the X server is run. The X server decides what they are each time it runs. They won't necessarily be the same each time.
Yes ive actually understod that, i supplied the numbers just to show the confusion in what was sent, but i think i have a pretty clear picture of how it works now.
Post Reply