Re: QDE (Quick Date Entry)

From: Frank Kabel (frank.kabel_at_freenet.de)
Date: 09/03/04 

Date: Fri, 3 Sep 2004 09:35:45 +0200

> Frank Kabel wrote...
> ..
>> Now we could argue what would be the better (better in this
>> case: easier to use for the end-user) approach. I like your idea
>> but dislike the idea of another hotkey.
> ..
>
> I'll grant that all design decisions are in part subjective, but in
> this case there's the issue about what would cause the least harm.
> That'd have to be determined empirically.

Agreed on that

> I still think separating entry and conversion is the most workable
way
> to go, and I'm dead certain no individual user ever needs multiple
> formats. But if they did, they could completely define how they
wanted
> ambiguous entries interpretted. Just enter them in another range like
> the following.

I'm with you that an *individual* user has his format and sticks to it.
What we had to deal with is that each individual user may have a
different date format. So of course creating a specific conversion
routine would be far more simpler than our (how did you call it)
'hammer approach' to deal with as many formats as possible.

[...]
very interesting code. We use a similar approach with array constants
to process the entries

> This isn't internationalized, but it could be by replacing the "ymd"
> string constant with a variable. That variable would be set by
> locating a blank cell, changing it's .NumberFormat property to "ymd"
> and storing its .NumberFormatLocal property in this new variable
> (then restoring its original format). If I'm right about this, this
> macro and defined name combination provides the equivalent
> functionality of your entire add-in.

This works (at least in my German version) but I still would go for the
registry settings (but this is more a personal taste). On the opposite
your approach requires a little bit more effort on the user side: he
has to create this defined name range somethere (or copy it manually
from workbook to workbook). No problem for a more experienced user who
also has no problem putting your code in a module, etc. We first
thought also about only providing the code without UI, etc. In the end
we thought that the user should do as little as possible. And perople
with your level of experience are probably not the target audience for
this add-in ;-)

Actually, it'd provide more
> because it could handle single digit dates, 4-digit dates like 7799,
> 9977 and 1234, and bypass 5- and 7-digit numbers.

4 digit dates are also handled by QDE. You're right about one digit
dates. We just omitted these entries (though easy to add) as design
decision. But I put this on our list for the next release.

> I still don't see why this requires a +500KB add-in. The core
> functionality just ain't that complicated.
We're currently trying to reduce the size (still something around
250K). And you're right. The core functionality is relatively 'simple'
and requires not that much code respectively. What adds to the size:
- Dialogs
- language translations
- etc.

But in my experience this is true for many programs that the core
functionality is relatively small. What one can argue about is if using
a real-time event handler is better than firstentering the short dates
and running a macro afterwards to convert all entries in one step.
We will discuss if we add a call to our processing routine which would
process all selected entries in one step without using event handlers
as second option

Frank