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)

Changed 10 years ago by joshe

Attachment: cspace.patch added

Fix Control-Space messages for KeyUp and KeyDown.

comment:1 Changed 10 years ago by stippi

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 Changed 10 years ago by joshe

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 Changed 10 years ago by stippi

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 Changed 10 years ago by axeld

Component: - GeneralServers/input_server

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

comment:5 Changed 10 years ago by stippi

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

Changed 10 years ago by stippi

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

comment:6 Changed 10 years ago by stippi

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 Changed 10 years ago by joshe

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 Changed 10 years ago by korli

Was this committed at all ?

comment:9 Changed 10 years ago by joshe

Yes, in hrev33338.

comment:10 Changed 10 years ago by korli

Resolution: fixed
Status: assignedclosed

Thanks

Note: See TracTickets for help on using tickets.