Is this happening because you are using the CHANGE event - is that
firing when you change modify the character also?
Have you tried using the TextEvent.TEXT_INPUT event - this might work,
but I am not sure.
The only other suggestion may be out of place, but concerns "usability"
and might be redundant: Making a text field large enough for the input
data may be a way around this too - I know email addresses can be
ridiculously long, but I think I would be happier with one that is long
enough rather than having one the right width just to please a graphic
designer...
On 24/09/2010 15:36, Paul Andrews wrote:
On 22/09/2010 20:25, Paul Andrews wrote:
On 22/09/2010 19:18, Cédric Muller wrote:
And, by any chance, are any fonts not embedded ? (another halfy dumb
question)
No, they are embedded. It's not that the text is not accepted it's
just that typing more text doesn't cause the text to move left when
the field is filled. It's not a case of typing characters that
aren't embedded.
It really is odd.
OK, I spotted what is making a difference. The field in question is
being used to enter an email address. Some testers had reported that
they were unable to enter a '@' symbol because when the tried to they
got an '"' (double quote). After a lot of discussion with the project
manager where i explained this was certainly down to incorrectly
configured keyboard/language settings (most likely UK English/US
English), I needed a solution, so for that field I attached a CHANGE
listener and substituted any typed " character with @ . This works
nicely, but
has clearly introduced another problem on some machines.
Scratched head for the moment.
Paul
22/09/2010 19:28, Paul Andrews wrote :
On 22/09/2010 17:26, Cédric Muller wrote:
Out in the wild (read: dumb question):
Do you have some player version detection in your tests ? (it
could be that the third computer has not FP9 installed?)
Fair question. Machine in question is running FP10! (as are the
other two)
hth,
Cedric
I've been working on an AS3 project with some input text - using
CS5 targetting FP 9.
It works nicely but I have a few text input fields, but one of
them has a problem on some computers. I have tried it on three
computers and only one shows the problem and the other input
fields do not show the problem. Even cutting and pasting
"working" or new textInput fields don't cure it.
The problem is that when the user types too much text, the text
should shift left so that what the user has just typed is always
in view. In two out of three machines I have access to it does.
On another it does not and the user can't see what they are typing.
There's no obvious correlation between machines that have the
correct behaviour for the field and those that do not. One tester
had the bad behaviour on all browsers except IE8. Works fine on
every browser I have installed.
Any ideas?
Paul
_______________________________________________
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
