Office 2004 for Mac

[Howard Kaikow]

I could not find much at Mactopia.

Has MSFT stated what will be the degree of compatibility between Mac Office
2004 and the various versions of VBA in Windoze Office 2000 and up?

In particular, will Mac Office 2004 VBA be fully compliant, other than
system specific object model differences, with VBA in Office 2000, Office XP
and/or Office 2003?

 

[JE McGimpsey]

I could not find much at Mactopia.

Has MSFT stated what will be the degree of compatibility between Mac Office
2004 and the various versions of VBA in Windoze Office 2000 and up?

In particular, will Mac Office 2004 VBA be fully compliant, other than
system specific object model differences, with VBA in Office 2000, Office XP
and/or Office 2003?

To the best of my knowledge, there hasn't been any announcement about
VBA, but I wouldn't hold my breath. While it would be nice, I can't see
any reason for MacBU to invest any resources in it except for (I hope)
bug fixes, and object model changes.

VBA is essentially a dead language walking. VBA development on the
Windows side has been essentially stopped. Everything MS is doing in the
application-integration area is focused on .Net. That doesn't mean that
VBA won't be used by developers for years to come (just like XL4 Macros
and WordBasic), but I suspect by WinOffice12, or at the latest 13, VBA
will be supported for legacy reasons, not as the primary development
platform.

Given the product cycle times, I would hope that, to the extent it can,
MacBU's efforts are looking toward whatever WinOffice is migrating to.
It's so far behind VBA6.x now that trying to catch up will put
MacOffice12/13 even farther behind its WinOffice counterpart. If I were
in charge, I'd give it up as a bad job, and try to leapfrog to the "next
thing".

Most people I know developing VBA applications on the Mac use VBA5
routines to simulate VBA6 commands where possible, using conditional
compilation or dedicated add-ins to make their applications
cross-platform compatible. That's probably still a viable strategy for
another year or two. An alternative, or perhaps concurrent strategy,
would be to beef up Applescriptability, which is a very attractive
option for Mac-only development.

Those are just my opinions, of course. If I had my druthers, a whole
boatload of money would be spent by MacBU on bringing a limited ActiveX
to the Mac (since it's open source, now, that could be done by others),
and concurrently, bring MacOffice automation to parity with WinOffice.
Since I don't have a boatload of money, and Microsoft's shareholders
probably don't want to reduce their return by spending a boatload of
money on MacOffice, that's not an option.

 

[Phillip M. Jones, C.E.T.]

To the best of my knowledge, there hasn't been any announcement about
VBA, but I wouldn't hold my breath. While it would be nice, I can't see
any reason for MacBU to invest any resources in it except for (I hope)
bug fixes, and object model changes.

VBA is essentially a dead language walking. VBA development on the
Windows side has been essentially stopped. Everything MS is doing in the
application-integration area is focused on .Net. That doesn't mean that
VBA won't be used by developers for years to come (just like XL4 Macros
and WordBasic), but I suspect by WinOffice12, or at the latest 13, VBA
will be supported for legacy reasons, not as the primary development
platform.

Given the product cycle times, I would hope that, to the extent it can,
MacBU's efforts are looking toward whatever WinOffice is migrating to.
It's so far behind VBA6.x now that trying to catch up will put
MacOffice12/13 even farther behind its WinOffice counterpart. If I were
in charge, I'd give it up as a bad job, and try to leapfrog to the "next
thing".

Most people I know developing VBA applications on the Mac use VBA5
routines to simulate VBA6 commands where possible, using conditional
compilation or dedicated add-ins to make their applications
cross-platform compatible. That's probably still a viable strategy for
another year or two. An alternative, or perhaps concurrent strategy,
would be to beef up Applescriptability, which is a very attractive
option for Mac-only development.

