The problem in an ink input box is when three numbers are written quickly,
168, the 6 will not show on the screen and the conversion is 18. If 16 is
written no conversion happens, if 168 is written slowly 168 is converted.
Writing 4 as two separate stokes forces writing the second stroke twice and
if the l is written first if you are not quick the recognition is as 1 not 4.
In other ink input boxes where we have used a delay value before conversion
of 1 second, not the system default, the numbers are handled easily. This
bad behavior does not exhibit in the Windows TIP.
My guess here is that some of the driver code may checking the delay in the
wrong sequence relative to processing. The only way to test this would be to
write a small app using the Tablet SDK.