wxMaskedTextCtrl 0.0.4 (with fries!)

Hi John,

Thanks much for the suggestions.

RE: Navigating to masking characters (e.g. '/')

I think maybe I'm trying too hard on this one. It's easy enough to navigate
to mask characters, but it turns out for different kinds of controls,
different behavior is expected. For example, if you type the first "2" in
your example below, then press '/', you expect *two* things to happen:

1- cursor to move _past_ the first '/'
2- the '2' to right-justify (immediately) within the first two spaces

I have been trying to get my head around a generic behavior for any mask
regarding mask character navigation, but maybe I should just code this
solution for date types and be done with it. Would you accept automatic
zero-filling, i.e. the '2' gets turned into '02'?

RE: Entering short dates

Version 0.0.6 now lets you enter 03/10/67 and it will auto-expand the date
to 03/10/1967 when you tab out of the field.

Thanks again for the input!

Regards,

Jeff Childers
jchilders_98@yahoo.com

···

-----Original Message-----
From: John Hopkins [mailto:john@hopkinsit.com]
Sent: Friday, February 14, 2003 9:37 PM
To: wxPython-users@lists.wxwindows.org
Subject: RE: [wxPython-users] wxMaskedTextCtrl 0.0.4 (with fries!)

Just jumping in, re:

Date formats that don't accept almost any type of deliminator

Hmmm, the goal I am shooting for is that the user _doesn't have to_ type

the
delimiters, >only the digits. For the developer, it is helpful to know what
sort
of delimiters will be >coming back from the control so he doesn't have to
code
for every possible configuration. >Can you give me more detail on this
point?

I like to type "02/02/1993" as "2/2/93" (I type the "/" chars, but not the
leading zeros or the Century digits). MS Access/VB/VBA masking lets me do
this.
I don't know how to solve the problem where the assigned (displayed)
delimiter
is "/" and the user wants to enter "." or "-". Access/VB/VBA doesn't bother
trying, and I'm not sure I would either. In this context you can consider
the
displayed delimiter character as a useful user prompt. An additional note:
The
way the mask allows a two-digit year is by distinguishing between "required"
and
"optional" characters. Here's the mask I use for the date field I just
described:
"09/09/0099;0;_".

In case you're not familiar with this specific idiom, ";" delimits the mask
expression itself. The first chunk sets out required integers (0) and
optional
ones (9). The second chunk tells the application to store only the
user-entered
portion of the control contents, and the final chunk determines what (if
any)
character will be displayed to guide the user to enter optional or required
characters. The masked field, on get focus but prior to the user entering
any
characters, looks like:
"__/__/____".

I hope this helps a bit. I'm delighted you're doing this work, and I'm
looking
forward to using the end-product!

John Hopkins

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

Jeff:

RE:

...you expect *two* things to happen:

  1- cursor to move _past_ the first '/'
  2- the '2' to right-justify (immediately) within the first two spaces

Yes, pretty much. See my next response.

... Would you accept automatic zero-filling, i.e. the '2' gets turned into '02'?

Yes, that's actually what I'm used to *and* what I prefer to display. I'm just
used to entering it with the '/' characters in "short date" format.

... it will auto-expand the date to 03/10/1967 when you tab out of the field.

Very Nice!

As far as the custom-code thing goes, I'm not sure I'm qualified to give advice.
But for the relatively common things I can think of (e.g. date, ip address,
decimal number) the behavior with regard to step 1 above is pretty consistent.
Step 2 has me a bit stuck, frankly, since decimal number probably doesn't need
zero fills and might be less legible for it, and ip addresses don't seem to user
them either. Maybe someone else will have a brilliant thought, here.

Thanks again for doing (and sharing!) this,

John