well code is quite complicated but I try to describe it better, if
that doesn’t help I could provide some easier pseudo-code.
Basically I need character composition only for korean, japanese and
chinese languages. Each glyph is composed from 2,3 or 4 characters.
All these characters are send through TextEditingEvent as
intermmediate character that is not finished yet, I need to display it
so user knows if the desired glyph is ok or not, that’s what other
programs do as well. When I get TextInputEvent I know I’ve got final
glyph and I move to another one…
The issue is that my application could have multiple windows and each
could have an editing control where input goes. Usually I don’t know
which window is currently active, so I process my events based on
windowID for each event. That’s why I’m missing a windowID for
TextEditingEvent as I don’t know where it should go…
I uploaded a screenshot from the GUI here:
You can see there could active focused edit control in any window and
when composing a glyph event should carry a windowID where this
occured, because user can simply switch between windows anytime
between TextInputEvents and it’s not very safe to hack this other way
without windowID in TextEditingEvent.
PavelOn 15.4.2010, at 5:38, Jjgod Jiang wrote:
On Thu, Apr 15, 2010 at 3:41 AM, Pavel Kanzelsberger <@Pavel_Kanzelsberger wrote:
I’m working on a multi-window GUI and now working on text input.
It works perfect but when I want to implement text editing events
and character composition, I would like to display it as well. The
problem is that corresponding event structure is missing windowID
and I don’t know to what window the final text input goes…
Here for this event, windowID is not specified…
typedef struct SDL_TextEditingEvent
Uint32 type; /
< ::SDL_TEXTEDITING */
char text[SDL_TEXTEDITINGEVENT_TEXT_SIZE]; /< The editing
int start; /< The start
cursor of selected editing text */
int length; /< The length of
selected editing text */
And then when character is finally composed, I know the windowID:
typedef struct SDL_TextInputEvent
Uint32 type; /< ::SDL_TEXTINPUT */
Uint32 windowID; /< The window with
keyboard focus, if any */
Uint8 which; /< The keyboard
device index */
char text[SDL_TEXTINPUTEVENT_TEXT_SIZE]; /< The input text */
Could that be fixed or is it a limitation of some operating system??
I could hack some code and remember what was the last active
window, but that’s not very safe probably.
Indeed, that can be fixed. Can you give me a sample code that how you
are going to use this API with multi-window? Even pseudo-code will
help me understand the situation better.
Currently the text input implementation is a bit broken for
multi-window since I only added a field edit to the front most window
on Cocoa_StartTextInput(). It can be solved once we switched to use
the field edit provided by NSWindow. I am working on it.
SDL mailing list
SDL at lists.libsdl.org
E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633