Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

franciscojma86
Copy link
Contributor

Synchronizes the win32 key press messages to send a Flutter message with all the key information (key code, scan code, code point, modifiers).

This change depends on flutter/flutter#54227

Part of flutter/flutter#37710


// Variable used to store the key code preceding a WM_CHAR message. For more
// info, read the comments below in WM_KEYDOWN/UP.
static unsigned int keycode_for_char_message = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This static makes me a little nervous, but I know it's common practice in Windows, and the changes should only happen on the UI thread, so there's no locking needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it static rather than an ivar?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah an ivar makes more sense. Done

// is persisted in a static variable keycode_for_char_message obtained
// from WM_KEYDOWN.
const unsigned int scancode = (lparam >> 16) & 0xff;
window->OnKey(keycode_for_char_message, scancode, WM_KEYDOWN, code_point);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should keycode_for_char_message be reset to zero here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would always be updated at this point, since WM_KEYDOWN is called before WM_CHAR, but it doesn't hurt to be extra cautious. Added it.


// Variable used to store the key code preceding a WM_CHAR message. For more
// info, read the comments below in WM_KEYDOWN/UP.
static unsigned int keycode_for_char_message = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it static rather than an ivar?

// is persisted in a static variable keycode_for_char_message obtained
// from WM_KEYDOWN.
const unsigned int scancode = (lparam >> 16) & 0xff;
window->OnKey(keycode_for_char_message, scancode, WM_KEYDOWN, code_point);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused about the complex character flow. First we send the initial code point, then later we send the combined code point? And sending the first part twice, effectively, doesn't break anything?

If that's correct behavior, can you maybe add a comment pointing to the relevant framework code explaining/showing why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just added a check to avoid sending the dead key code point, and some comments explaining the flow. Is this better?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dead key check seems different. Or is a dead key always a leading surrogate?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Capturing from offline discussion: dead keys and surrogate pairs are orthogonal. The decision was that we should add a check to only send OnKey once even if we get multiple WM_CHAR messages, which should address my concern here.

// is persisted in a static variable keycode_for_char_message obtained
// from WM_KEYDOWN.
const unsigned int scancode = (lparam >> 16) & 0xff;
window->OnKey(keycode_for_char_message, scancode, WM_KEYDOWN, code_point);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dead key check seems different. Or is a dead key always a leading surrogate?

Copy link
Contributor

@stuartmorgan-g stuartmorgan-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@franciscojma86 franciscojma86 added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Apr 10, 2020
@fluttergithubbot fluttergithubbot merged commit 262723a into flutter:master Apr 10, 2020
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Apr 10, 2020
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Apr 10, 2020
goderbauer pushed a commit to goderbauer/engine that referenced this pull request Apr 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants