RE: [XaraXtreme-dev] Text tool shortcuts

["Phil Martin" <Phil@xxxxxxxx>]

Er, so to clarify, I think the text tool should be using Char events to
add characters into text objects and Keypress events to initiate
actions.

I'm sure you know this already but remember that Char events can be
generated from sources other than the keyboard, e.g. OCR,
speech-to-text, chorded keyboards, handwritingr recognition, etc.,
etc...

Phil 

> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Phil Martin
> Sent: 21 July 2006 11:16
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Text tool shortcuts
> 
> We've done some tweaking in this area (Luke knows the 
> details) and might have changed the behaviour from Xtreme.
> 
> I think that both Keypress and Char events are needed and I 
> suggest that the text tool should claim keypress events even 
> when it does nothing with them (although it may choose to 
> pass some crucial ones on).
> 
> Phil 
> 
> > -----Original Message-----
> > From: owner-dev@xxxxxxxxxxxxxxxx
> > [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Martin Wuerthner
> > Sent: 21 July 2006 11:04
> > To: dev@xxxxxxxxxxxxxx
> > Subject: [XaraXtreme-dev] Text tool shortcuts
> > 
> > I have had a look at text tool shortcuts, which currently 
> do not work 
> > and I have found the following:
> > 
> >  (1) A keypress like "arrow left" moves the caret AND is handled 
> >      by the hotkeys system, too, so it causes a nudge operation 
> >      as well. So, if you move the caret left in text and go to 
> >      the Edit menu, it says "Undo nudge".
> > 
> >  (2) Ctrl+letter shortcuts (e.g., Ctrl-W) are not working at all.
> > 
> >  (3) Even if Ctrl-W (swap case) was correctly recognized it would 
> >      not work because an underlying function to swap case is not 
> >      yet implemented.
> > 
> > (2) is caused by wxWidgets setting the virtual key of Ctrl-letter 
> > combinations to the control code (i.e., 1 for
> > Ctrl-A) instead of the uppercase letter, which is what the code 
> > expects. I have fixed that in the Keypress constructor.
> > I also have a fix for (3).
> > 
> > I found the problem that causes (1) but I am wondering how to best 
> > deal with it. The problem is that the application gets THREE key 
> > messages for a keypress like "arrow left":
> > 
> >       IsChar() IsRelease()
> > 1st    FALSE     FALSE
> > 2nd    TRUE      FALSE
> > 3rd    FALSE     TRUE
> > 
> > The text tool responds to presses with IsChar=TRUE and 
> IsRelease=FALSE 
> > while the hotkey system responds to presses with IsChar=FALSE and 
> > IsRelease=FALSE. So, the text tool ignores the 1st message, 
> which the 
> > hotkey system happily processes. Then, the text tool processes the 
> > second message.
> > Surely, something is wrong there. What is the point in having two 
> > "press" messages for each keypress? Is this deliberate?
> > 
> > Martin
> > 
>