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.rov...@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 <jus...@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
