Re: [Pythoncard-users] making components less restrictive about a ttributes

[Kevin A. <al...@se...>]

On Apr 15, 2004, at 8:06 AM, Schollnick, Benjamin wrote:

>
>> Since you have control over what goes in the field within
>> your own code,
>> keyPress is probably the easiest since it would just deal
>> with what a user
>> types.
>>
>> Given a TextField named 'fld' the following event handler
>> should do what you
>> want for plain ascii as well as unicode strings
>>
>>     def on_fld_keyPress(self, event):
>>         upper = chr(event.keyCode).upper()
>>         if chr(event.keyCode) != upper:
>>             event.target.replaceSelection(upper)
>>         else:
>>             event.skip()
>
> Why even check to see the keycode is uppercase?
> Is there really that much latency with the uppercase
> function?  Yet, do we care if it was already uppercase?
> Uppercasing a uppercase letter results in a uppercase
> letter....
>
> Since the desire is for the result to be uppercase,
> there is two ways to approach this.
>
> At data entry, which is what you presented...
> Here's my alteration of your code:
>
>      def on_fld_keyPress(self, event):
> 	"""Force the results from the keypress to be uppercase.
> 	"""
>          event.target.replaceSelection( chr(event.keyCode).upper() )

Did you actually test this code? If you did then you should have gotten 
some errors when you used the arrow keys, backspace characters would 
have been inserted into the text, etc. So yes, there is a reason for 
the check and in order to deal with ASCII as well as Unicode, the the 
logic I chose is a simple solution. There could be other boundary 
conditions that will break it, I didn't do extensive testing or try it 
with a unicode build of wxPython, but I'm pretty sure it is correct.

> Or alternatively, when the entry is done and the user moves to the next
> field, just do a .upper() on the text string as you leave the field.

You can do that easily with a closeField handler, which only occurs 
when the contents of a field have been changed.

> I would suggest that as a standard pythoncard option, that the field be
> untouched, or made uppercase, lowercase or normal after leaving the 
> field.
> The logic for that should only be a few lines of code, but would be 
> quite
> helpful...
>
I don't see the benefit to this for the standard field. I would like to 
have a masked input field sometime and/or validated field which can 
automatically deal with various transformations and restricted input, 
but due to the extra complexity of such a component I see that as 
something separate from a simple TextField.

ka