VBA to return in the next version of Office Mac !?

[Mitrokhin]

Perhaps this is old hat to some but I havn't seen it mentioned in here.

cp.
http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.msp
x?rss_fdn=Press%20Releases

I wonder if it's worthwhile to rewrite VBA macros in Applescript,
(which btw I have been doing for the last couple of days ).

[first Wordbasic then VBA then Applescript then perhaps VBA 2 then ?
sigh]


----
VBA Returns to Future Versions of Office for Mac The Mac BU also
announced it is bringing VBA-language support back to the next version
of Office for Mac. Sharing information with customers as early as
possible continues to be a priority for the Mac BU to allow customers to
plan for their software needs.2 Although the Mac BU increased support in
Office 2008 with alternate scripting tools such as Automator and
AppleScript ‹ and also worked with MacTech Magazine to create a
reference guide, available at
http://www.mactech.com/vba-transition-guide ‹ the team recognizes that
VBA-language support is important to a select group of customers who
rely on sharing macros across platforms. The Mac BU is always working to
meet customers¹ needs and already is hard at work on the next version of
Office for Mac.

 

[Daiya Mitchell]

More info here:
http://www.schwieb.com/blog/2008/05/13/saying-hello-again-to-visual-basic/

Whether it's worth rewriting macros or not depends on you and what you
need them for.

Note that "next version" means next purchased upgrade, *not* an update
to Office 2008.

 

[Corentin Cras-Méneur]

Note that "next version" means next purchased upgrade, *not* an update
to Office 2008.

Which means 2010, 2011......

Corentin

 

[Phillip Jones]

Which means 2010, 2011......

Corentin

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

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

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://www.kimbanet.com/~pjones/90th_Birthday/index.htm>
<http://www.kimbanet.com/~pjones/Fulcher/default.html>
<http://www.kimbanet.com/~pjones/Harris/default.htm>
<http://www.kimbanet.com/~pjones/Jones/default.htm>

<http://www.vpea.org>

 

[Corentin Cras-Méneur]

or 2013... 2014.... ;-)

I thought MS had announced a shorted development cycle??


Corentin

 

[Jim Gordon MVP]

or 2013... 2014.... ;-)

Hi Phil,

Microsoft has targeted 2 year cycles for Office and Windows for many
years. But the future is always a moving target. By those standards
Vista was more than 4 years late.

I think the most realistic way to phrase it is that a timetable will be
developed internally based on guesstimates as to how long it will take
to build a new VBA compiler.

Combine that with any new features that might be being planned for the
next version and however long those will take and hopefully you'll
realize that coming up with any sort of a firm date is nearly impossible.

Plan, build, test, deploy. Each of those steps takes an indeterminate
amount of time. Deciding when software is "done" is akin to deciding
when a cake is done. When it smells good and tastes good it's ready.

-Jim

--
Jim Gordon
Mac MVP

MVPs are independent experts who are not affiliated with Microsoft.


Visit my blog
http://blog.360.yahoo.com/blog-i7JMeio7cqvhotIUwCzaJWq9

 

[Phillip Jones, CET]

I thought MS had announced a shorted development cycle??


Corentin

That's funny, they have admitted shorting out the development cycle. ;-)

--
------------------------------------------------------------------------
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 |[email protected], ICQ11269732, AIM pjonescet
------------------------------------------------------------------------

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

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://www.kimbanet.com/~pjones/90th_Birthday/index.htm>
<http://www.kimbanet.com/~pjones/Fulcher/default.html>
<http://www.kimbanet.com/~pjones/Harris/default.htm>
<http://www.kimbanet.com/~pjones/Jones/default.htm>

<http://www.vpea.org>

 

[John McGhie]

Hi Mitrokhin:

Perhaps this is old hat to some but I havn't seen it mentioned in here.

The decision was made about two months ago. Some of us have been under a
non-disclosure agreement that has prevented us talking about it until the
Microsoft announcement appeared.

I wonder if it's worthwhile to rewrite VBA macros in Applescript,
(which btw I have been doing for the last couple of days ).

Yes, I think so.

VBA is very good for automation "within" an Application. It begins to have
problems across applications, and cannot automate non-Microsoft Applications
at all.

