You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While using GetRawInputData, I've stumbled upon an issue where the value of UsButtonFlags is apparently placed inside UsButtonData.
After looking at the code, I noticed the Pad_cgo_0 field and got to read a bit about the beautiful world of field alignment in C. I still don't know much about it but here's what worked in my case:
By just moving that padding above UsButtonFlags it seems to work just fine, even for the info in LLastX and LLastY.
I was wondering about creating a PR but then noticed this might work differently depending on the target architecture. Can you please give me your thoughts on this? Is it safe to move that padding field, or will I have to look out for its position depending on my compiler target?
set GOARCH=386 && go build -o ./build/Debug/test_offset_386.exe ./cmd/testoffset
set GOARCH=amd64 && go build -o ./build/Debug/test_offset_amd64.exe ./cmd/testoffset
You might need to check the RAWMOUSE struct and the Windows data type docs to make some sense of the above output.
The output is pretty much the same and the padding is set above the usButtonFlags+usButtonData inner struct. Maybe I need an actual 32bit machine for it to be different (not sure).
I wonder if the current Golang structure in this repo is prepared for 32bit builds since the commit was made in July 2012, or if this has been a bug all along 🤔
The text was updated successfully, but these errors were encountered:
While using
GetRawInputData
, I've stumbled upon an issue where the value ofUsButtonFlags
is apparently placed insideUsButtonData
.After looking at the code, I noticed the
Pad_cgo_0
field and got to read a bit about the beautiful world of field alignment in C. I still don't know much about it but here's what worked in my case:By just moving that padding above
UsButtonFlags
it seems to work just fine, even for the info inLLastX
andLLastY
.I was wondering about creating a PR but then noticed this might work differently depending on the target architecture. Can you please give me your thoughts on this? Is it safe to move that padding field, or will I have to look out for its position depending on my compiler target?
EDIT:
I did some more investigation on this and here's an interesting read on the subject: http://www.catb.org/esr/structure-packing/
I've also checked the paddings using this code:
Built for both 32bit and 64bit Windows:
Here's the output for 32bit:
Here's the output for 64bit:
You might need to check the RAWMOUSE struct and the Windows data type docs to make some sense of the above output.
The output is pretty much the same and the padding is set above the
usButtonFlags
+usButtonData
inner struct. Maybe I need an actual 32bit machine for it to be different (not sure).I wonder if the current Golang structure in this repo is prepared for 32bit builds since the commit was made in July 2012, or if this has been a bug all along 🤔
The text was updated successfully, but these errors were encountered: