View Issue Details

IDProjectCategoryView StatusLast Update
0021331Runner[All Projects] HTML5Public2018-02-05 16:28
ReporterPiotr GnysAssigned ToMike Dailly 
PriorityHighSeverityB - MajorReproducibility100%
Status ClosedResolutionFixed 
PlatformWindowsOSWin7OS Version
Product Version 
Target VersionFixed in Version 
Summary0021331: Some characters works wrong in HTML5
DescriptionWhen exporting game to HTML5, some characters from keyboard are wrongly recognized from keyboard:

Shift+~ = @, should be ~
Shift+2 = ", should be @
Shift+' = ~, shoold be " (double quote)
' = #, should be ' (apostrophe/single quote)
Shift+2 = £, should be # (newline in GM).



I've used font with 32-255 characters range available for tests.
Steps To ReproduceOnly code needed for test in HTML5 - draw event:


    draw_set_font(font0);
    var last = keyboard_lastchar;
    if last = '#' last = '\#';
    draw_text(10,10,'last key: <' + string(keyboard_lastchar)+'>');


(this makes # visible as character instead newline).
1.4 Found In1.4.1757
2.x Runtime Found In
2.x Runtime Verified In

Activities

GameGeisha

2016-04-28 15:01

Updater   ~0043134

That's because the current implementation of keyboard_lastchar and keyboard_string is always pegged to the UK layout. I've been a critic of this for a long time and the only way out is to overlay a text field or text area over the canvas through JS.

Piotr Gnys

2016-04-28 15:51

Updater   ~0043143

Last edited: 2016-04-28 15:51

View 2 revisions

It should use US keyboard, even if other countries (like Poland). That will be most accurate I think.

GameGeisha

2016-04-29 07:19

Updater   ~0043179

Absolutely not. Work with anything that isn't written using the basic English alphabet and the approach comes apart.
 
Text field/area overlays are the only real valid approach that adequately accounts for layout/orthographical differences, not keyboard_string or keyboard_lastchar and certainly not one of those silly on-screen keyboard lookalikes.

rcusumano

2016-04-29 19:04

Updater   ~0043190

I gave up trying to interprete keycodes and switched to text fields aswell.

Current runner implementation is a very poor design choice I'd say.

Piotr Gnys

2016-06-23 10:17

Updater   ~0044209

I think that good idea will be that we can define keyboard we want on our own, or redefine it at runtime.

Piotr Gnys

2016-09-05 12:04

Updater   ~0048332

Or another approach, that there's function:

html5_set_keyboard_layout(map)

where map can be one of constans:

html_layout_uk - https://upload.wikimedia.org/wikipedia/commons/d/da/KB_United_Kingdom.svg
html_layout_us - https://upload.wikimedia.org/wikipedia/commons/5/51/KB_United_States-NoAltGr.svg

Mike Dailly

2017-06-13 11:45

Manager   ~0053580

This should now be addressed as all browsers (we think) now pass through the ASCII of the character pressed. Chinese and Korean chaarcters probably won't work as browsers don't pass them through, but european and cyrillic alphabets should work.

Where the character isn't available, it'll fall back to the UK keyboard again.