AppleScript's strength is that it can automate ANYTHING on a Macintosh.
Because the AppleScript compiler/runtime runs outside the application, it is
extremely good at coordinating the efforts of multiple applications.

AppleScript begins to struggle WITHIN an Application, depending on how
richly-implemented the AppleScript Dictionary is.

Because the AppleScript dictionaries in Microsoft Office are simply a
re-expression of the VBA Object Model, and because Microsoft Office's core
applications were designed from the get-go to be automated, AppleScript
provides the ability to automate almost every dot and comma in a Microsoft
Office application.

So now, solution vendors get the ability to choose between two automation
technologies. AppleScript will be the winner when the task involves
automating non-Microsoft applications. VBA will be the winner when the task
benefits from having common code with the PC version.

[first Wordbasic then VBA then Applescript then perhaps VBA 2 then ?
sigh]

The one we REALLY want is "dot-Net". Dot-Net is very difficult to do on the
Mac, although there are efforts to get it working beginning to appear.
Microsoft's original plans for dot-Net included making it available on
platforms other than Win-Tel.

On a personal note, I am "hoping" (and that's all it is, a "hope") that "VBA
2" will take us closer to .Net. By the way, I am also hoping that what we
get will be "VBA 7" (the PC Office 2007 version). What we have in Office
2004 is two levels behind that, and the differences are becoming annoying.

Hope this helps
--

Don't wait for your answer, click here: http://www.word.mvps.org/

Please reply in the group. Please do NOT email me unless I ask you to.

John McGhie, Microsoft MVP, Word and Word:Mac
Nhulunbuy, NT, Australia. mailto:[email protected]

 

[Mitrokhin]

i microsoft.public.mac.office.word skrev John McGhie
Sun, 18 May 2008 08:33:36 +0930 (-), i en artikel med
ID <C4559A60.15117%[email protected]>
og titlen "Re: VBA to return in the next version of Office Mac !?",
følgende:


: Hi Mitrokhin:
:

Hi there

: On 16/05/08 5:38 PM, in article
: 160520081008452444%[email protected], "Mitrokhin"
:
: > Perhaps this is old hat to some but I havn't seen it mentioned in here.
:
: The decision was made about two months ago. Some of us have been under a
: non-disclosure agreement that has prevented us talking about it until the
: Microsoft announcement appeared.
:

Yes I gathered as much after reading the link provided earlier in this
thread ... can't say that I regret the rewriting (which it still in
progress) now though, because for one thing Word 2008 is so much
nicer to work in than the earlier version, so I would have had to make
the transition - rewriting and all - at some point anyway.

Btw I'm not a professional by a long shot. My "programming" (consisting
mostly of gathering bits and pieces here and there and adding a little
of my own code) is only for my personal non-business use.


: > I wonder if it's worthwhile to rewrite VBA macros in Applescript,
: > (which btw I have been doing for the last couple of days ).
:
: Yes, I think so.
:
: VBA is very good for automation "within" an Application. It begins to have
: problems across applications, and cannot automate non-Microsoft Applications
: at all.
:
: AppleScript's strength is that it can automate ANYTHING on a Macintosh.
: Because the AppleScript compiler/runtime runs outside the application, it is
: extremely good at coordinating the efforts of multiple applications.
:
: AppleScript begins to struggle WITHIN an Application, depending on how
: richly-implemented the AppleScript Dictionary is.
:
: Because the AppleScript dictionaries in Microsoft Office are simply a
: re-expression of the VBA Object Model, and because Microsoft Office's core
: applications were designed from the get-go to be automated, AppleScript
: provides the ability to automate almost every dot and comma in a Microsoft
: Office application.
:

Indeed, Applescript seems to be very well integrated. I've also found
that in most cases the rewriting wasn't as hard as I expected (guees it
helped having the MacTech guide close at hand too , but alas there're
a couple of macros I just can't convert (more due to my own lack of
skills than anything else)

