Input Mask for dateformat dd/mm/yyyy hh\:nn
Filips Benoit
I have a datefield that sometimes should store hours and minutes too ans use
following format and inputmask.
dd/mm/yyyy hh\:nn
09/09/0000\ 99:99;0;*
Typing date, hour and minutes is OK.
But i would like to be able to stop after the date-part like 12122005 and
enterkey giving 12/12/2005 00:00
But this triggers an error 'The value you entered isn't valid for this field
'
Is it possible to create a inputmask that accepts skipping the hour and
minutes ?
thanks,
Filip
Steve Jorgensen
On Sat, 17 Dec 2005 10:26:26 GMT, "Filips Benoit" <benoit...@pandora.be>
wrote:
Lyle Fairfield
2005-12-17
or I can enter
2005-12-17 09:00
Filips Benoit
no inputmask > you have to type 4 extra chars: 2 - 1 space and 1:
inputmask > you have to type 4 zero's extra at the end
I still prefere an inputmask since it shows clearly what type of date should
be input
And trapping inputmask-error can give a clear errormessage !
Filip
"Lyle Fairfield" <lylefa...@aim.com> wrote in message
news:1134821739.7...@g44g2000cwa.googlegroups.com...
Rick Brandt
> OK, but
>
> no inputmask > you have to type 4 extra chars: 2 - 1 space and 1:
>
> inputmask > you have to type 4 zero's extra at the end
>
> I still prefere an inputmask since it shows clearly what type of date
> should be input
> And trapping inputmask-error can give a clear errormessage !
And when I enter my name into a database I have to type 11 characters.
I have never understood why DateTimes are singularly expected to have some sort
of shortcut for entering them. No one would advocate a shortcut for entering
credit card numbers or social security numbers, but users always wants to
complain about how many keystrokes it takes to enter a date.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Arno R
"Filips Benoit" <benoit...@pandora.be> schreef in bericht news:BKUof.75489$k04.4...@phobos.telenet-ops.be...
> OK, but
>
> no inputmask > you have to type 4 extra chars: 2 - 1 space and 1:
>
> inputmask > you have to type 4 zero's extra at the end
FWIW:
If I use a format property like dd-mm-yyyy hh:mm (The Netherlands here...)
and if I don't use an inputmask ...
if I enter something like 4/2 (3 chars only), the result in my textbox is 04-02-2005 0:00
if I enter something like 14/2 (4 chars only), the result in my textbox is 14-02-2005 0:00
if I enter something like 14/12 (5 chars only), the result in my textbox is 14-12-2005 0:00
Arno R
Filips Benoit
Thanks
"Arno R" <arraNO...@tiscali.nl> wrote in message
news:43a42355$0$10085$ba62...@text.nova.planet.nl...
David W. Fenton
news:mtt7q196v87vrbahl...@4ax.com:
> Simple answer - input masks are evil. Don't use input masks.
Date masks are not infinitely flexible, so they can't do everything.
But where they are sufficient, they save a lot of coding.
I'd say that you should use them where they work and not use them
where they don't.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Steve Jorgensen
<XXXu...@dfenton.com.invalid> wrote:
>Steve Jorgensen <nos...@nospam.nospam> wrote in
>news:mtt7q196v87vrbahl...@4ax.com:
>
>> Simple answer - input masks are evil. Don't use input masks.
>
>Date masks are not infinitely flexible, so they can't do everything.
>But where they are sufficient, they save a lot of coding.
>
>I'd say that you should use them where they work and not use them
>where they don't.
Controls with input masks don't act the asme as controls anywhere else, and
that's true for dates as well. It's too easy to click on a character and
start typing in the middle, it's too hard to copy and paste, and it's too hard
to edit in the middle of a value. Besides, I prefer to be lazy and type
something like Aug 1, 2005 rather than remember the month number for Aug or
wonder what month/day order interpretation will be employed.
In my day job, I work on a shrink wrapped Access application that I didn't
write. When I suggested to the sales manager that I should take the input
masks off all the dates, he emphatically agreed since they had been
specifically annoying to him during training sessions. After I removed them,
one of our data entry people specifically came over to thank me for doing so.
Filips Benoit
Filip
"Steve Jorgensen" <nos...@nospam.nospam> wrote in message
news:pm49q1pp8n2jalivf...@4ax.com...
David W. Fenton
> On Sat, 17 Dec 2005 15:24:29 -0600, "David W. Fenton"
><XXXu...@dfenton.com.invalid> wrote:
>
>>Steve Jorgensen <nos...@nospam.nospam> wrote in
>>news:mtt7q196v87vrbahl...@4ax.com:
>>
>>> Simple answer - input masks are evil. Don't use input masks.
>>
>>Date masks are not infinitely flexible, so they can't do
>>everything. But where they are sufficient, they save a lot of
>>coding.
>>
>>I'd say that you should use them where they work and not use them
>>where they don't.
>
> Controls with input masks don't act the asme as controls anywhere
> else, and that's true for dates as well. It's too easy to click
> on a character and start typing in the middle, . . .
People doing data entry shouldn't be clicking on the control -- they
should be tabbing into it.
> . . . it's too hard to copy and paste, . . .
I've never run onto that problem, nor heard it as a complaint from
any users.
> . . . and it's too hard
> to edit in the middle of a value. . . .
Too hard for whom? Those who are incompetent with the keyboard?
> . . . Besides, I prefer to be lazy and type
> something like Aug 1, 2005 rather than remember the month number
> for Aug or wonder what month/day order interpretation will be
> employed.
Well, that's fine if that's what you want to do.
But date masks work perfectly well where they are appropriate. And
users get used to the way they work.
> In my day job, I work on a shrink wrapped Access application that
> I didn't write. When I suggested to the sales manager that I
> should take the input masks off all the dates, he emphatically
> agreed since they had been specifically annoying to him during
> training sessions. After I removed them, one of our data entry
> people specifically came over to thank me for doing so.
Well, one makes design decisions appropriate for the targets of an
app. That does not automatically mean that one should always avoid
data masks in all cases.
It's one of many techniques available for accomplishing a task.
Where it works, use it. Where it doesn't, don't.
Which is where I came in on this discussion. . .
Steve Jorgensen
<XXXu...@dfenton.com.invalid> wrote:
>Steve Jorgensen <nos...@nospam.nospam> wrote in
>news:pm49q1pp8n2jalivf...@4ax.com:
>
>> On Sat, 17 Dec 2005 15:24:29 -0600, "David W. Fenton"
>><XXXu...@dfenton.com.invalid> wrote:
>>
>>>Steve Jorgensen <nos...@nospam.nospam> wrote in
>>>news:mtt7q196v87vrbahl...@4ax.com:
>>>
>>>> Simple answer - input masks are evil. Don't use input masks.
>>>
>>>Date masks are not infinitely flexible, so they can't do
>>>everything. But where they are sufficient, they save a lot of
>>>coding.
>>>
>>>I'd say that you should use them where they work and not use them
>>>where they don't.
>>
>> Controls with input masks don't act the asme as controls anywhere
>> else, and that's true for dates as well. It's too easy to click
>> on a character and start typing in the middle, . . .
>
>People doing data entry shouldn't be clicking on the control -- they
>should be tabbing into it.
I'm sure they usually do, but data entry is not always linear, especially when
double-checking.
>> . . . it's too hard to copy and paste, . . .
>
>I've never run onto that problem, nor heard it as a complaint from
>any users.
I find it annoying myself, and so does our sales manager who demos the program
to prospective customers.
>> . . . and it's too hard
>> to edit in the middle of a value. . . .
>
>Too hard for whom? Those who are incompetent with the keyboard?
No - those who have habits based on how fields work that don't mix immutable
and mutable components - people like me.
>> . . . Besides, I prefer to be lazy and type
>> something like Aug 1, 2005 rather than remember the month number
>> for Aug or wonder what month/day order interpretation will be
>> employed.
>
>Well, that's fine if that's what you want to do.
>
>But date masks work perfectly well where they are appropriate. And
>users get used to the way they work.
That sounds plausible, but the data entry person who thanked me for removing
it has entered 1000 of records into the system.
>> In my day job, I work on a shrink wrapped Access application that
>> I didn't write. When I suggested to the sales manager that I
>> should take the input masks off all the dates, he emphatically
>> agreed since they had been specifically annoying to him during
>> training sessions. After I removed them, one of our data entry
>> people specifically came over to thank me for doing so.
>
>Well, one makes design decisions appropriate for the targets of an
>app. That does not automatically mean that one should always avoid
>data masks in all cases.
>
>It's one of many techniques available for accomplishing a task.
>Where it works, use it. Where it doesn't, don't.
>
>Which is where I came in on this discussion. . .
When I started learning Access, I used input masks a lot. Over time, I used
them less and less. My current opinion is that they always have more problems
than benefits. If data entry help should be provided for a date field, I use
a calendar-style date picker.
Tim Marshall
> OK, but
>
> no inputmask > you have to type 4 extra chars: 2 - 1 space and 1:
Use two or more separate controls. Combine the result in the on update
event of the record...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Tim Marshall
> People doing data entry shouldn't be clicking on the control -- they
> should be tabbing into it.
I'd agree, however, when a data entry preson realizes s/he's made a
mistake, the mouse is often used to go back to the offending control. I
run a work control call centre and my people do a lot of data entry...
tabbing is definitely the way to go, but there's lots of scope for
poking around with the mouse.
FWIW, my date controls always have an after update event which does a
lot of checking, in order to minimize key strokes (plus there's a button
which opens a calendar form). It doe involve a bit of code, but once it
was done, it's done. I've used more or less the same code since about 1999.
To include time, I'd prefer a separate, even two separate controls.
David W. Fenton
news:do558l$omc$1...@coranto.ucs.mun.ca:
> David W. Fenton wrote:
>
>> People doing data entry shouldn't be clicking on the control --
>> they should be tabbing into it.
>
> I'd agree, however, when a data entry preson realizes s/he's made
> a mistake, the mouse is often used to go back to the offending
> control. I run a work control call centre and my people do a lot
> of data entry... tabbing is definitely the way to go, but there's
> lots of scope for poking around with the mouse.
What about a keyboard shortcut for the date fields? Then the
individual who uses the keyboard for data entry could navigate to
those fields without needing to go to the mouse.
> FWIW, my date controls always have an after update event which
> does a lot of checking, in order to minimize key strokes (plus
> there's a button which opens a calendar form). It doe involve a
> bit of code, but once it was done, it's done. I've used more or
> less the same code since about 1999.
>
> To include time, I'd prefer a separate, even two separate
> controls.
Go back and read the thread. I *said* that one could get around the
shortcomings of input masks by writing code, but that for what they
did and the amount of code they eliminated, input masks are useful.
David W. Fenton
> Filips Benoit wrote:
>
>> OK, but
>>
>> no inputmask > you have to type 4 extra chars: 2 - 1 space and 1:
>
> Use two or more separate controls. Combine the result in the on
> update event of the record...
That adds code that isn't necessary with the input mask.
I'm not arguing that input masks are perfect or that it's a mistake
to code something more complex. I'm just saying that input masks
have their place. If they work for your particular situation, use
them. If they don't, do something else.
Tim Marshall
> Go back and read the thread. I *said* that one could get around the
> shortcomings of input masks by writing code, but that for what they
> did and the amount of code they eliminated, input masks are useful.
And I agree with your points. I was just commenting on the necessity of
sometimes going back to the keyed fields on a form even where tabbing is
carefully designed. I find my users totally ignore any keyboard short
cuts I include. 8(