QDE (Quick Date Entry)

N

Norman Harker

Hi Community of Excel Users!

This is a joint posting from 4 of the "regulars" to these newsgroups:
Bob Phillips, Frank Kabel, Ron de Bruin, and Norman Harker.

QDE.xla Version 1 is now available *free* from:

Bob Phillips
http://www.xldynamic.com/source/xld.QDEDownload.html
and
Ron de Bruin
http://www.rondebruin.nl/qde.htm

A long outstanding feature request in these newsgroups has been for a
robust method by which dates can be entered as numbers only. By
"robust" we mean a method that will stand up to the fullest possible
range of Operating System settings.

Although this is Version 1, it has been tested as much as possible
within the constraints we faced. However, we believe that it is now
ready for release and we hope that the community of Excel users will
appreciate what we have tried to achieve and will have no problems
with using it.

It comes with the usual full money back if not delighted guarantee;
"You pay nothing for it and you'll get nothing back!"

Edited thrilling highlights of what QDE is all about are provided
below our sign-off with further details in the Help File and at the
link above.

Regards


Norman Harker, Sydney, Australia
Bob Phillips, Poole, England
Frank Kabel, Frankfurt, Germany
Ron de Bruin, Netherlands


***** Edited Highlights of QDE

*** Background:
This is a joint effort of 4 of the "regulars" Bob Phillips, Frank
Kabel, Ron de Bruin and Norman Harker.

*** Why QDE?
Entry of dates into Excel is not too difficult to master for any given
set of Operating System Regional Settings although users have to
appreciate the inbuilt assumptions that Excel makes regarding various
date entry forms.

However, where large numbers of dates need to be entered, Excel's date
serial number approach imposes obligations to use date separators (eg.
03-05-2004).

Where many dates are required to be entered, this imposes a
requirement for more key presses than might be achieved. For example,
we might prefer just to enter
0305 and have this interpreted "correctly" as 03-05-04. If we can do
this, we save 4 key presses. Big deal? Not really! Unless, that is,
you have many hundreds or even thousands of such dates to enter.

This is why we need QDE. We need a means by which we can economize on
the number of keystrokes required to enter dates.

*** What Is QDE?
QDE is an Excel Addin that provides quick input of dates, in all
international formats. With QDE you now have the option to enter dates
using numbers only.
These are interpreted by QDE as dates based upon settings which you
will rarely, if ever, need to change.

QDE is a stand-alone utility, that once installed is available to all
of your workbooks and worksheets. It does not change anything on the
worksheet until directed to by you the user.
Once dates are entered they are treated by Excel as dates entered
using non-QDE methods. Workbooks constructed with the assistance of
QDE do not require that QDE should remain installed or even be present
on whatever computer the workbook is open on.

*** Where Did It Come From?
Date entry has been a perennial problem in Excel. Many people want to
input the date components (day. month, year) without having to bother
with the date delimiters. The problem here is that Excel then
interprets this as a normal number, not a date. Chip Pearson made the
first serious attempt at a solution that we know of, which you can see
at Chip's site on his Date and Time Entry page, Whilst it does show
some of the issues that need to be addressed, it is US date centric,
and there are a couple of problems with the input.
Norman Harker decided that a full international version of this
routine was needed. Norman is an Excel MVP based in Sydney, Australia
and is a regular contributor to the Excel newsgroups. He has a special
interest in Excel's date handling capabilities. Norman posted a
tentative solution which was hitting problems.

There were many follow up responses to this query, mainly from Frank
Kabel, based in Frankfurt, Germany and Bob Phillips, based in Poole,
England. Both are regular contributors to the Excel newsgroups. The
discussions moved the problem on somewhat, but as usual, further
issues were revealed as the "regulars"
educated themselves on the complexities involved.

At this point, Norman, Frank and Bob decided informally that the
newsgroups were not the best forum for development work and informally
agreed to set up a team to tackle the problem. Ron de Bruin, another
Excel MVP, was recruited to provide the extra skills and experience
needed, and QDE was conceived.
There were many problems along the way to what we have here. These
were mainly those of ensuring that all international issues, operating
system settings and Excel versions were covered. This is the result of
that development, and we hope that you enjoy it and find it useful.

If you are interested, you can see the original newsgroup discussion
that gave rise to QDE at this Google thread

http://tinyurl.com/3luwe

*** How It Works
This is a classic case of, "Easier said than done!"

Excel has limited date interpretation capabilities that are inherent
in Excel not using a dedicated data type (as is common for database
programs).
Excel uses the date serial number concept whereby dates are nothing
more than a format of a number with 1 representing a base date.
However, users, want to enter dates quickly with as few numbers and
key presses as is possible, and to have Excel interpret those numbers
as the dates that the user intends.

The trouble is that there are three interacting issues:

1. There are two date serial number bases in Excel; the 1900 Date
System where 1 represents 1-Jan-1900 and the 1904 Date System where 1
represents 1-Jan-1904.
The 1900 Date System is the default setting for Windows and the 1904
Date System is the default setting for Mac. But Excel for Windows also
allows you to change the default setting to the 1904 Date System.

2. Ordering the three parameters of day month and year varies
according to the user's country custom. In the US (predominantly)
entry is Month > Day > Year. In some Asian countries and in countries
that have adopted the International Standard ISO8601:2000 the order is
Year > Month > Day. The rest of the world (when using the Gregorian
Calendar), including most of Europe, UK, South America and former
British Colonies all use Day > Month > Year.

3. The quick date entry of a user might be from 3 to 8 digits long
depending upon whether or not it was a single or double digit day or
month number and whether or not they were entering a double digit or
four digit year (or, indeed, wanted the current year to be assumed).
QDE handles quick date entry interpretation and reflects these three
interacting issues. In most situations those issues are handled only
once for a given range or worksheet and most often the user will not
even have to change the parameters that QDE takes from current Excel
and Operating System settings.

End of Post.
 
H

hgrove

Having read the help file, qde.chm, it says your add-in adds code t
worksheet class modules apparently by replacing Change an
SelectionChange event handlers. Uh, guys, you need to refresh you
understanding of systems programming. Since your add-in is manipulatin
VBE objects, you *could* add *additional* procedures to worksheet clas
modules and *add* a statement to existing event handlers calling th
added procedures.

That said, it's buggy (or the documentation is inadequate).

Following your installation and usage instructions, I opened a ne
workbook, and activated QDE in Sheet1 of that workbook, set Priority t
Day Priority checked Current Year, and specified A1:A10 as the dat
entry range. With A1:A10 selected, I entered various numbers in thes
cells. As I entered them, nothing changed (possibly because th
Selection didn't change though the ActiveCell moved through th
selected range). Once I finished entering them and moved though th
entry range with cursor keys, the entries changed to dates when eac
cell was activated.

Here are my entries and the resulting dates (standard US).

Entry___Not Activated____Activated

__1____01/01/1900____12/31/1899
_10____01/10/1900____01/09/1900
_11____01/11/1900____01/10/1900
100____04/09/1900____04/09/1900
101____04/10/1900____04/10/1900
110____04/19/1900____04/19/1900
111____04/20/1900____04/20/1900
122____05/01/1900____05/01/1900
131____05/10/1900____05/10/1900
222____08/09/1900____08/09/1900

Doesn't match up with claimed functionality. Also, the fact that th
dates in A1:A3 display as one day before when those cells are th
active cell would be an indication there's an off-by-one bug somewher
in the code.

I'm running XL97 SR-2 under Windows NT4 SP-6. 1900 date system
mm/dd/yyyy default date format.

How many besides you 4 have *tested* this? If no others, then you'v
got *BETA* stage software at best. You should include standar
beta-level warnings somewhere in your package.

Personally I don't find this sort of thing useful mostly because
don't enter many dates. The vast bulk of what I work with comes fro
network and online sources. For anyone with Access, they'd be bette
off entering lots of dates in Access using date input masks. There ma
even be freeware or cheap shareware lightweight databases with dat
input mask features. What I'm getting at is that there may be littl
need for a product such as this. After all, if the date entry cell
were formatted as Text, then it really is painless to convert entrie
to dates with formulas only.

1 -> day of month in current month and year
11 -> ambiguous, either md, dm or dd in current month and year
111 -> ambiguous, either mmd, mdd, dmm or ddm
1111 -> ambiguous, either mmdd or ddmm (dmmy etc possible*)

anything longer would include years.

One point y'all may not have considered is that Excel most users woul
enter dates in one and only one format. For the most part individua
users would never change their settings. Only resolution of ambiguous
and 3 digit partial dates would possibly differ between uses, and thos
could also be handled purely by formula.

1 -> 1-Sep-2004
11 -> 11-Sep-2004
111 -> 11-Jan-2004
1111 -> 11-Nov-2004
=--IF(LEN(x)<=2,MONTH(NOW())&"-"&x,LEFT(x,
ROUNDDOWN(LEN(x)/2,0))&"-"&RIGHT(x,ROUNDUP(LEN(x)/2,0)))

1 -> 1-Sep-2004
11 -> 1-Jan-2004
111 -> 1-Nov-2004
1111 -> 11-Nov-2004
=--IF(LEN(x)=1,MONTH(TODAY())&"-"&x,LEFT(x,
ROUNDUP(LEN(x)/2,0))&"-"&RIGHT(x,ROUNDDOWN(LEN(x)/2,0)))

5 through 8 digit entries would also best be handled by insertin
dashes between groups of 1 or 2 numerals then using -- on the resultin
string to convert to date numbers.

While I appreciate you all spent some time & effort on this, it jus
doesn't seem to merit a +500KB add-in that can't coexist wit
preexisting Change and SheetChange event handlers
 
R

Ron de Bruin

Hi Harlan

VBE objects, you *could* add *additional* procedures to worksheet class
modules and *add* a statement to existing event handlers calling the
added procedures.

You are right, but we start with this and are open for all comments.

Following your installation and usage instructions, I opened a new
workbook, and activated QDE in Sheet1 of that workbook, set Priority to
Day Priority checked Current Year, and specified A1:A10 as the date
entry range. With A1:A10 selected, I entered various numbers in these
cells. As I entered them, nothing changed (possibly because the
Selection didn't change though the ActiveCell moved through the
selected range). Once I finished entering them and moved though the
entry range with cursor keys, the entries changed to dates when each
cell was activated.

Good Catch in 97
I never notice this when testing it in 97 on a Virtual PC
in 2000-2003 this is working correct

If you enter 1 for example in a cell it will not accept it in all the other Excel versions(we have a bug here)

What I'm getting at is that there may be little
need for a product such as this

No problem, we do this for fun Harlan


I am sure that Norman will respond also with good English.
Thanks for your reply
 
F

Frank Kabel

Hi Harlan
just in addition to Ron :)

hgrove > said:
Having read the help file, qde.chm, it says your add-in adds code to
worksheet class modules apparently by replacing Change and
SelectionChange event handlers. Uh, guys, you need to refresh your
understanding of systems programming. Since your add-in is manipulating
VBE objects, you *could* add *additional* procedures to worksheet class
modules and *add* a statement to existing event handlers calling the
added procedures.
That said, it's buggy (or the documentation is inadequate).

First thanks for reading + testing it (honestly!). As Ron said this was
our go-in position. As The event code is a little bit more complex it
would be kind of difficult only to 'add' the code to existing event
handlers and removing the code would be even more complicated. So yes
we chose the easier way. I would totally agree with you if it were just
a simple statement but it is a little bit more code involved.
BUT we should (and will) add this in the documentation to clarify this
possible issue!

Following your installation and usage instructions, I opened a new
workbook, and activated QDE in Sheet1 of that workbook, set Priority to
Day Priority checked Current Year, and specified A1:A10 as the date
entry range. With A1:A10 selected, I entered various numbers in these
cells. As I entered them, nothing changed (possibly because the
Selection didn't change though the ActiveCell moved through the
selected range). Once I finished entering them and moved though the
entry range with cursor keys, the entries changed to dates when each
cell was activated.

Excel 97 is really different. Though tested with various versions and
different languages we didn't catch thus bug. Thanks for spotting it.
Have you tried entering the dates then only a single cell is selected
(hopefully this works for you?)

[....]
Doesn't match up with claimed functionality. Also, the fact that the
dates in A1:A3 display as one day before when those cells are the
active cell would be an indication there's an off-by-one bug somewhere
in the code.

See above for the bug reason

[...]
How many besides you 4 have *tested* this? If no others, then you've
got *BETA* stage software at best. You should include standard
beta-level warnings somewhere in your package.

