H
Harlan Grove
A couple of MSFT employees have set up a public wishlist for Office at
http://makeofficebetter.com/
One idea I posted was that Excel should allow multiple open files with
the same base filename in the same session. For example, Word allows
you to open C:\x\a.docx and C:\y\a.docx in the same session, but Excel
doesn't allow you to open C:\x\b.xlsx and C:\y\b.xlsx in the same
session.
This has always been so in Excel. The original version of Excel could
only run on 512K Macs (in 1985), and those machines had only one
floppy disk drive, and the Mac file system at the time didn't support
directories. That means that there could only be one file open with a
given filename at any time. Excel's developers unfortunately made this
a principle design element, so they've never fixed this.
It would be difficult to fix this now. In terms of worksheet formulas,
it'd mean either using full pathnames, adding support for partial/
relative pathnames (which Lotus 1-2-3 provided in Release 3.0 in 1989,
just for comparison and to show that this IS possible and
unambiguous), or using an IE-like convention of adding extraneous
qualifiers to subsequent filenames (e.g., open C:\x\b.xlsx first and
it appears as b.xlsx; open C:\y\b.xlsx second and it appears as b.xlsx
(1); open C:\z\b.xlsx third and it appears as b.xlsx(2); etc. along
with the convention that b.xlsx(0) would be an alias for b.xlsx). The
last would be the least pleasant, but it WOULDN'T break existing code.
Additional syntax would be needed for files with perverse filenames
ending with parenthesized numbers. Alternatively, the syntax could be
b.xlsx::2 rather than b.xlsx(2) [two colons necessary for the Excel
OM's Windows collection to be able to distinguish multiple same base
filenames from multiple window names into the same file].
The Excel OM would have to support the same convention for using
filenames as indices into the Workbooks collection and as literal
workbook object references like [b.xlsx(2)] or [b.xlsx::2]. An obvious
extension of the Excel OM would be allowing workbook FULLNAME
properties to be used in addition to their Name and Index properties
when dereferencing particular members of the Workbooks collection.
And it'd be REALLY NICE if VBA would FINALLY include a pragma for
application version in addition to the VBA version in order to allow
for more obvious conditional compilation, e.g.,
#If EXCEL14 Then
do Excel 14 and later stuff
#ELSE
do Excel 12 and prior stuff
#END IF
EXCEL14 would be defined automatically in Office 2010 and undefined in
prior versions, so no compatibility issues.
http://makeofficebetter.com/
One idea I posted was that Excel should allow multiple open files with
the same base filename in the same session. For example, Word allows
you to open C:\x\a.docx and C:\y\a.docx in the same session, but Excel
doesn't allow you to open C:\x\b.xlsx and C:\y\b.xlsx in the same
session.
This has always been so in Excel. The original version of Excel could
only run on 512K Macs (in 1985), and those machines had only one
floppy disk drive, and the Mac file system at the time didn't support
directories. That means that there could only be one file open with a
given filename at any time. Excel's developers unfortunately made this
a principle design element, so they've never fixed this.
It would be difficult to fix this now. In terms of worksheet formulas,
it'd mean either using full pathnames, adding support for partial/
relative pathnames (which Lotus 1-2-3 provided in Release 3.0 in 1989,
just for comparison and to show that this IS possible and
unambiguous), or using an IE-like convention of adding extraneous
qualifiers to subsequent filenames (e.g., open C:\x\b.xlsx first and
it appears as b.xlsx; open C:\y\b.xlsx second and it appears as b.xlsx
(1); open C:\z\b.xlsx third and it appears as b.xlsx(2); etc. along
with the convention that b.xlsx(0) would be an alias for b.xlsx). The
last would be the least pleasant, but it WOULDN'T break existing code.
Additional syntax would be needed for files with perverse filenames
ending with parenthesized numbers. Alternatively, the syntax could be
b.xlsx::2 rather than b.xlsx(2) [two colons necessary for the Excel
OM's Windows collection to be able to distinguish multiple same base
filenames from multiple window names into the same file].
The Excel OM would have to support the same convention for using
filenames as indices into the Workbooks collection and as literal
workbook object references like [b.xlsx(2)] or [b.xlsx::2]. An obvious
extension of the Excel OM would be allowing workbook FULLNAME
properties to be used in addition to their Name and Index properties
when dereferencing particular members of the Workbooks collection.
And it'd be REALLY NICE if VBA would FINALLY include a pragma for
application version in addition to the VBA version in order to allow
for more obvious conditional compilation, e.g.,
#If EXCEL14 Then
do Excel 14 and later stuff
#ELSE
do Excel 12 and prior stuff
#END IF
EXCEL14 would be defined automatically in Office 2010 and undefined in
prior versions, so no compatibility issues.