Shift the keyboard to the left by 1

[Arthur3032]

Describe the bug

1.download source code of Dosbox-x (Latest Release: 0.84.3 (2022.09.0)) 64bit
2.use Microsoft Visual stodio 2022 buile it.
3.The DosBox-X:
3-1.Shift the keyboard to the left by 1 (press z->x, x->c, c->v ..., 1->2, 4->5, 7->8...)
3-2. Mouse wheel not responding (Left and right mouse buttons are normal)

Steps to reproduce the behaviour

same as Describe the bug.

Expected behavior

No response

What operating system(s) this bug have occurred on?

Windows 10 22H2

What version(s) of DOSBox-X have this bug?

Latest Release: 0.84.3 (2022.09.0) SD1

Used configuration

default config

Output log

No response

Additional information

No response

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[Arthur3032]

dosbox-x.rar.zip
This is *.rar

[NebularNerd]

Just tested, top three rows of a UK keyboard worked fine, last row is weird \ works ok which is to the left of Z but rest of the row is off by one as described.

Layout for UK keyboard, when testing \ works, everything else is shifted by one letter, / does not work. Both shift keys work if that's important.

Testing against commit build created for #3810 a few days ago and that works fine.

[NebularNerd]

@Arthur3032 have you tried building recently to see if the issue still persists? I threw together a build yesterday from the latest code and found the keyboard behaves as expected.

[Arthur3032]

The problem of shifting one key on the keyboard is still there. It may be that the visual studio is not set correctly, so I will test it again. Please give me the DosBox-x source code in your hand.

[NebularNerd]

I grabbed the latest code in a .zip from the frontpage a couple of days ago, then opened the project in VS and ran a new build. It should not make any difference but I'm not cloning the repo directly as VS is being weird for me and refusing to grab GitHub repo's.

I've not got a clean copy of the source as I deleted the .zip shortly after, and have been playing about with the source to help confirm and test other issues.

[Arthur3032]

I download dosbox-x-master.zip to use (2022.09.1).
The keyboard key position is also shifted to the left (z...m)

[NebularNerd]

I download dosbox-x-master.zip to use (2022.09.1). The keyboard key position is also shifted to the left (z...m)

That's weird, I only encountered the issue with the copy you uploaded. Please can you post the link you used?

[Torinde]

Arthur posted a link at #3822 (comment)

[NebularNerd]

Arthur posted a link at #3822 (comment)

@Arthur3032 I compiled from the master.zip you posted using VS SDL2 x64 and keyboard behaves as expected. This was a fully clean build and in its own directory away from my existing builds just to make sure.

Unless others can offer more insight I would say there is an issue in your compilation environment as the compiled version you posted previously did exhibit the issues you described. Have you tried downloading a precompiled copy from the recent commit builds?

As described in #3822, head to Actions at the top of the page, pick the build environment on the left that suits you (e.g.: 64-bit Visual Studio builds), pick the most recent workflow from the top and grab the build test separately from your normal DosBox setup. If you still have issues it could be similar to #3787 but again that seemed to be limited to one machine as well.

[ancning]

I had the same problem using DOSBox-X 2022.08.0 (0.84.2) Release and Visual Studio 2019.
My problem was solved by adding /utf-8 msvc option to dosbox-x project in Visual Studio.
Reference

[NebularNerd]

Hi @ancning,

Reading through the link it says the files are checked to see it they are UTF8-BOM (Byte Order Marked) if not it defaults to your set code page. I wonder if you and @Arthur3032 are on a non standard codepage. Could you both run the following in powershell:
Get-WinSystemLocale | Select-Object Name, DisplayName, @{ n='OEMCP'; e={ $_.TextInfo.OemCodePage } }, @{ n='ACP'; e={ $_.TextInfo.AnsiCodePage } } (borrowed from https://serverfault.com/a/836221)

You should get a result as below (with whatever your region is):

Name  DisplayName              OEMCP  ACP
----  -----------              -----  ---
en-GB English (United Kingdom)   850 1252

As your compiles otherwise work it would seem that the best option maybe to add an .editorconfig file to the source directory (I guess the vs directory is best), similar to the answer here https://stackoverflow.com/a/65945041

[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 4

Could one or both of you try this method (and not use the /utf-8 flag) if it works I can create a pull request on your behalf and see if it will get accepted.

[Arthur3032]

[NebularNerd]

Hi @Arthur3032 that could be the issue for your builds, maybe something gets messed up if VS tries to use your local codepage in place of UTF8. Can you try a build adding the .editorconfig file detailed above?

From your codepage I see you're in Taiwan, I've been to Taipei and Jiufen in the past, loved it out there 🙂

[Arthur3032]

I changed .editorconfig to this, the situation is the same
(Welcome to visit Taiwan again)

top-most EditorConfig file

root = true

#[*.{c,cpp,h}]
#end_of_line = lf
#indent_style = space
#indent_size = 4
#charset = utf-8
#trim_trailing_whitespace = true
#insert_final_newline = true
#max_line_length = 120

[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 4

[NebularNerd]

@Arthur3032 thanks for trying, did you try this against your existing builds or make a clean copy to test? Not sure what else to suggest, everything seems to suggest it's a codepage/charset issue during your build process.

I wonder if I can make a compile with and .editorconfig charset set to your codepage and replicate the issue that way? Or if I can find which files are not in UTF8 and change them to UTF8? (I have a python script I can modify to search through them all fairly quickly)

[NebularNerd]

A new commit build for #4192 might fix this issue as well.