Some more but also as stated in Norman's email we 'hoped' that no bug
is there anymore. Maybe next time we should invite you to out beta test
Personally I don't find this sort of thing useful mostly because I
don't enter many dates. The vast bulk of what I work with comes from
network and online sources. For anyone with Access, they'd be better
off entering lots of dates in Access using date input masks. There may
even be freeware or cheap shareware lightweight databases with date
input mask features. What I'm getting at is that there may be little
need for a product such as this. After all, if the date entry cells
were formatted as Text, then it really is painless to convert entries
to dates with formulas only.

Personally I don't need this either but many questions in this NG
suggested this requirement. Personally I prefer using a database for
mass data but Excel is often used differently and it seems to me that
many users use it for this kind of data processing. In addition to Ron:
- pure fun for us (therefore totally free addin)
- also a learning excercise (international date settings, manipulationg
event handlers, mutli-language support, etc.)
- So for me if at least one user uses it my personal goal is achieved
:)))

1 -> day of month in current month and year
11 -> ambiguous, either md, dm or dd in current month and year
111 -> ambiguous, either mmd, mdd, dmm or ddm
1111 -> ambiguous, either mmdd or ddmm (dmmy etc possible*)
or even dmyy

One point y'all may not have considered is that Excel most users would
enter dates in one and only one format. For the most part individual
users would never change their settings. Only resolution of ambiguous 2
and 3 digit partial dates would possibly differ between uses, and those
could also be handled purely by formula.
Totally agree with you that this could handled also by formulas BUT
this would require a helper column. This is saved by the addin

[...]
While I appreciate you all spent some time & effort on this, it just
doesn't seem to merit a +500KB add-in that can't coexist with
preexisting Change and SheetChange event handlers.

As we won't want to earn money with it we at least had our fun
developing it. And thanks again for your valid comments + suggestions +
bug reports.

Regards
Frank
 
N

Norman Harker

Thanks Harlan!

Just the sort of comments we need and will take on board.

Frank and Ron have covered the technical issues you raised. I'll stick
to utility.

Same as you, I don't often need this type of tool as I don't often
have to enter that many dates.

But there are researchers out there plus other mass date entry users
who will benefit significantly from QDE *if* we've got it right.

There is, without a shadow of doubt, a pain before you gain! And you
will not gain enough to warrant the pain unless you have a significant
major date entry requirement.

You need to install. You need to master what we hope is a fairly
simple user interface for setting up or accepting defaults. Then it's
a reasonably fast process of activation and range setting and you are
off!

Pretty extensive, but nonetheless imperfect, testing indicated that
QDE works OK. We don't think that many users will hit problems but
obviously we keep our fingers crossed. We certainly don't have the
time or resources that are needed to test in a multitude of
environments. I think that you are right though in indicating that a
beta indication was warranted pending operation under fire.

What we are attempting to redress is a fundamental defect / inadequacy
in Excel. It doesn't have a dedicated data type for dates and times
but uses special formatting of numbers plus interpretation of date
type entries. That attempt must have limitations and the pain > gain
trade-off that you've hit on is the biggest one for most users.

Now if we could have the sort of Spreadsheet program that we could
design from base up without the accumulated detritus and historically
imposed limits. Plus avoid the need for backwards compatibility...
Nirvana! I hope to see you there.
 
H

hgrove

Frank Kabel wrote...
...
. . . As The event code is a little bit more complex it would be
kind of difficult only to 'add' the code to existing event handlers
and removing the code would be even more complicated. So yes
we chose the easier way. I would totally agree with you if it
were just a simple statement but it is a little bit more code
involved.
...

I'll repeat - y'all need to revisit your systems programming.

Something else I just thought of. If there were date entry ranges in
or more worksheets in a workbook, would each worksheet's class modul
get its very own copy of the QDE Change and SelectionChange even
handlers? Seems rather wasteful. Wouldn't it make more sense to add th
procedures to be called to a separate general module and add singl
lines to preexisting Change and SelectionChange event handlers o
create single statement event handlers if there were none to begi
with?

Just make the macros parametrized, and they won't appear in the Macr
Run dialog. Users would have to go out of their way to call them, an
if they perceived a need to do so, why not?
Excel 97 is really different. Though tested with various versions
and different languages we didn't catch thus bug. Thanks for
spotting it. Have you tried entering the dates then only a single
cell is selected (hopefully this works for you?)
...

So you all hadn't even tested this under XL97? I'll revise my earlie
assessment - it's an *ALPHA* release (at least for XL97). Did any o
you test this under XL2K?

WHERE ARE THE WARNINGS?!

It works if only one cell is selected when a date entry is made. IMO,
requirement that only a single cell should be selected for this add-i
to work would obviate much of its claimed purpose of reducing use
keystrokes. Do any of the authors believe most users would expect it t
work when entire data entry ranges were selected? Or do you all believ
that users must set their Edit options to move selection after enter?
Some more but also as stated in Norman's email we 'hoped'
that no bug is there anymore. Maybe next time we should invite
you to out beta test
...

How naive.

There are ALWAYS bugs in any code more than a few dozen lines. All tha
one may hope is that the bugs manifest themselves rarely.

Perhaps you all may learn from this what TESTING really means. For m
to have caught a bug arising from entry into multiple selected cell
means it wasn't EFFECTIVELY tested at all no matter how many peopl
tried it out on single cell ranges.

Why do you need to use the SelectionChange event in addition to th
Change event? That just doesn't make sense to me. I'd also note th
check for the selection being a single cell in the Change event handle
is ill-considered. If you check that the selection does span multipl
cells, then you only need to check th
Application.MoveAfterReturnDirection property and use that informatio
sensibly in an Offset range property call to figure out which cell mus
have changed. Granted there are wrap-around issues, but perhaps you al
can have fun and gain enlightenment figuring that out.
Personally I don't need this either but many questions in this NG
suggested this requirement. Personally I prefer using a
database for mass data but Excel is often used differently and it
seems to me that many users use it for this kind of data
processing. . . .

You have one individual who's asked about this several times in th
last few months, and others who each ask once infrequently. What'
wrong with the standard response of using a macro, which users coul
run when they want to, to convert entries to dates in place in batch?
In addition to Ron:
- pure fun for us (therefore totally free addin)
- also a learning excercise (international date settings,
manipulationg event handlers, mutli-language support, etc.)
- So for me if at least one user uses it my personal goal is
achieved

Personal discovery is fine in it's place, but responsible peopl
shouldn't distribute lightly tested, problematically useful softwar
without warnings about its state of development. If you all didn'
realize what state of development it was at, you shouldn't have
released it at all.
Totally agree with you that this could handled also by formulas
BUT
this would require a helper column. This is saved by the addin

Wrap the formulas' logic in a macro.


Code:
--------------------

Sub foo()
Dim c As Range, f As String, df As String

If Not TypeOf Selection Is Range Then Exit Sub

For Each c In Selection.Cells
If Not (c.HasFormula Or c.Formula Like "*[!0-9 ]*") Then
f = c.Formula

If Not IsError(Evaluate("." & f)) Then
df = CStr(CDate("1-Feb-2003"))
df = Application.Substitute(df, "2003", "yyyy")
df = Application.Substitute(df, "03", "yyyy")
df = Application.Substitute(df, "02", "mm")
df = Application.Substitute(df, "2", "m")
df = Application.Substitute(df, "01", "dd")
df = Application.Substitute(df, "1", "d")

Select Case Len(f)
Case 1
f = Format(Now, "yyyy-mm-0" & f)
Case 2
f = Format(Now, "yyyy-mm-" & f)
Case 3
f = Format(Now, "yyyy-0") & Left(f, 1) & "-" & Right(f, 2)
Case 4
f = Format(Now, "yyyy-") & Left(f, 2) & "-" & Right(f, 2)
Case 6
f = "20" & Right(f, 2) & "-" & Left(f, 2) & "-" & Mid(f, 3, 2)
Case 8
f = Right(f, 4) & "-" & Left(f, 2) & "-" & Mid(f, 3, 2)
Case Else
Debug.Print c.Address(0, 0, xlA1, 1) & " not a valid date"
End Select

If c.NumberFormat <> "General" Then c.NumberFormat = df

c.Formula = f

End If

End If

Next c

End Sub

--------------------

As we won't want to earn money with it we at least had our fun
developing it. And thanks again for your valid comments +
suggestions + bug reports.

So if you don't want to make $$ from it, why not open source it? Then
others could point out the bugs in the code for you.
 
J

JE McGimpsey

hgrove said:
If you check that the selection does span multiple cells, then you
only need to check the Application.MoveAfterReturnDirection property
and use that information sensibly in an Offset range property call to
figure out which cell must have changed.

FWIW, I've always found using Change event while depending on the
..MoveAfterReturnDirection property problematic. Within a multicell
selection, the Change event can be fired by the Enter key, shift-Enter,
the tab key, shift-tab, del, Delete, Edit/ClearContents, and ctrl-click,
a change in sheet or workbook, at least. Not to mention that Undo and
Redo seem to fire _Change() twice. In addition, I routinely set up my
MacXL version to have the .MoveAfterReturnDirection set to xlDown, but
not to move after the keypad Enter key. Pasting into a multicell
selection returns a union of the range and the activecell.

It's even worse when dealing with a multiple area range.
 
H

Harlan Grove

hgrove > said:
I'll repeat - y'all need to revisit your systems programming.
....

For example,


Sub foo()
Dim cm As CodeModule, k As Long, n As Long

Set cm = ActiveWorkbook.VBProject.VBComponents("Sheet1").CodeModule

With cm
k = .ProcStartLine("Worksheet_SelectionChange", vbext_pk_Proc)
n = .ProcCountLines("Worksheet_SelectionChange", vbext_pk_Proc)

If Not .Find("Call foobar", k + n - 2, 1, k + n, 80, -1, 0, 0) Then
.InsertLines k + n - 1, Chr(9) & "Call foobar"
End If

End With

End Sub


I'm not going to say it's easy to modify preexisting event handlers, but it
*IS* possible. A similar approach could be used to delete added statements.

As for the macro I gave in my preceding response, drop the df statements. If
a cell would be changed to a date with system default date format if
originally formatted as General and an ISO date (yyyy-mm-dd) date were
entered into it, then all that's needed is changing the number format to
General and entering an ISO date string.

Note that I'm now bypassing cells already containing dates (so formatted as
dates).


Sub foo()
Dim c As Range, f As String

If Not TypeOf Selection Is Range Then Exit Sub

For Each c In Selection.Cells
If Not (c.HasFormula Or c.Formula Like "*[!0-9 ]*" _
Or VarType(c.Value) = vbDate) Then
f = c.Formula

If Not IsError(Evaluate("." & f)) Then

Select Case Len(f)

Case 1
f = Format(Now, "yyyy-mm-0" & f)

Case 2
f = Format(Now, "yyyy-mm-" & f)

Case 3
f = Format(Now, "yyyy-0") & Left(f, 1) & "-" & Right(f, 2)

Case 4
f = Format(Now, "yyyy-") & Left(f, 2) & "-" & Right(f, 2)

Case 6
f = "20" & Right(f, 2) & "-" & Left(f, 2) & "-" & Mid(f, 3, 2)

Case 8
f = Right(f, 4) & "-" & Left(f, 2) & "-" & Mid(f, 3, 2)

Case Else
Debug.Print c.Address(0, 0, xlA1, 1) & " not a valid date"

End Select

If Not IsError(Evaluate("--" & f)) Then
c.NumberFormat = "General"
c.Formula = f
End If

End If

End If

Next c

End Sub


I'm not claiming a deep understanding of internationalization issues, but
from what I gleen from VBA online help, the .NumberFormat property is always
in English while the .NumberFormatLocal may not be, and VBA's Format
function takes only English date formatting metacharacters. If so, the code
above should work for interpretting date entries so that 2 digits are always
just the day in the current month, and 3 digits are necessary to provide
month as well as day of month. Easy enough to adapt to d[d[m[m]]] short date
entries or other individual user needs.

. . . I'd also note the check for the selection being a single cell in
the Change event handler is ill-considered. If you check that the
selection does span multiple cells, then you only need to check the
Application.MoveAfterReturnDirection property and use that information
sensibly in an Offset range property call to figure out which cell must
have changed. Granted there are wrap-around issues, but perhaps you all
can have fun and gain enlightenment figuring that out.

That was stupid of me. The user could have moved to the current ActiveCell
either by [Enter], [Shift]+[Enter], [Tab], [Shift]+[Tab] or not have moved
at all but clicked on the check mark in the formula bar to enter the
ActiveCell.

This points out a design flaw in QDE. If users do select entire date entry
ranges and enter dates just pressing [Enter] or [Tab], shifted or not, your
Change event handler won't process the entries since the selected range's
cell count is > 1, but the SelectionChange event handler won't fire at all
as long as the entire entry range remains selected. The only way to convert
dates entered in such manner is to select some other range then reselect the
entry range. Clumsy and undocumented would be a charitable assessment.

Better to change cells as entered rather than rely on the SelectionChange
event handler cleaning up such entries when & if users *re*select entry
ranges. I understand that you don't want to have to process all cells in the
intersection of the selected range and the QDE date entry range, but you
don't have to. All you need to process are the up to 5 cells that could have
changed: the active cell itself (user clicked on the check mark in the
formula bar) and the preceding cells if the user had pressed [Enter],
[Shift]+[Enter], [Tab] or [Shift]+[Tab].

Here's a brute force approach to determining those cells.

Dim a As Range

Application.EnableEvents = False
Application.ScreenUpdating = False

Set a = ActiveCell
SendKeys "~", -1
Set a = Union(a, ActiveCell)
SendKeys "+~+~", -1
Set a = Union(a, ActiveCell)
SendKeys "~{TAB}", -1
Set a = Union(a, ActiveCell)
SendKeys "+{TAB}+{TAB}", -1
Set a = Union(a, ActiveCell)
SendKeys "{TAB}", -1

Application.EnableEvents = True
Application.ScreenUpdating = True

Elegant alternatives are left to you for fun & enlightenment.
 
H

Harlan Grove

JE McGimpsey said:
FWIW, I've always found using Change event while depending on the
.MoveAfterReturnDirection property problematic. . . .
....

Yeah, I figured that out belatedly myself.

However, for an add-in that supposed to support fewer keystrike date entry,
it's not unreasonable to assume that the actual changed cell when the Change
event is fired is either the ActiveCell itself or the cell activated by
[Enter], [Shift]+[Enter], [Tab] or [Shift]+[Tab]. Redundant to process all 5
on each Change event, but MUCH better than processing a selected range
spanning hundreds or thousands of cells.
 
F

Frank Kabel

Frank Kabel wrote...
..
..

I'll repeat - y'all need to revisit your systems programming.

Something else I just thought of. If there were date entry ranges in 2
or more worksheets in a workbook, would each worksheet's class module
get its very own copy of the QDE Change and SelectionChange event
handlers? Seems rather wasteful. Wouldn't it make more sense to add the
procedures to be called to a separate general module and add single
lines to preexisting Change and SelectionChange event handlers or
create single statement event handlers if there were none to begin
with?

Just make the macros parametrized, and they won't appear in the Macro
Run dialog. Users would have to go out of their way to call them, and
if they perceived a need to do so, why not?

Hi Harlan
point taken. We'll investigate this -> next release :)
..

So you all hadn't even tested this under XL97? I'll revise my earlier
assessment - it's an *ALPHA* release (at least for XL97). Did any of
you test this under XL2K?

of course we have tested it under Excel 97!!!!. No question about this.
My statement was just meant to be that this is another issue with Excel
97 whcih is not documented, etc. We have included several workarounds
already for dealing with Excel 97 but this one error you found just
asn't catched by us. Thats all. Also XL2K + XL2003 was tested

WHERE ARE THE WARNINGS?!
see above


It works if only one cell is selected when a date entry is made. IMO, a
requirement that only a single cell should be selected for this add-in
to work would obviate much of its claimed purpose of reducing user
keystrokes. Do any of the authors believe most users would expect it to
work when entire data entry ranges were selected? Or do you all believe
that users must set their Edit options to move selection after enter?

See above. An Excel 97 issue we will definetly look into.



[...]
How naive.

There are ALWAYS bugs in any code more than a few dozen lines. All that
one may hope is that the bugs manifest themselves rarely.

Perhaps you all may learn from this what TESTING really means. For me
to have caught a bug arising from entry into multiple selected cells
means it wasn't EFFECTIVELY tested at all no matter how many people
tried it out on single cell ranges.

This case was tested but we missed the error under Excel 97. So Harlan
come on: yes it is a bug, yes we will look into it and the cause is
again Excel 97 behaviour (not an excuse though).

Why do you need to use the SelectionChange event in addition to the
Change event? That just doesn't make sense to me. I'd also note the
check for the selection being a single cell in the Change event handler
is ill-considered. If you check that the selection does span multiple
cells, then you only need to check the
Application.MoveAfterReturnDirection property and use that information
sensibly in an Offset range property call to figure out which cell must
have changed. Granted there are wrap-around issues, but perhaps you all
can have fun and gain enlightenment figuring that out.

There're other reasons for using the Selection_Change event handler.
Most are releated to formating issues of the date entry cell and
preventing errors if you enter a short date with a leading zero. In
effect the selection change event handler does:
- change the format of the selected cell to text
- restores the old format afterwards
- checks for formulas, etc.

This only to allow an entry of for example 0311 in the cell. If you
wouldn't change the format prior to entry Excel will skip the '0' and
(depending on your chosen settings) this entry could get interpretedt
as 31-Jan-2004 and not as 3-Nov-2004.
I agree with you that this is a 'crude' workaround and I'd be happy if
there's a better solution (so if you have one I would be VERY happy)


You have one individual who's asked about this several times in the
last few months, and others who each ask once infrequently. What's
wrong with the standard response of using a macro, which users could
run when they want to, to convert entries to dates in place in batch?

Nothing but a very common standard response is also the link to Chip's
website showing a similar approach

Personal discovery is fine in it's place, but responsible people
shouldn't distribute lightly tested, problematically useful software
without warnings about its state of development. If you all didn't
realize what state of development it was at, you shouldn't have
released it at all.

and again: It was intensively tested and you just got this one bug
(which has to be solved, of course). And as Ron already said we should
have said something more about the release state



[....]
So if you don't want to make $$ from it, why not open source it? Then
others could point out the bugs in the code for you.
Point to consider for us

Frank
 
F

Frank Kabel

hgrove > said:
I'm not going to say it's easy to modify preexisting event handlers, but it
*IS* possible. A similar approach could be used to delete added
statements.

No questions that it is in general feasible. So just give us the time
for a next release :)))
As for the macro I gave in my preceding response, drop the df statements. If
a cell would be changed to a date with system default date format if
originally formatted as General and an ISO date (yyyy-mm-dd) date were
entered into it, then all that's needed is changing the number format to
General and entering an ISO date string.

Nice procedure BTW BUT you mentioned the restrixtion: The user has to
enter in YYYY-MM-DD format. This is not very common for most userss
(though it would solve several issues). Most of our code is not the
parsing but dealing with different formats


