Big Bug in Excel Applescript?

[CRP]

Version: 2008 Operating System: Mac OS X 10.6 (Snow Leopard) Processor: Intel Hi,
could you please try the following applescript on your Excel 2008 for Mac?

tell application "Microsoft Excel"
        select range "A1:C3"
        get address of rows of selection
        select range "B13"
        get address of rows of selection
end tell

I get the following result:
tell application "Microsoft Excel"
select range "A1:C3"
get address every row of selection
--> {"$A$1:$C$1", "$A$2:$C$2", "$A$3:$C$3"}
select range "B13"
get address every row of selection
--> {"$C$1:$E$1", "$C$2:$E$2", "$C$3:$E$3"}
end tell

Basically, the rows() class screws up if the range object it refers to does not start in the first column.

Thanks
Chris

 

[XinXin]

Hi Chris, thanks for reporting it. We are investigating...

Thanks,
XinXin Liu
Test Lead, Macintosh Business Unit, Microsoft

 

[CRP]

Thanks for looking into this.
What is interesting is that the "get address" command fails only on the rows object, not on the columns object. See here:

tell application "Microsoft Excel"
        select range "B24"
        get every row of selection
                --> {row "$B$2:$D$2" of selection, row "$B$3:$D$3" of selection, row "$B$4:$D$4" of selection}
        get address {row "$B$2:$D$2" of selection, row "$B$3:$D$3" of selection, row "$B$4:$D$4" of selection}
                --> {"$C$3:$E$3", "$C$4:$E$4", "$C$5:$E$5"}
        get every column of selection
                --> {column "$B$2:$B$4", column "$C$2:$C$4", column "$D$2:$D$4"}
        get address {column "$B$2:$B$4", column "$C$2:$C$4", column "$D$2:$D$4"}
                --> {"$B$2:$B$4", "$C$2:$C$4", "$D$2:$D$4"}
end tell

 

[CRP]

Hi XinXin, have you had a chance to look at this bug?

 

[XinXin]

Given that we have higher prioirty bugs, it's likely we won't be shipping the update to fix this bug for XL2008. But we are considering the possibility of fixing this bug in MacXL2011.

Thanks,
XinXin Liu
Test Lead, Macintosh Business Unit, Microsoft

 

[CRP]

Well, I will not hide my disappointment. I have just bought five Office 2008 for Mac licenses, and just started to translate *a lot* of macros from vba to applescript, only to find out that I will need a (paid) upgrade to get them to work...

 

[John McGhie]

Slow down there, Pardner He did NOT say "We will fix this in Excel
2011".

What he said was "This is on the list of bugs for 'consideration' in Office
2011". He won't know until he sees the completed specification for 2011
whether it made it or not...

If this bug does not score enough "points" to get fixed in Office 2008, it
is quite likely that it won't score enough points to get fixed in Office
2011 either.

We have to accept that, like politics, software development is a
majority-wins sport. Mass-market software such as Microsoft Office adheres
rigidly to the rule of the ballot box, or it fails in the marketplace and
goes out of business. There are bugs in Office that have been there for 20
years: they will never gather enough support to be worth the time and cost
of fixing them.

There are two things working in our favour:

1) A large part of the "cost" of fixing a bug is the cost of "testing" to
ensure the fix does not break all the installed copies currently out there.
XinXin awakes in fright at the thought of this: he's in charge of testing
Excel

Some of that cost goes away in a "New Version". With a new Version, the
Software Licence specifies "This is new and different. We make no comment
about whether this will break anything in your system or not: it is your
responsibility to test for that, before putting the software into use." Of
course, it doesn't say it quite so plainly, but that's what it means

So the chances of getting a bug fixed in the next version are roughly double
the chances of getting it fixed in the current version, because the cost of
testing is roughly half.

That still doesn't mean you'll make it over the bar! If you need 51 points
to get onto the development schedule, and you currently have 10, by halving
the testing cost you now have 20 points: you are still not going to make it.
Of course, if your bug already had 49 points, you're on your way to
Washington

2) In each new version, slabs of the code get replaced with improved
versions. In the case of Office 2011, these slabs are very large lumps of
the program.

Chances are, the bit of the program that caused this bug will no longer be
there in Office 2011. I can't tell you whether that is true for this bug or
not (and neither can XinXin: neither of us know). In fact, the software
development engineer actually doing the work couldn't tell us off the top of
her head: she would have to open the code and look. Which would take her
about a week. A week when could could be doing something useful, like
making a better program.

So we'll have to wait.

I suggest to you that we have reason to be very hopeful about Office 2011.
But I further suggest to you that we need to ensure we carefully test the
next version before we put it into production: there is a lot of change, and
there WILL be some breakages. I can guarantee you that

If I were to make a suggestion to you, I would suggest that you DON'T port
any more macros to AppleScript. Microsoft has announced that Office 2011
will have a full version of VBA back in, and it's due to hit the shelves at
the end of this year. Your old macros will then burst back into life.

Hope this helps

Well, I will not hide my disappointment. I have just bought five Office 2008
for Mac licenses, and just started to translate *a lot* of macros from vba to
applescript, only to find out that I will need a (paid) upgrade to get them to
work...

--

The email below is my business email -- Please do not email me about forum
matters unless I ask you to; or unless you intend to pay!

John McGhie, Microsoft MVP (Word, Mac Word), Consultant Technical Writer,
McGhie Information Engineering Pty Ltd
Sydney, Australia. | Ph: +61 (0)4 1209 1410 | mailto:[email protected]