Andrey Isakov 2012-10-03 08:30:25 PDT
I've found out in the process of porting one OS project to Android/SDL2 that
there is no support for TextInput events/APIs on Android.
So I implemented some kind of initial support of that feature, and at the very
least it seems to work fine with latin chars input with soft and hardware
keyboards on my Moto Milestone2. I've also tried playing around with more
complex IMEs, like japanese, logging the process and it seemed to work too. I'm
not sure since the app itself I am working on does not have support for
non-latin input.
The main point of the patch is to place a fake input view in the region
specified by SDL_SetTextInputRect and create a custom InputConnection for it.
The reason to make it a separate view is to support Android's pan&scan on input
feature properly. For details please refer to
http://android-developers.blogspot.com/2009/04/updating-applications-for-on-screen.html
Even though the manual states that SetTextInputRect is used to determine the
IME variants position, I thought this would be a proper use for this too.
When programmatically resizing a window on Unity 3D, we'll get a move event with the old size before we get a size event with the new size, and we don't want to clobber our internal state with the old size.
From Rick Johnson:
Here's the call pattern:
Create the window hidden
The game tells it to adjust the window position
Make the window visible.
A problem arises from the SetWindowsPos() - the default behavior of that would cause a WM_ACTIVATE message to be passed, of which SDL interprets that as the window now becoming visible and sets the flags. The window is not visible though. Now, when you try to call ShowWindow() - SDL sees those flags as indicating that the window is visible and early returns.
My proposed fix was that if we are calling set windows position and we aren't visible, add on the flag SWP_NOACTIVATE, which tells windows to not send down the WM_ACTIVATE flag.
Philipp Wiesemann 2012-09-30 05:56:09 PDT
I attached a patch which tries to implement the dropfile support for Microsoft
Windows. If applied SDL_DROPFILE events should be sent for single or multiple
files which are dropped on window.
The handling on Windows side is always activated (cursor will change and so on)
because there is no connection between SDL_EventState() and the window setup. I
assumed this additional overhead would be small and can be ignored.
