Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Set max chars for Unicode Edit Text control?

On 7/27/04 10:06 AM, Scott Thompson didst favor us with:

>> The reason I mentioned that is that I know there are multiple ways for users
>> to enter text, more than just typing and pasting. I don't know all the
>> details about how all of the work, so I'm reluctant to assume how all of the
>> interact with a key filter. If someone at Apple wants to clarify that and
>> alleviate my concerns, that would be cool.

> Apart from the fact that the Key Filter proc doesn't tell you how your
> keystrokes fit into the current unicode sequence, another problem with
> key filters is that user can also enter text through the inline input
> window and that window doesn't have any knowledge of what the current
> text entry field's environment is. In that case the Key Filter will
> not see individual keystrokes that are destined for the inline input
> window and the key filter will not be able to prevent the user from
> entering whatever text they may care to enter. In this case, a user
> using the inline input window can type a long sentence that consists of
> many more characters than 5 and the key filter will be none the wiser
> until the user accepts the inline input.

I thought this might be the case, but wasn't sure.
>
> That is why you have to pair the key filter with the validation proc.
> The Validation proc will be called before the field accepts the text

My understanding of validation procs is that they're called after
an operation like Paste has taken place, but it sounds like you're saying
they're called before.

> and the validation proc can, as it's name implies, make sure that the
> contents of the field are valid before the key focus leaves the
> control.

But this doesn't help if you want to limit the text before it's entered.
>
>> This depends on the nature of the data being pasted and the situation. If I
>> attempt a Paste into a text field, most applications will disable the Paste
>> command if the data on the Clipboard isn't text, for example. They don't
>> enable the Paste command and then respond to an attempt to paste by posting
>> an alert that there's no text to paste. I know this isn't exactly the same
>> situation, but it's not altogether different either.
>
> Pasting something that isn't text into a text field is a nonsensical
> operation and the paste item should be disabled. Pasting text into a
> text field, makes sense regardless of the restrictions placed on the
> text field's contents.

That depends. Should a field intended for numbers accept non-numeric text?
Should a text field for a creator code allow you to paste "Mary had a little
lamb" into it? You say yes, I say no, and I believe the UI Guidelines are
silent on the subject. ;-)

>> This is a judgement call, but as a user, I see no significant advantage to
>> implementing "partial-pasting" code, and it certainly isn't standard. For
>> example, I have some text fields in my application into which you can enter
>> type and creator codes. If you copied four characters to the Clipboard and
>> tried to paste them after three existing characters in one of those fields,
>> it wouldn't make any sense to offer to do a partial paste. It might make
>> sense for this field in your application, but it's not an approach I'd
>> recommend I general. Just my $0.02.
>
> The advantage is that the user gets a consistent behavior for all Text
> entry fields, not just those that happen to take more than a certain
> number of characters.
>
> I fail to see how allowing the paste and then warning the user that the
> field has too many characters is non-standard.

Standard or not, I'd rather my invalid input be blocked than allowed. With
your approach--which is fine--I have to dismiss an alert *and* possibly
manually undo the thing I did that isn't allowed.

> FWIW, I copy and paste four character codes most every day with a
> frequency that would probably alarm you. Interface Builder and XCode
> are happy to exchange the codes and copy and paste makes it much easier
> for me to ensure that I don't fat-finger the codes when trying to keep
> them in sync. Of course IB is more than happy to take more characters
> into the field than strictly make sense which is a less than ideal
> situation as well.
>
> Now if only IB would give me some way to export those codes en-masse
> into a header file with my own identifiers... But I digress :-)

I never paste codes into IB. When I first started using IB, I was using
unique control signatures in every window. Then I figured out I can use 0
and life with IB has been ever so much easier since.

Larry
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Set max chars for Unicode Edit Text control? (From: Scott Thompson <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.