: So now, solution vendors get the ability to choose between two automation
: technologies. AppleScript will be the winner when the task involves
: automating non-Microsoft applications. VBA will be the winner when the task
: benefits from having common code with the PC version.
:
: > [first Wordbasic then VBA then Applescript then perhaps VBA 2 then ?
: > sigh]
:
: The one we REALLY want is "dot-Net". Dot-Net is very difficult to do on the
: Mac, although there are efforts to get it working beginning to appear.
: Microsoft's original plans for dot-Net included making it available on
: platforms other than Win-Tel.
:
: On a personal note, I am "hoping" (and that's all it is, a "hope") that "VBA
: 2" will take us closer to .Net. By the way, I am also hoping that what we
: get will be "VBA 7" (the PC Office 2007 version). What we have in Office
: 2004 is two levels behind that, and the differences are becoming annoying.
:

My view on this is colored by the fact stated above. I'm not a
professional in contrast to yourself - and I have no idea what a
dot-netification of Mac Office would entail precisely, a part from the
almost guarenteed (?) nescessity of another rewriting of macros on
my part , since as I've hinted at I have a couple of usefull macros
that I just can't convert to AS, which means that they would have to
be converted to the new VBA variety, so I would be perfectly happy
with the old VBA version. *Still* a re-adding of VBA (be that a
completely new version or not) is of course a good thing and can't
help making Mac Office even better than it is today. Also this "VBA to
VBA 2" conversion is a couple of years off too.

May I ask what features of "VBA 7" you miss. Ie. I've found that one
feature that's often lamented is the lack of good Userform support
but I've found that WordBasic.BeginDialog/EndDialog constructs
works really well and looks great in Word 2004 (you can even use
the old Word 6 dialog tool if you have access to a wintel computer).


: Hope this helps
: --
:
: Don't wait for your answer, click here: http://www.word.mvps.org/
:
: Please reply in the group. Please do NOT email me unless I ask you to.
:
: John McGhie, Microsoft MVP, Word and Word:Mac
: Nhulunbuy, NT, Australia. mailto:[email protected]
:

 

[Daiya Mitchell]

Hi Mitrokhin,

Indeed, Applescript seems to be very well integrated. I've also found
that in most cases the rewriting wasn't as hard as I expected (guees it
helped having the MacTech guide close at hand too , but alas there're
a couple of macros I just can't convert (more due to my own lack of
skills than anything else)

If you have any macro replacement scripts you think would be useful for
other people, I'd love to link them from here. Have you put them on
Scriptbuilders.net or anything, perhaps?
http://word.mvps.org/Mac/scripts/

Daiya

 

[John McGhie]

Hi Mitrokhin:

Btw I'm not a professional by a long shot. My "programming" (consisting
mostly of gathering bits and pieces here and there and adding a little
of my own code) is only for my personal non-business use.

I wouldn't call myself a "professional" either, and if you saw my code, you
would know why. But I do sell it

My view on this is colored by the fact stated above. I'm not a
professional in contrast to yourself - and I have no idea what a
dot-netification of Mac Office would entail precisely,

In essence, .Net is very similar to Java, but has the benefit of the
learnings from the progress made in developing Java. In action, it looks a
little bit like the Classic environment on the Mac: you get a "run time
platform" that is treated as being part of the operating system.

It gives you the speed advantages of being part of the operating system, and
the security advantages of being fenced off by the operating system.

A major issue with VBA is security. By DESIGN, VBA is not secure -- can
never be secure, because it is designed to allow things such as file
read/write/delete. VBA can do anything the containing application can do.
And if the bad guys get hold of it, they can do anything the application can
do.

In .Net, the runtime is treated like another user. As soon as it wants to
do something, the OS gets to say "And who exactly might you be? Let's see
some ID here, otherwise, put your hands on the car and spread 'em...."

In VB or VBA, you had to write rather a lot of code to do things such as
create a user interface, and you can hide all manner of mischief inside that
code if you know what you are doing.

In .Net, all the UI and almost all the functions you will ever need are
already pre-build for you, and all you have to do is call them. I saw a
whole credit-card validation and approval widget built in about ten lines of
code: everything needed is already built in, you just call it. And because
it is built-in, and is almost a part of the operating system, it has already
been fully security-tested and can't be hacked.

But from solution creator's point of view, .Net brings the ability to create
massively-distributed applications. Not only will it automate anything it
is allowed to touch on the local system, it will automate anything it is
permitted to play with on any other computer system in the world.