[...]
I'm not claiming a deep understanding of internationalization issues, but
from what I gleen from VBA online help, the .NumberFormat property is always
in English while the .NumberFormatLocal may not be, and VBA's Format
function takes only English date formatting metacharacters. If so, the code
above should work for interpretting date entries so that 2 digits are always
just the day in the current month, and 3 digits are necessary to provide
month as well as day of month. Easy enough to adapt to d[d[m[m]]] short date
entries or other individual user needs.

Now you only have to define what 4 digits represent :)
YYMD
MMDD

And yes you're correct. The Format function works as expected in other
languages as well

[...]
This points out a design flaw in QDE. If users do select entire date entry
ranges and enter dates just pressing [Enter] or [Tab], shifted or not, your
Change event handler won't process the entries since the selected range's
cell count is > 1, but the SelectionChange event handler won't fire at all
as long as the entire entry range remains selected. The only way to convert
dates entered in such manner is to select some other range then reselect the
entry range. Clumsy and undocumented would be a charitable
assessment.

No problem under Excel 2000K and above. The change handler gets fired.
for the relevant cells. It is just different in Excel 97.
Though there's an issue we have to look into. In these cases entries
such as 0103 could be problematic.


Better to change cells as entered rather than rely on the SelectionChange
event handler cleaning up such entries when & if users *re*select entry
ranges. I understand that you don't want to have to process all cells in the
intersection of the selected range and the QDE date entry range, but you
don't have to. All you need to process are the up to 5 cells that could have
changed: the active cell itself (user clicked on the check mark in the
formula bar) and the preceding cells if the user had pressed [Enter],
[Shift]+[Enter], [Tab] or [Shift]+[Tab].

Here's a brute force approach to determining those cells.

Dim a As Range

Application.EnableEvents = False
Application.ScreenUpdating = False

Set a = ActiveCell
SendKeys "~", -1
Set a = Union(a, ActiveCell)
SendKeys "+~+~", -1
Set a = Union(a, ActiveCell)
SendKeys "~{TAB}", -1
Set a = Union(a, ActiveCell)
SendKeys "+{TAB}+{TAB}", -1
Set a = Union(a, ActiveCell)
SendKeys "{TAB}", -1

Application.EnableEvents = True
Application.ScreenUpdating = True

Elegant alternatives are left to you for fun & enlightenment.


:)
FWIW I would not use Sendkeys in any product/etc. I just wouldn't rely
on it :)

Frank
 
H

hgrove

Norman Harker wrote...
...
But there are researchers out there plus other mass date entry
users who will benefit significantly from QDE *if* we've got it
right.
...

I believe you're confusing and conflating the ng posters who ask abou
simple date entry with the link I posted about a month ago to th
article about genetic researchers having certain genetic markers frie
upon import into Excel because some of those markers look like wha
Excel considers partial dates.

YOUR ADD-IN DOES **NOTHING** TO ADDRESS THE LATTER ISSUE.

For people who want to *PREVENT* Excel interpretting data tokens a
dates, there is NO ALTERNATIVE (wasn't that one of Margaret Thatcher'
favorite phrases?) to importing as text and specifying fields tha
should be formatted as text. Your add-in doesn't and can't do that. S
much for researchers.
You need to install. You need to master what we hope is a fairly
simple user interface for setting up or accepting defaults. Then
it's a reasonably fast process of activation and range setting
and you are off!
...

And spinning your wheels.

As I've pointed out in my 'technical' responses, neither event handle
does anything with partial date entries when users are entering date
into multiple cell selected ranges. That's the *most* *likely* usag
scenario for your add-in. So your add-in doesn't convert short dat
entries upon entry in that most likely situation. The user would hav
to reselect all date entry cells after entry in order to convert them
What's the advantage of doing that vs using a simple macro to conver
short date entries in batch?

You've got a problematic concept that can't be implemented real-tim
given the way Excel's event handlers actually work. What are th
benefits vs more traditional conversion methods (macros)?
. . . We certainly don't have the
time or resources that are needed to test in a multitude of
environments. I think that you are right though in indicating that
a beta indication was warranted pending operation under fire.
...

Not only the beta warning, you also need to state EXPLICITLY in whic
environments you've tested or in which you haven't
 
F

Frank Kabel

Hi Harlan
[...]
As I've pointed out in my 'technical' responses, neither event handler
does anything with partial date entries when users are entering dates
into multiple cell selected ranges. That's the *most* *likely* usage
scenario for your add-in. So your add-in doesn't convert short date
entries upon entry in that most likely situation. The user would have
to reselect all date entry cells after entry in order to convert them.
What's the advantage of doing that vs using a simple macro to convert
short date entries in batch?

and as answered this is IMHO more an Excel 97 bug :) This scenario
works without a problem in all other Excel versions. So we 'just' have
to workaround this Excel 97 behaviour.
And I agree with you that this is a very common scenario so we of
course have to solve it.

You've got a problematic concept that can't be implemented real-time
given the way Excel's event handlers actually work. What are the
benefits vs more traditional conversion methods (macros)?

I think this is a user decision. Benefit: Real time conversion without
a helper column. Drawback: usage of event handlers. And IMHO we can
implement it in real-time also for Excel 97 (and if not we will include
this as draweback of using the addin in Excel 97)

Frank
 
H

hgrove

Frank Kabel wrote...
...
of course we have tested it under Excel 97!!!!. No question
about this. My statement was just meant to be that this is
another issue with Excel 97 whcih is not documented, etc. We
have included several workarounds already for dealing with
Excel 97 but this one error you found just asn't catched by us.
Thats all. Also XL2K + XL2003 was tested
...

Last time I'll discuss this. Multiple cell selections are the mos
likely usage scenario, so it seems whoever did test this in XL97 didn'
test under this most likely usage scenario. I think you all need
testing checklist.
There're other reasons for using the Selection_Change event
handler. Most are releated to formating issues of the date entry
cell and preventing errors if you enter a short date with a
leading zero. In effect the selection change event handler does:
- change the format of the selected cell to text
- restores the old format afterwards
- checks for formulas, etc.

This only to allow an entry of for example 0311 in the cell. If you
wouldn't change the format prior to entry Excel will skip the '0'
and (depending on your chosen settings) this entry could get
interpretedt as 31-Jan-2004 and not as 3-Nov-2004. I agree
with you that this is a 'crude' workaround and I'd be happy if
there's a better solution (so if you have one I would be VERY
happy)

Have you considered formatting the QDE date entry range as Text whe
the worksheet is activated? Then leading zeros would be retained afte
entry.

