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

cp.
[url down]
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]

More info here:
http://www.schwieb.com/blog/2008/05/...-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.

Mitrokhin wrote:
[..]

Daiya Mitchell <daiyaNOSPAM> wrote:

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

Which means 2010, 2011......

Corentin

Corentin Cras-Méneur wrote:
> Daiya Mitchell <daiyaNOSPAM> wrote:
>
>> Note that "next version" means next purchased upgrade, *not* an update
>> to Office 2008.
>
> Which means 2010, 2011......
>
> Corentin

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

Phillip Jones <pjones1> wrote:

> > Which means 2010, 2011......
> >
> > Corentin
>
> or 2013... 2014.... ;-)


:-)
I thought MS had announced a shorted development cycle??


Corentin

Phillip Jones wrote:
>> Corentin Cras-Méneur wrote:
>> Daiya Mitchell <daiyaNOSPAM> wrote:
>>
>>> Note that "next version" means next purchased upgrade, *not* an update
>>> to Office 2008.
>>
>> Which means 2010, 2011......
>>
>> Corentin
>
> 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

Corentin Cras-Méneur wrote:
> Phillip Jones <pjones1> wrote:
>
>>> Which means 2010, 2011......
>>>
>>> Corentin
>> or 2013... 2014.... ;-)
>> :-)
> I thought MS had announced a shorted development cycle??
>> Corentin
>

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

Hi Mitrokhin:

On 16/05/08 5:38 PM, in article
160520081008452444%Mitrokhin, "Mitrokhin"
<Mitrokhin> wrote:

> 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 microsoft.public.mac.office.word skrev John McGhie
Sun, 18 May 2008 08:33:36 +0930 (-), i en artikel med
ID <C4559A60.15117%john>
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%Mitrokhin, "Mitrokhin"
: <Mitrokhin> wrote:
:
: > 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:john
:

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/

Daiya

Hi Mitrokhin:

On 18/05/08 8:05 PM, in article
180520081235040670%Mitrokhin, "Mitrokhin"
<Mitrokhin> wrote:

> 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

Jim Gordon MVP wrote:
[..]
> 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.

John McGhie wrote:
[..]
> 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.

i microsoft.public.mac.office.word skrev Daiya Mitchell
Sun, 18 May 2008 06:54:17 -0400 (-), i en artikel med
ID <#Cf9DWNuIHA.3604>
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 object:(text object of selection)}
collapse range (text object of selection) direction collapse start

end try

end tell






: Daiya
:

i microsoft.public.mac.office.word skrev John McGhie
Sun, 18 May 2008 21:26:01 +0930 (-), i en artikel med
ID <C4564F69.15180%john>
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%Mitrokhin, "Mitrokhin"
: <Mitrokhin> wrote:
:
: > 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:john
:
: