Mantis

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0021331Runner[All Projects] HTML5Public2016-04-28 12:282017-06-13 11:45
ReporterPiotr Gnys 
Assigned ToMike Dailly 
PriorityHighSeverityB - MajorReproducibility100%
StatusResolvedResolutionFixed 
PlatformWindowsOSWin7OS 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 Version1.4.1757
2.x Runtime Version
2.x Runtime Version Verified In
Attached Files

- Relationships

-  Notes
(0043134)
GameGeisha (Updater)
2016-04-28 15:01

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.
(0043143)
Piotr Gnys (Updater)
2016-04-28 15:51
edited on: 2016-04-28 15:51

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

(0043179)
GameGeisha (Updater)
2016-04-29 07:19

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.
(0043190)
rcusumano (Updater)
2016-04-29 19:04

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.
(0044209)
Piotr Gnys (Updater)
2016-06-23 10:17

I think that good idea will be that we can define keyboard we want on our own, or redefine it at runtime.
(0048332)
Piotr Gnys (Updater)
2016-09-05 12:04

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 [^]
(0053580)
Mike Dailly (Manager)
2017-06-13 11:45

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.


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker