flex-dev mailing list archives

Hi Justin et all,
I made a response in blog post but is still pending for approval.
I think I saw the problem tracked by @witchlake: I insert and remove
restricted chars rightly as you, but the problem comes when you have
different restrict patterns and you remove chars *between* chars. So as you
remove a char in the middle of the string you'll end dragging chars to
unallowed positions. For example if you remove a char from a *only numeric
position* and the sibling is alphanumeric. The alphanumeric ends in the
only numeric slot.
I think this is the problem, and I propose the following: If the user
remove a middle position insert a blank char (and show the prompt char for
that slot), so we''ll end not *dragging" chars as we do now. In bindings or
*get text* uses, the component strips the blank char.
For example, for a plate with mask ####-@@@ and prompt ____-__ a valid
input will be 3577-DVG. The user can remove '5' and the component will
show: 3_77-DVG (the '_' char will be greyed since is show in the prompt),
but when retrieving the text we will get 377DVG. If the user has
validation, the plate will be invalid.
This will avoid the removal problem in the middle of the string, and remove
the need of the proposed "inputMode" flag, and we'll end with all chars
maintaining the slot position where they are positioned. I think this will
make the component more robust and complete (if there's some missing
feature, we could discuss it and implement it).
What do you think about it. I'll make the changes as folks give some
feedback about this proposal.
Best,
Carlos
2014-03-12 12:08 GMT+01:00 Carlos Rovira <carlos.rovira@codeoscopic.com>:
> In Made In Flex article I had another guy that reports problems. The
> comment is here:
>
>
> http://www.madeinflex.com/maskedtextinput-nuevo-componente-de-mascara-en-apache-flex-4-12/
>
> But he does not provide any feedback so I couldn't know nothing about that
> one in particular.
>
> I'm thinking that maybe folks expect a different behavior in the component
> and for this reason report it broken. Instead of add/remove text and "drag"
> the rest, maybe people expect characters hold in it's position and deleting
> chars make blank positions.
>
> This was a behavior I proposed in the old thread where we discussed the
> component to implement using a Boolean property (e.j: inputMode) , so
> people could choose between actual input method and the other one.
>
> Maybe this could be the problem? As I get some time I'll take a look at
> the sample provided, I'm off my dev environment.
>
> Thanks for check it Justin :)
>
> Carlos
>
>
>
>
>
>
>
>
>
>
> 2014-03-12 11:50 GMT+01:00 Justin Mclean <justin@classsoftware.com>:
>
> Hi,
>>
>> > I'll take a look a this case and report here what I see.
>>
>> I had a quick look at it and it actually seemed OK to me - not sure what
>> the actual issue is.
>>
>> My guess is the namespace was not specified correctly - but that's just a
>> guess.
>>
>> Thanks,
>> Justin
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F: +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es