So for example, you might create a Translation module: send me some text and
I will send it back to you in a different language. I might create an
Indexing module. Someone else might create a charting module. And of
course, your bank (or mine...) might create a micro-payment module.

The solution vendor could create a "book" that automatically prints itself
in all of the world's languages: type the text "here" in any language you
like. Press Print, and your book will print in the 29 most popular
languages in the world, provided your credit card authorises correctly.

a part from the
almost guarenteed (?) nescessity of another rewriting of macros on
my part ,

Yes, and "No" Being a cynical old curmudgeon, I agree with you.
However, the "Promised" target for the dot-Net guys is a completely
automatic upgrade from VBA to VBA.Net. That's the reason it has not yet
appeared, in Windows Office. They are still working on the conversion
utilities. Because .Net is secure by design, it will not put up with the
outrageous hacks that we get away with in VBA. In VBA.Net, every term must
be fully qualified in context. If we wrote VBA the way we're supposed to,
that would be easy to automate. We don't, so it's not.

I am "hoping" that VBA in PC Office will be a lot closer to VBA.Net in the
next iteration, and that that will be the version that comes to Mac Office
in Office 14 (the next Mac version).

May I ask what features of "VBA 7" you miss.

Too many to list, but the main one is the ability to run the same code
unchanged on the PC and the Mac. If I write (properly) in Word 2000 and
send the macro to the Mac, it will just work in Word 2004. If I write in
Word 2007, all hell breaks loose. Many of the objects, methods, and
properties have been extended in Word 2007 VBA to handle all the stuff that
Word 2007 can do. Each one produces a compile error or a runtime error in
Mac Word

Ie. I've found that one
feature that's often lamented is the lack of good Userform support
but I've found that WordBasic.BeginDialog/EndDialog constructs
works really well and looks great in Word 2004 (you can even use
the old Word 6 dialog tool if you have access to a wintel computer).

Hell, you're working too hard I just use the built-in Word dialogs

Cheers

--

Don't wait for your answer, click here: http://www.word.mvps.org/

Please reply in the group. Please do NOT email me unless I ask you to.

John McGhie, Microsoft MVP, Word and Word:Mac
Nhulunbuy, NT, Australia. mailto:[email protected]

 

[Phillip Jones]

Hi Phil,

Microsoft has targeted 2 year cycles for Office and Windows for many
years. But the future is always a moving target. By those standards
Vista was more than 4 years late.

I think the most realistic way to phrase it is that a timetable will be
developed internally based on guesstimates as to how long it will take
to build a new VBA compiler.

Combine that with any new features that might be being planned for the
next version and however long those will take and hopefully you'll
realize that coming up with any sort of a firm date is nearly impossible.

Plan, build, test, deploy. Each of those steps takes an indeterminate
amount of time. Deciding when software is "done" is akin to deciding
when a cake is done. When it smells good and tastes good it's ready.

-Jim

Hey I am not arguing with anyone on this subject.

Everyone *plans for a 2 year cycle*.

I'm just say MS has never had a True two year delivery date. The last
last version I bought before 2008 (which became available in 2008) was
2004 which became available for me to purchase in 2004.

You'll also note that the PC version equivalent for 2004 was Office2003
which was delivered in 2003 and PC version of 2008 was 2007 delivered in
2007.
--
------------------------------------------------------------------------
Phillip M. Jones, CET |LIFE MEMBER: VPEA ETA-I, NESDA, ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112 |[email protected], ICQ11269732, AIM pjonescet
------------------------------------------------------------------------

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

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://www.kimbanet.com/~pjones/90th_Birthday/index.htm>
<http://www.kimbanet.com/~pjones/Fulcher/default.html>
<http://www.kimbanet.com/~pjones/Harris/default.htm>
<http://www.kimbanet.com/~pjones/Jones/default.htm>

<http://www.vpea.org>

 

[Phillip Jones]

Hi Mitrokhin:

Perhaps this is old hat to some but I havn't seen it mentioned in here.

The decision was made about two months ago. Some of us have been under a
non-disclosure agreement that has prevented us talking about it until the
Microsoft announcement appeared.

I wonder if it's worthwhile to rewrite VBA macros in Applescript,
(which btw I have been doing for the last couple of days ).

Yes, I think so.

VBA is very good for automation "within" an Application. It begins to have
problems across applications, and cannot automate non-Microsoft Applications
at all.

AppleScript's strength is that it can automate ANYTHING on a Macintosh.
Because the AppleScript compiler/runtime runs outside the application, it is
extremely good at coordinating the efforts of multiple applications.

AppleScript begins to struggle WITHIN an Application, depending on how
richly-implemented the AppleScript Dictionary is.

Because the AppleScript dictionaries in Microsoft Office are simply a
re-expression of the VBA Object Model, and because Microsoft Office's core
applications were designed from the get-go to be automated, AppleScript
provides the ability to automate almost every dot and comma in a Microsoft
Office application.

So now, solution vendors get the ability to choose between two automation
technologies. AppleScript will be the winner when the task involves
automating non-Microsoft applications. VBA will be the winner when the task
benefits from having common code with the PC version.

[first Wordbasic then VBA then Applescript then perhaps VBA 2 then ?
sigh]

The one we REALLY want is "dot-Net". Dot-Net is very difficult to do on the
Mac, although there are efforts to get it working beginning to appear.
Microsoft's original plans for dot-Net included making it available on
platforms other than Win-Tel.

On a personal note, I am "hoping" (and that's all it is, a "hope") that "VBA
2" will take us closer to .Net. By the way, I am also hoping that what we
get will be "VBA 7" (the PC Office 2007 version). What we have in Office
2004 is two levels behind that, and the differences are becoming annoying.

Hope this helps

I am going to ask some dumb questions. Of which I am famous for doing.

Why is it so complicated to use the VBA used in PC Office on a Mac?

Is it the mapping of commands, and keyboard shortcuts?

The use of UNIX?
The PowerPC Processor with is strictly a RISC based Processor, then
going to an Intel chip with is a combination of both?

I don't need or want a 50 page explanation. Just why is it so complicated.

VBA support for Mac Office products have been in all versions for me
back to Excel 5 and Word 6 days. In fact it was so closely matched that
nasty bugs that could destroy files and hard drives on a PC could do the
same thing, on a Mac. Reason why it was recommend to turn off VBA based
Macros by Virus detection software vendors such a Symantec, as far back
as Word 6 days.

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

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

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://www.kimbanet.com/~pjones/90th_Birthday/index.htm>
<http://www.kimbanet.com/~pjones/Fulcher/default.html>
<http://www.kimbanet.com/~pjones/Harris/default.htm>
<http://www.kimbanet.com/~pjones/Jones/default.htm>

<http://www.vpea.org>

 

[Mitrokhin]

i microsoft.public.mac.office.word skrev Daiya Mitchell
Sun, 18 May 2008 06:54:17 -0400 (-), i en artikel med
ID <#[email protected]>
og titlen "Re: VBA to return in the next version of Office Mac !?",
følgende:


Hi

: Hi Mitrokhin,
:
: Mitrokhin wrote:
: > Indeed, Applescript seems to be very well integrated. I've also found
: > that in most cases the rewriting wasn't as hard as I expected (guees it
: > helped having the MacTech guide close at hand too , but alas there're
: > a couple of macros I just can't convert (more due to my own lack of
: > skills than anything else)
:
: If you have any macro replacement scripts you think would be useful for
: other people, I'd love to link them from here. Have you put them on
: Scriptbuilders.net or anything, perhaps?
: http://word.mvps.org/Mac/scripts/
:

No I havn't, see, my use of macros in word just might be very
idiosyncratic and then there's the question about coding quality: i'm
pretty far from being a programming whiz but you be the judge, would
eg. these hold an interest for other people (beware of linebreaks) ?


1. Toogle highlight on the selection or the whole line. Chose among
some predetermined highlightcolors.

2. Find the first occurence of a specially named bookmark from the
current ip to the end of the doc (if found go to said bookmark and
delete it) OR insert a bookmark at the current ip and highlight the
selection/line.

(yep I like highlighting stuff)

1. Toogle Highlight etc.
======
tell application "Microsoft Word"

if selection's selection type = selection ip then
expand the selection by a line item
-- chop off the paragraph mark
set r to create range active document start ¬
(selection's selection start) end ((selection's selection end)
- 1)
collapse range text object of selection direction collapse start
my highlightChange(r)
else
-- again chop off some superfluous chars
if (content of selection) ends with " " or (content of selection)
ends with return then
set selection's selection end to ((selection's selection end)
- 1)
end if

my highlightChange(text object of selection)
collapse range text object of selection direction collapse end
end if
end tell

on highlightChange(range)
tell application "Microsoft Word"
if highlight color index of range = no highlight then
set highlight color index of range to (my PickFarve())
else
set highlight color index of range to no highlight
end if
end tell
end highlightChange

on PickFarve()
set FarveListe to {"blue", "turquoise", "bright green", "violet", ¬
"yellow", "green", "pink"}

set FarveKoder to {2, 3, 4, 5, 7, 11, 12}

set the farve to (choose from list the FarveListe with prompt "Vælg
en farve:") as Unicode text
if farve is "false" then error number -128

repeat with i from 1 to the count of FarveListe
set denne_her to item i of the FarveListe
if denne_her is the farve then
set the opslagsKode to i
exit repeat
end if
end repeat
return item opslagsKode of FarveKoder

end PickFarve

====


2. Insert/go to bookmark

tell application "Microsoft Word"

-- fra IP/markeringen + 1 og frem
set r to (create range active document start ((selection's selection
end) + 1) ¬
end (end of content of text object of active document))
try
set bmk to first item of (get every bookmark of r whose name
contains "MARK")
set bmkRange to text object of bmk
select bmkRange

tell selection
set highlight color index of text object to auto
collapse range (text object of selection) direction collapse
start
end tell

delete bookmark (name of bmk) of active document

on error
-- ingen bogmærker med navnet mark. Opret et i markeringen
-- der kan dog være "MARK" bogmærker tidl. i dokumentet
if not (exists (bookmark "MARK" of active document)) then
set bmkNavn to "MARK"
else
set i to 1
repeat
if not (exists (bookmark ("MARK" & i) of active document))
then
set bmkNavn to "MARK" & i
exit repeat
end if

set i to 1 + 1
end repeat
end if

tell selection
if selection type = selection ip then expand by a line item
set selection end to ((selection end) - 1)
set highlight color index of text object to violet
end tell

make new bookmark at selection with properties {name:bmkNavn,
text objecttext object of selection)}
collapse range (text object of selection) direction collapse start

end try

end tell






: Daiya
:

 

[Mitrokhin]

i microsoft.public.mac.office.word skrev John McGhie
Sun, 18 May 2008 21:26:01 +0930 (-), i en artikel med
ID <C4564F69.15180%[email protected]>
og titlen "Re: VBA to return in the next version of Office Mac !?",
følgende:

Hi again

: Hi Mitrokhin:
:
: On 18/05/08 8:05 PM, in article
: 180520081235040670%[email protected], "Mitrokhin"
:
: > Btw I'm not a professional by a long shot. My "programming" (consisting
: > mostly of gathering bits and pieces here and there and adding a little
: > of my own code) is only for my personal non-business use.
:
: I wouldn't call myself a "professional" either, and if you saw my code, you
: would know why. But I do sell it

Well you know I just skimmed through some of the VBA code I've been
collecting (amazing how much stuff you collect) and there're some
with your name on it ... and I wouldn't say that at all.

:
: > My view on this is colored by the fact stated above. I'm not a
: > professional in contrast to yourself - and I have no idea what a
: > dot-netification of Mac Office would entail precisely,
:
: In essence, .Net is very similar to Java, but has the benefit of the
: learnings from the progress made in developing Java. In action, it looks a
: little bit like the Classic environment on the Mac: you get a "run time
: platform" that is treated as being part of the operating system.
:
: It gives you the speed advantages of being part of the operating system, and
: the security advantages of being fenced off by the operating system.
:
: A major issue with VBA is security. By DESIGN, VBA is not secure -- can
: never be secure, because it is designed to allow things such as file
: read/write/delete. VBA can do anything the containing application can do.
: And if the bad guys get hold of it, they can do anything the application can
: do.
:
: In .Net, the runtime is treated like another user. As soon as it wants to
: do something, the OS gets to say "And who exactly might you be? Let's see
: some ID here, otherwise, put your hands on the car and spread 'em...."
:
: In VB or VBA, you had to write rather a lot of code to do things such as
: create a user interface, and you can hide all manner of mischief inside that
: code if you know what you are doing.
:
: In .Net, all the UI and almost all the functions you will ever need are
: already pre-build for you, and all you have to do is call them. I saw a
: whole credit-card validation and approval widget built in about ten lines of
: code: everything needed is already built in, you just call it. And because
: it is built-in, and is almost a part of the operating system, it has already
: been fully security-tested and can't be hacked.
:
: But from solution creator's point of view, .Net brings the ability to create
: massively-distributed applications. Not only will it automate anything it
: is allowed to touch on the local system, it will automate anything it is
: permitted to play with on any other computer system in the world.
:
: So for example, you might create a Translation module: send me some text and
: I will send it back to you in a different language. I might create an
: Indexing module. Someone else might create a charting module. And of
: course, your bank (or mine...) might create a micro-payment module.
:
: The solution vendor could create a "book" that automatically prints itself
: in all of the world's languages: type the text "here" in any language you
: like. Press Print, and your book will print in the 29 most popular
: languages in the world, provided your credit card authorises correctly.
:

Thanks for the explanation. It would seem .net have some nice
features, although I doubt that I will ever find an application for the
kind of features you mention in the last three paragraphs .

: > a part from the
: > almost guarenteed (?) nescessity of another rewriting of macros on
: > my part ,
:
: Yes, and "No" Being a cynical old curmudgeon, I agree with you.
: However, the "Promised" target for the dot-Net guys is a completely
: automatic upgrade from VBA to VBA.Net. That's the reason it has not yet
: appeared, in Windows Office. They are still working on the conversion
: utilities. Because .Net is secure by design, it will not put up with the
: outrageous hacks that we get away with in VBA. In VBA.Net, every term must
: be fully qualified in context. If we wrote VBA the way we're supposed to,
: that would be easy to automate. We don't, so it's not.
:

I see, so it's not unrealistic to hope for some sort of automated
conversion between VBA and .Net: that's just sweet music in my ears.


: I am "hoping" that VBA in PC Office will be a lot closer to VBA.Net in the
: next iteration, and that that will be the version that comes to Mac Office
: in Office 14 (the next Mac version).
:
: > May I ask what features of "VBA 7" you miss.
:
: Too many to list, but the main one is the ability to run the same code
: unchanged on the PC and the Mac. If I write (properly) in Word 2000 and
: send the macro to the Mac, it will just work in Word 2004. If I write in
: Word 2007, all hell breaks loose. Many of the objects, methods, and
: properties have been extended in Word 2007 VBA to handle all the stuff that
: Word 2007 can do. Each one produces a compile error or a runtime error in
: Mac Word
:

I see your point of view: yes the closest possible integration between
Mac & Win office is important.

: > Ie. I've found that one
: > feature that's often lamented is the lack of good Userform support
: > but I've found that WordBasic.BeginDialog/EndDialog constructs
: > works really well and looks great in Word 2004 (you can even use
: > the old Word 6 dialog tool if you have access to a wintel computer).
:
: Hell, you're working too hard I just use the built-in Word dialogs
:

Could be (and it wouldn't be the first time, especially if you add
"when there's no particular reason for doing so" but in this
instance it does allow for some nice customized dialogs here and
there I think.


: Cheers
:
: --
:
: Don't wait for your answer, click here: http://www.word.mvps.org/
:
: Please reply in the group. Please do NOT email me unless I ask you to.
:
: John McGhie, Microsoft MVP, Word and Word:Mac
: Nhulunbuy, NT, Australia. mailto:[email protected]
:
:

 

[Daiya Mitchell]

No I havn't, see, my use of macros in word just might be very
idiosyncratic and then there's the question about coding quality: i'm
pretty far from being a programming whiz but you be the judge, would
eg. these hold an interest for other people (beware of linebreaks) ?


1. Toogle highlight on the selection or the whole line. Chose among
some predetermined highlightcolors.

2. Find the first occurence of a specially named bookmark from the
current ip to the end of the doc (if found go to said bookmark and
delete it) OR insert a bookmark at the current ip and highlight the
selection/line.

Yeah, I'm no programming whiz to be judging quality either. And yeah,
my macros are all very idiosyncratic too. But I might wind up borrowing
your highlight script at some point, or building on it.

I probably won't link them from the page, but by posting them here they
should come up if anyone searches the group for AppleScript. Any code
sample that works might be useful for someone.

Thanks,
Daiya

 

[Jim Gordon MVP]

I am going to ask some dumb questions. Of which I am famous for doing.

Why is it so complicated to use the VBA used in PC Office on a Mac?

Is it the mapping of commands, and keyboard shortcuts?

The use of UNIX?
The PowerPC Processor with is strictly a RISC based Processor, then
going to an Intel chip with is a combination of both?

I don't need or want a 50 page explanation. Just why is it so complicated.

VBA support for Mac Office products have been in all versions for me
back to Excel 5 and Word 6 days. In fact it was so closely matched that
nasty bugs that could destroy files and hard drives on a PC could do the
same thing, on a Mac. Reason why it was recommend to turn off VBA based
Macros by Virus detection software vendors such a Symantec, as far back
as Word 6 days.

Hi Phillip,

The PC version of VBA is designed to use Microsoft Windows. The Windows
operating system addresses the hardware in specific ways. Since Windows
is not on a Mac, VBA will have to be customized to take advantage of
MacOS and how Apple hardware is controlled by software.

It's not just the mapping of commands and keyboard shortcuts. Everything
including window management and the way the screen is drawn is different
on a Mac than a PC. Normally, software is written in something like C++
or C#, then it is converted to low level programs. VBA sometimes has to
interface directly with the hardware to maintain speed (something
notably lacking in previous Mac iterations of VBA).

Whenever you use software that you didn't write yourself you are
trusting the author to not damage your system. No matter what language
is used, as long as it has access to the file system it has the
potential to do bad things. The absolute safest thing to do is to not
run any software at all on your computer. That's downright stupid. It's
equally stupid to brand all software written in a given language as too
dangerous to use and then ban it or bad mouth it. Also stupid is running
any and all software the comes your way regardless of its source.

There are tens of thousands of viruses and other exploits. The vast
majority deal with internet and web technologies, especially web
browsers and email.

I only know of one VBA virus, the ancient Word Macro virus, which was
easy to get rid of simply by deleting the file Normal.dot. There may
have been a couple other viruses written in VBA, but it is hardly
something to get all flustered about.

Having the full file system at the developer's finger tips is a very
valuable thing. Almost every application I write needs to save, open,
and revise documents, so this is essential even though it could be used
in bad ways.

-Jim

--
Jim Gordon
Mac MVP

MVPs are independent experts who are not affiliated with Microsoft.


Visit my blog
http://blog.360.yahoo.com/blog-i7JMeio7cqvhotIUwCzaJWq9

 

[Mitrokhin]

i microsoft.public.mac.office.word skrev Daiya Mitchell
Mon, 19 May 2008 19:27:49 -0400 (-), i en artikel med
ID <[email protected]>
og titlen "Re: VBA to return in the next version of Office Mac !?",
følgende:

:
: Yeah, I'm no programming whiz to be judging quality either. And yeah,
: my macros are all very idiosyncratic too. But I might wind up borrowing
: your highlight script at some point, or building on it.
:

Great

: I probably won't link them from the page, but by posting them here they
: should come up if anyone searches the group for AppleScript. Any code
: sample that works might be useful for someone.
:
: Thanks,
: Daiya
: >
:

And thank you for your "Script Solutions for Word 2008" and
"Using MS Word" pages

 

[JE McGimpsey]

I'm just say MS has never had a True two year delivery date.

MacWord/Office:

Version Year
1 1985
3 1987
4 1989
5 1991
6 1993
98 1998
01 2000
vX 2001
04 2004
08 2008

Hit the two-year mark: 5 out of 9 times

WinWord/Office
1 1989
2 1991
6 1993
95 1995
97 1997
00 1999
02 2001
03 2003
07 2006

Hit the two-year mark: 7 out of 8 times.