Those are just my opinions, of course. If I had my druthers, a whole
boatload of money would be spent by MacBU on bringing a limited ActiveX
to the Mac (since it's open source, now, that could be done by others),
and concurrently, bring MacOffice automation to parity with WinOffice.
Since I don't have a boatload of money, and Microsoft's shareholders
probably don't want to reduce their return by spending a boatload of
money on MacOffice, that's not an option.

NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!
Active -X must never, ever, ever be ported to Mac. It is the most dangerous
lanaguage ever designed for computers. If one has the direct knowledge now
in PC's Active-X can be used to seriptiously reintialize your hard drive
without your knowledge. It can be a method used to send viruses, worm, and
Trogan Horses without your knowldege. Or to burrow in into your system and
highjack it so they can use your computer to spread spam. To this day in IE
I won't even turn on Active-X starting from IE 3 to the latest OSX version.
Active-X as MS implements is far more dangerous than Java was when it first
hit the market 10 years ago. The programers for Java waere quick to remove
or disable any distructive code. Active-X code is basically unchanged from
the day MS brought it to the Market.

Mozilla is toying with a deriviate of Active-X, but are being careful not to
implement any of the dangerous components and commands, but even that is
receiving a very cool reception in the open source community. Even for PC
and Unix versions.

While you can say, Macs are not vunerable to PC vageries.With OSX we simply
do not know that much of the comand line stuff in Dos and windows looks
much like unix.Who are we to know, what active-x is capable of in UNIX.

Personally I believe Active_x is so dangerous it should be banned from use
in all forms.
--
---------------------------------------------------------------------------
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112-1809 |[email protected], ICQ11269732, AIM pjonescet
---------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://home.kimbanet.com/~pjones/birthday/index.htm>
<http://vpea.exis.net>

 

[JE McGimpsey]

NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!NO!
Active -X must never, ever, ever be ported to Mac. It is the most dangerous
lanaguage ever designed for computers.

I think that's a fair bit of hyperbole, don't you? First of all, ActiveX
isn't a "language", and even if it were, there's no way any language
could be "more dangerous" than assembler, or even C... Instead, ActiveX
is more like a set of rules that determine how applications interact.
The problem with ActiveX historically has been the way it interacts with
and gains permissions from the operating system. In that, it has been a
very dangerous technology, largely because its lack of limitations
weren't well understood.

Mozilla is toying with a deriviate of Active-X, but are being careful not to
implement any of the dangerous components and commands, but even that is
receiving a very cool reception in the open source community. Even for PC
and Unix versions.

That's why I used the phrase "limited ActiveX". If something akin to
ActiveX were able to duplicate the behavior within Office apps of the
control toolbox controls, there would be a tremendous amount of code
that would then run in MacOffice that doesn't now. That wouldn't take
any of the elements that make ActiveX controls dangerous.

Most PC ActiveX controls used in Office in the wild are simply buttons,
textboxes or comboboxes, much like the ones in Userforms. They're hardly
dangerous - they can't be hijacked to take over your computer, or do
other nasty stuff. They can, however, use events, be formatted, be
resized, etc.

While you can say, Macs are not vunerable to PC vageries.With OSX we simply
do not know that much of the comand line stuff in Dos and windows looks
much like unix.Who are we to know, what active-x is capable of in UNIX.

Presumably, with the code being open source, "we" can determine the
danger, just as "we" determine the danger of any other open source code.
There's nothing *magic* about "ActiveX". It's a technology that has been
misused, and the key is to make sure that that misuse is not allowed in
the future. I'm much more confident of open source code than I am of
closed source code, and I rely on the community to police itself (and
contribute when I can).

Personally I believe Active_x is so dangerous it should be banned from use
in all forms.

It doesn't sound like you have a good technical basis for that opinion.

 

[Howard Kaikow]

I do not believe that it would be that difficult to upgrade MAC VBA 5 to
something very close to windoze Office VBA 6.*.
But such decisions are not always made logically.

Of course, if MSFT is going to truly .NET-ize windoze Office, I'd sure like
them to also, NET-ize MAC Office, but that involves getting the .NET
Framework running on the MAC, a fairly expensive task.

Oh well, we can wait and see, I'll start counting

1 Tallahassee
2 Tallahassee

 

[Howard Kaikow]

One does not have to port ActiveX to upgrade Mac VBA.

However, for platform independence, Mac and windoze Office must support the
same level of macro programming language.
The OS specifics can differ, the Office model/VBA stuff needs to be
identical.

 

[JE McGimpsey]

One does not have to port ActiveX to upgrade Mac VBA.

However, for platform independence, Mac and windoze Office must support the
same level of macro programming language.
The OS specifics can differ, the Office model/VBA stuff needs to be
identical.

One doesn't need VBA6 to be platform independent (if, by platform, one
means Win/Mac), as long as the application code doesn't use VBA6
specific features - much like writing code that works in WinOffice97-03.

Until controls that have the same programmability and scope as the
ActiveX controls in the Controls Toolbox, there will be no *platform*
independence.

 

[Howard Kaikow]

I should have said latform independent, without needless restrictions, in
the latest version of Office for each system:

 

[Phillip M. Jones, C.E.T.]

Wasn't commenting to VBA, only to Active-X

One does not have to port ActiveX to upgrade Mac VBA.

However, for platform independence, Mac and windoze Office must support the
same level of macro programming language.
The OS specifics can differ, the Office model/VBA stuff needs to be
identical.

--
---------------------------------------------------------------------------
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112-1809 |[email protected], ICQ11269732, AIM pjonescet
---------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://home.kimbanet.com/~pjones/birthday/index.htm>
<http://vpea.exis.net>

 

[John McGhie [MVP - Word]]

Howard:

My comments would precisely mirror J.E.'s.

I suggest that your safest option would be to expect no change at all in VBA
support in the next version of Office on the Mac.

Cheers

I should have said latform independent, without needless restrictions, in
the latest version of Office for each system:

--

Please respond only to the newsgroup to preserve the thread.

John McGhie, Consultant Technical Writer,
McGhie Information Engineering Pty Ltd
Sydney, Australia. GMT + 10 Hrs
+61 4 1209 1410, mailto:[email protected]