This points out another conceptual problem. Dates from the early 1900
would evaluate to 3- or 4-digit numbers, but such dates shouldn't b
processed as short dates. As a practical matter, not an issue sinc
your add-in would most likely be used to enter recent dates. But wha
about 5-digit numbers? Would 21877 be treated as a short date to b
converted to 18-Feb-1977 or as the date serial for 23-Nov-1959? O
40109 as 1-Apr-2009 or 23-Oct-2009? How could QDE cope with date
actually entered as standard Excel dates that just happened t
correspond to date serial numbers that look like possible 5-digit shor
dates
 
F

Frank Kabel

[...]
Have you considered formatting the QDE date entry range as Text when
the worksheet is activated? Then leading zeros would be retained after
entry.

This was one alternative but we decided against it. This would prevent
formulas entered in the range and also could/would cause problems with
the processed date values (alignment, etc.). So just a design decision
with benefits and drawbacks

This points out another conceptual problem. Dates from the early 1900s
would evaluate to 3- or 4-digit numbers, but such dates shouldn't be
processed as short dates. As a practical matter, not an issue since
your add-in would most likely be used to enter recent dates. But what
about 5-digit numbers? Would 21877 be treated as a short date to be
converted to 18-Feb-1977 or as the date serial for 23-Nov-1959? Or
40109 as 1-Apr-2009 or 23-Oct-2009? How could QDE cope with dates
actually entered as standard Excel dates that just happened to
correspond to date serial numbers that look like possible 5-digit
short dates?

QDE would interprete this entry as a short date (so depending on your
settings: 18-Feb-1977 and 1-Apr-2009 respectively / for me: 21-Aug-1977
and 4-Jan-2009). All numbers entered are treated as 'short date
entries' and not as serial date values. This is another reason for
using the Selection_Change event - or to be more precise to change the
format to 'Text' before entering a value. This way Excel does not
convert the 5 digit entries to a date value (using the entry as serial
number).

Same applies to 3/4 digit entries which could represent the serial
value for an early 1900s date. Formating the cell as 'Text' is IMHO the
only way to prevent Excel's automatic conversion and omitting leading
zeros from the entry.

And a stated above: You could achieve something similar with formating
the entire range as 'Text' but then you have other drawbacks

Frank
 
H

hgrove

Frank Kabel wrote...
...
Nice procedure BTW BUT you mentioned the restrixtion: The
user has to enter in YYYY-MM-DD format. This is not very
common for most userss (though it would solve several issues).
Most of our code is not the parsing but dealing with different
formats

The user DOES NOT have to enter dates in yyyy-mm-dd format. The macr
does. The user would enter short dates as 1-, 2-, 3-, 4-, 6- or 8-digi
numbers, and the macro would rearrange the digits and insert dashes t
form ISO yyyy-mm-dd date strings and enter then into cells with Genera
number format. Since such ISO dates are always interpretted as date
when entered into cells with General number format, this seems to solv
the *macro* entry and formatting issue in one pass.

I'd already guessed that most of the QDE code is dealing with differen
formats and the GUI interface for user options overhead, and I'll repea
(with emphasis) that MOST INDIVIDUAL USERS NEED *ONE* *AND* *ONLY* *ONE
DATE FORMAT most of the time, and only occasionally need to switch t
alternative 2- or 3-digit short date entry treatment. Most users wil
*NEVER* switch between MDY, DMY or YMD entry order.

QDE is the logical opposite of a one-size-fits-all approach. It's a
all-sizes-included-even-though-you-need-only-one approach. It's lik
asking for a hammer and being handed a 20kg toolbox that includes
hammer and having to carry around the toolbox as you use the hammer.
Now you only have to define what 4 digits represent :)
YYMD
MMDD

Something QDE doesn't handle either. The variations are (for MDY entr
order)

MDYY
MDDY
MMDY
MMDD

QDE chokes on 7799, which should be 7-July-1999, even when a single QD
entry cell is selected. I'll admit my macro doesn't handle such entrie
either, but I hadn't meant it to do so. If I had, I'd have used
defined name to store my ambiguous entry resolution preferences as a
array of text like

{"MMDD","MDDY","MMDY","MDYY"}

then used them to convert 4-digit entries into ISO yyyy-mm-dd dat
strings and used the first one that resolved to a valid date.

Anyway, it should have been clear from my macro's code that anythin
with 4 or fewer digits is treated as month and day without year.
bypass 5 digit entries because they could be date serial numbers.
suppose I could have added 7 digit entries, but I just didn't see th
point.
And yes you're correct. The Format function works as expected
in other languages as well
...

So unless you're working around Gregorian vs Hijri, entering IS
yyyy-mm-dd date strings into cells formatted General will result in
date serial number using the system's default date format.

Speaking of Gregorian vs Hijri, I take it QDE won't be much if any us
for much of the Muslim world?
FWIW I would not use Sendkeys in any product/etc. I just
wouldn't rely on it :)

Why not? Bad experience using it?

Now that I've dug deeper, QDE also makes Registry entries under

HKEY_CURRENT_USER\Software\QDE

but using to Tools > Add-ins to unload it doesn't eliminate thes
Registry entries, so QDE leaves cruft in the Registry when uninstalled
Where's the mentioned in the documentation
 
F

Frank Kabel

[...]
Something QDE doesn't handle either. The variations are (for MDY entry
order)

MDYY
uncheck the option 'Automatically append current year..' and QDE would
interprete 7799 as 7-Jul-1999

MDDY
MMDY
correct as QDE requires at least a 2 digit year entry (or none at all)
It does. In this case you have to check the above mentioned option. BUT
of course you can't have both. Allow MDYY and MMDD at the same time.

QDE chokes on 7799, which should be 7-July-1999, even when a single
QDE entry cell is selected. I'll admit my macro doesn't handle such
entries either, but I hadn't meant it to do so. If I had, I'd have
used a defined name to store my ambiguous entry resolution
preferences as an array of text like

[...]
And yes you're correct. The Format function works as expected
in other languages as well
..

So unless you're working around Gregorian vs Hijri, entering ISO
yyyy-mm-dd date strings into cells formatted General will result in a
date serial number using the system's default date format.

Speaking of Gregorian vs Hijri, I take it QDE won't be much if any use
for much of the Muslim world?

lol. And i have to admit we haven't tested QDE with arabic Excel
versions ;-)

Why not? Bad experience using it?

