Hi Yoshiki,

It sounds like this problem is more complicated then I expected!  

With a Genie enabled image on my desktop, this is what happens:
(1) Click to position cursor (insertion point)
(2) Draw letter
(3) Blue hand-drawn letter dissapears, typed letter appears at insertion
point

When I transfer my image to my iPaq, this happens:
(1) Tap to position cursor 
(2) Draw letter
(3) Blue hand-drawn letter dissapears, as do half of the letters on the
screen, typed letter appears at insertion point

I think what is happening is that instead of inserting a character, I am
highlighting characters from the insertion point to the start of my
handwriting, then replacing those characters with the (newly recognised)
character.  You can see this behaviour if you try to edit a block of
text; it is not noticable if you try to add characters to the end of a
piece of text.

Maybe this too is a timing problem?

Cheers,

Russell

Yoshiki.Ohshima at acm.org wrote:
>   Russel and other iPAQers,
> 
> > Also, maybe you can help.  On my iPaq, when I tap the screen it seems to
> > register as two taps; for example a scrollbar will scroll two steps for
> > one tap.  I didn't notice this until playing with the Genie character
> > recogniser, where it causes problems.    
> > 
> > Since the same image works without this behaviour on my desktop, it may
> > be a VM issue.  Do you have any thoughts?  Is this only on my iPaq or
> > have you seen this before?
> 
>   Now, I'm getting confused.  I see the scrolling problem, but it
> doesn't cause any noticable problem Genie for me.  Can you elaborate
> the problem related to Genie?
> 
>   ...  I'm now thinking that it is an expected behavior.  As I gather
> it, what's happening should be something like this:
> 
>   The scrolling button and "scroll paging" use #step mechanism.
> Because it is relatively slow on iPAQ, processing the first mouseDown
> event simply exceeds the next step time and the #step repeats the
> scrolling action once again.
> 
>   I inserted the following line
> 
> 	evt printString, '  ' displayAt: 0 at 0.
> 
> in #scrollPageInit: and tested.  It looks like it gets single
> mouseDown event.
> 
>   You don't see it on desktop because it is fast.  But on the desktop,
> you see another different "counter-intuitive" behavior of scroll bars.
> If you click on a scroll button really fast (less than 200ms, I
> think), you'll see the button flashes but the text doesn't move at
> all.
> 
>   On WinCE, contrast the the manual, WM_MOUSEMOVE event is (always)
> sent to the VM right after the WM_LBUTTONDOWN is sent, no matter the
> stylus is moved or not.  HandMorph>>#generateMouseEvent: indicates
> that the Mac has the same behavior.  In the other words, it should be
> handled already.
> 
>   Thank you again,
> 
> -- Yoshiki