Re: using KEBOARD into a EditBox with InputMask

From: AndyV (a_at_a)
Date: 07/28/04 

Date: Wed, 28 Jul 2004 08:58:03 -0600

I tried, but it seems like there is some un-natural stuff going on when the
form/EditBox looses focus to go to the Debugger window.

Andy.

Robert wrote:

> Have you followed the event firing sequence through the debugger while you
> are stuffing the character?
>
> --
> Robert
>
> "AndyV" <a@a> wrote in message news:4107b7f7$1_4@newsfeed.slurp.net...
>
>>Robert,
>>I left it in. The main problem I'm having is finding at what point the
>
> contents
>
>>of the TextBox.Value and/or TextBox.ControlSource value is stable. In the
>>form's procedure that does the actual stuffing of a newly-entered
>
> character with
>
>>the KEYBOARD cCharToInput command, neither of the values reflect what is
>>displayed on the form until the form returns to it's 'waiting for input'
>
> state.
>
>> Once I find a place in the order-of-events, I can compare the actual
>
> value of
>
>>the ControlSource with the intended value, after the InputMask could
>
> possibly
>
>>reject a character, and set the SelStart value to the length of the actual
>>results' length.
>>
>>Thanks for your views.
>>Andy.
>>
>>
>>Robert wrote:
>>
>>
>>>Did you remove or leave in the "TextBox.SelStart = nLastCursorPosition"
>>>command?
>>>
>>>--
>>>Robert Hoogstraat
>>>Software Intellect
>>>"AndyV" <a@a> wrote in message news:4106d5eb$1_2@newsfeed.slurp.net...
>>>
>>>
>>>>The SelectOnEntry property was set to .F., but when I changed it to .T.
>
> it
>
>>>>didn't seem to have much effect, except that the entire size of the
>>>
>>>InputMask is
>>>
>>>
>>>>Marked initially, but not after the first key is 'poked'. I'm at the
>>>
>>>burnout
>>>
>>>
>>>>stage of this 'tiny' enhancement and I think I need to re-boot my
>
> attitude
>
>>>and
>>>
>>>
>>>>re-think the whole thing.
>>>>
>>>>Thanks for looking into this.
>>>>
>>>>Andy.
>>>>
>>>>Robert wrote:
>>>>
>>>>
>>>>
>>>>>What is the value of textbox.selectonentry property? For me, on a test
>>>>>form, setting selectonentry to .t. gives the result you describe;
>>>
>>>setting
>>>
>>>
>>>>>selectonentry to .f. gives the result you are after.
>>>>>--
>>>>>Robert Hoogstraat
>>>>>Software Intellect
>>>>>
>>>>>"AndyV" <a@a> wrote in message news:4106b7ae$1_4@newsfeed.slurp.net...
>>>>>
>>>>>
>>>>>
>>>>>>I'm trying to enhance my TouchScreen Entry form by allowing an
>
> InputMask
>
>>>>>on the
>>>>>
>>>>>
>>>>>
>>>>>>data entered. Basically, my customer would like to be able to do
>
> simple
>
>>>>>input
>>>>>
>>>>>
>>>>>
>>>>>>masking (like A9A-9A9 for Canada Postal Codes) in order to make it a
>>>>>
>>>>>little more
>>>>>
>>>>>
>>>>>
>>>>>>difficult for the entry operators to screw up. That is a trivial
>>>>>
>>>>>operation when
>>>>>
>>>>>
>>>>>
>>>>>>entering with a keyboard, but when entering data with my TouchScreen
>>>
>>>Entry
>>>
>>>
>>>>>form
>>>>>
>>>>>
>>>>>
>>>>>>is where I'm running into difficulties.
>>>>>>
>>>>>>Basically, I have a Form with a button for each letter (laid out like
>
> a
>
>>>>>QWERTY
>>>>>
>>>>>
>>>>>
>>>>>>keyboard) that enters the 'keys' touched into a TextBox. I thought
>
> that
>
>>>>>it
>>>>>
>>>>>
>>>>>
>>>>>>would be a simple matter of Setting Focus to the TextBox (with an
>>>>>
>>>>>InputMask),
>>>>>
>>>>>
>>>>>
>>>>>>then passing the keystroke with a "KEYBOARD cKeyPassedIn" command.
>>>>>>Unfortunately, the cursor is always on the first position, so it
>>>
>>>'inserts'
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>newly-entered character in the first position. I tried to manually
>>>>>
>>>>>attempt to
>>>>>
>>>>>
>>>>>
>>>>>>keep track of where the last character is and force the cursor to that
>>>>>
>>>>>position
>>>>>
>>>>>
>>>>>
>>>>>>with a "TextBox.SelStart = nLastCursorPosition" command. I managed to
>>>
>>>get
>>>
>>>
>>>>>most
>>>>>
>>>>>
>>>>>
>>>>>>of it working, but when attempting to backspace to correct an
>
> incorrect
>
>>>>>entry, I
>>>>>
>>>>>
>>>>>
>>>>>>ran into the problem of keeping an accurate nLastCursorPosition,
>
> because
>
>>>a
>>>
>>>
>>>>>>cKeyPassedIn could be quietly rejected because it isn't a valid
>>>
>>>InputMask
>>>
>>>
>>>>>>data-type. I tried to sense this by capturing the
>>>>>
>>>>>BeforeValue+cKeyPassedIn to
>>>>>
>>>>>
>>>>>
>>>>>>the TextBox.ControlSource variable. During the general Method that
>
> does
>
>>>>>this
>>>>>
>>>>>
>>>>>
>>>>>>'simple' KEYBOARD operation, I haven't been able to get an accurate
>>>>>>TextBox.Value or value of the TextBox.ControlSource. They both seem
>
> to
>
>>>be
>>>
>>>
>>>>>>either empty, or what was there BEFORE the current operation.
>>>>>>
>>>>>>Is there a better way to do this? More specifically, is there a way
>>>
>>>that
>>>
>>>
>>>>>will work?
>>>>>
>>>>>
>>>>>
>>>>>>Thanks for reading this far,
>>>>>>Andy.
>>>>>
>>>>>
>>>>>
>>>
>
>