Opened 10 years ago

Closed 10 years ago

#4648 closed bug (fixed)

Fix BMessage key events where the bytes array contains an ASCII NUL

Reported by: joshe Owned by: stippi
Priority: normal Milestone: R1
Component: Servers/input_server Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

For the Control-Space key sequence, the bytes array in the BMessage contains an ASCII NUL. Attached is a patch to the input_server keyboard driver, the BMessage FindString method, and the BWindow DispatchMessage method which insures that the KeyDown and KeyUp methods for Control-Space will be invoked with the correct length.

The inline loops here are a little cumbersome, perhaps BString should have a method for setting the contents of the string to binary data which may contain NULs?

Attachments (2)

cspace.patch (2.6 KB ) - added by joshe 10 years ago.
Fix Control-Space messages for KeyUp and KeyDown.
alternative_cspace_patch.diff (2.7 KB ) - added by stippi 10 years ago.
Achieving the same, but without making FindString() slower.

Download all attachments as: .zip

Change History (12)

by joshe, 10 years ago

Attachment: cspace.patch added

Fix Control-Space messages for KeyUp and KeyDown.

comment:1 by stippi, 10 years ago

Interesting. Have you been able to test if this is indeed how BeOS behaves? Maybe the problem is at the input_server device level and the string array is not supposed to contain NUL in the middle of the sequence in the first place?

comment:2 by joshe, 10 years ago

No, it didn't occur to me to test under BeOS. If you'd like then I can try to dig up my old R5 CD and install it in a VM.

However the BeBook seems to suggest that including a NUL is the right thing to do in this case. On the BView page it says "The bytes array is not null-terminated; '0' is a valid character value".

For what it's worth, this patch makes the Control-Space sequence work in the Terminal with no other changes, which also suggests to me that this is how it originally worked in BeOS.

comment:3 by stippi, 10 years ago

Owner: changed from nobody to stippi
Status: newassigned

Ok, thanks for the BeBook reference, I think there is no need to go through the hassle of confirming this with BeOS R5.

comment:4 by axeld, 10 years ago

Component: - GeneralServers/input_server

I think the cleanest solution would be not to use BString here, after all.

comment:5 by stippi, 10 years ago

Same thought here. I was going to change the patch to use AddData/FindData.

by stippi, 10 years ago

Achieving the same, but without making FindString() slower.

comment:6 by stippi, 10 years ago

Hi Joshua, can you please test if my version of the patch works as well as yours? I believe BMessage::FindString() should not be changed, since strings are not valid with NULs in them, so FindString() should not suffer for this one special case, IMHO.

comment:7 by joshe, 10 years ago

Yes thank you, this works fine for me. It is cleaner to just use AddBytes, shame on me for not thinking of that in the first place I guess.

comment:8 by korli, 10 years ago

Was this committed at all ?

comment:9 by joshe, 10 years ago

Yes, in hrev33338.

comment:10 by korli, 10 years ago

Resolution: fixed
Status: assignedclosed

Thanks

Note: See TracTickets for help on using tickets.