Yes, indeed. I would use it for my personal use but not in macros I
give away.


Now that I've dug deeper, QDE also makes Registry entries under

HKEY_CURRENT_USER\Software\QDE

but using to Tools > Add-ins to unload it doesn't eliminate these
Registry entries, so QDE leaves cruft in the Registry when
uninstalled. Where's the mentioned in the documentation?

Will check that.

Frank
 
H

hgrove

Frank Kabel wrote...
This was one alternative but we decided against it. This would
prevent formulas entered in the range and also could/would
cause problems with the processed date values (alignment,
etc.). So just a design decision with benefits and drawbacks

Several problems with your rationale.

1. Formulas. You're already processing entered cells. It's simple t
check if the first character in the cell is =, and if so reformat th
cell as General (or clear the cell's format to return it to th
worksheet default) then set the cell's .Formula property equal to it'
.Value property. If the user wants to enter a text constant beginnin
with =, oblige them to enter an initial apostrophe (as they'd need t
without QDE), and process cells with initial apostrophes the same way
as those beginning with =. Heck, you could use the same code for bot
situations.

If c.Formula Like "['=]*" Then
c.ClearFormats
c.Formula = c.Value
End If

2. Alignment. Cells formatted as Text would be left-aligned by default
When the user makes an entry, if the entry could be converted into
date, what prevents you from changing the cell's format as well as it
contents? If you change the cell's format to anything numeric the
change its contents to something Excel will interpret as a date, th
resulting date should be aligned the same way any other numeric entr
would be aligned under the workbook's Normal style, no?

I can't believe you guys really thought this through.
QDE would interprete this entry as a short date (so depending
on your settings: 18-Feb-1977 and 1-Apr-2009 respectively / for
me: 21-Aug-1977 and 4-Jan-2009). All numbers entered are
treated as 'short date entries' and not as serial date values.
This is another reason for using the Selection_Change event -
or to be more precise to change the format to 'Text' before
entering a value. This way Excel does not convert the 5 digit
entries to a date value (using the entry as serial number).
...

In other words, QDE would mung up (jargon for fubar) standard Exce
date entries. This would be another advantage of having QDE proces
only cells initially formatted as Text and not use SelectionChang
event handlers to change formats. When a cell has been processed, it'
going to be in a date format presumably, so subsequent entries when th
format hasn't changed could be standard Excel date entries, and wouldn'
be reprocessed by QDE. To allow users to change entries, you could ad
another hotkey (E) that would store the cell's .Text property, reforma
it as Text, then enter the stored .Text property as its .Valu
property.
And a stated above: You could achieve something similar with
formating the entire range as 'Text' but then you have other
drawbacks

I believe you've overestimated the drawbacks
 
F

Frank Kabel

[....]
In other words, QDE would mung up (jargon for fubar) standard Excel
date entries. This would be another advantage of having QDE process
only cells initially formatted as Text and not use SelectionChange
event handlers to change formats. When a cell has been processed, it's
going to be in a date format presumably, so subsequent entries when
the format hasn't changed could be standard Excel date entries, and
wouldn't be reprocessed by QDE. To allow users to change entries, you
could add another hotkey (E) that would store the cell's .Text
property, reformat it as Text, then enter the stored .Text property
as its .Value property.

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 believe you've overestimated the drawbacks.

Hi Harlan
o.k. the benefit would be using only one event handler and I agree with
you that this approach is also feasible and nearly as easy/complicated
as our chosen one. Not sure if we had overestimated the drawbacks but
you know at some points during the design you have to make some
decisions. We made one and were able to achieve our goal (meet our
requirements).
BUT your approach is something to reconsider if we decide to make a new
major release (and changing the existing handling). This will also
depend on the user feedback and maybe their additional requirements.

Frank
 
H

hgrove

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 i
this case there's the issue about what would cause the least harm
That'd have to be determined empirically.


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

d
dd
md
mdd
mmd
mdy
mmdd
mddy
mdyy
mmdy
mmddyy
mmddyyyy

You'd probably want to use

d
dd
dm
ddm
dmm
dmy
ddmm
ddmy
dmyy
dmmy
ddmmyy
ddmmyyyy

Name this range something long & complicated like

DateEntryAmbiguityResolution

(or define it with a constant array), and you could use a batc
conversion macro like the following.



Code
-------------------

Sub csd()
Dim f0 As String, f1 As String
Dim i As Long, j As Long, n As Long
Dim ymd(1 To 3) As String, cm As String, cy As String
Dim c As Range, dear As Variant, v As Variant

If Not TypeOf Selection Is Range Then Exit Sub

dear = Evaluate("DateEntryAmbiguityResolution")
cm = Format(Now, "mm")
cy = Format(Now, "yyyy")

For Each c In Selection.Cells
If Not (c.HasFormula Or VarType(c.Value) = vbDate _
Or c.Text Like "*[!0-9 ]*") Then

f0 = Application.Substitute(c.Text, " ", "")
n = Len(f0)
f1 = ""

For Each v In dear
ymd(1) = ""
ymd(2) = ""
ymd(3) = ""

If Len(v) = n Then
For i = 1 To n
j = InStr(1, "ymd", Mid(v, i, 1))
ymd(j) = ymd(j) & Mid(f0, i, 1)
Next i

If ymd(1) = "" Then ymd(1) = cy

i = CLng(ymd(1))
If i < 30 Then ymd(1) = Format(2000 + i, "0000")
If i < 1900 Then ymd(1) = Format(1900 + i, "0000")

If ymd(2) = "" Then ymd(2) = cm

f1 = ymd(1) & "-" & ymd(2) & "-" & ymd(3)

If IsNumeric(Evaluate("--""" & f1 & """")) Then Exit For

f1 = ""

End If

Next v

If f1 <> "" Then
c.NumberFormat = "General"
c.Formula = f1
End If

End If

Next c

End Sub

-------------------



This isn't internationalized, but it could be by replacing the "ymd
string constant with a variable. That variable would be set by locatin
a blank cell, changing it's .NumberFormat property to "ymd" and storin
its .NumberFormatLocal property in this new variable (then restorin
its original format). If I'm right about this, this macro and define
name combination provides the equivalent functionality of your entir
add-in. Actually, it'd provide more because it could handle singl
digit dates, 4-digit dates like 7799, 9977 and 1234, and bypass 5- an
7-digit numbers.

I still don't see why this requires a +500KB add-in. The cor
functionality just ain't that complicated
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top