Hi Mitrokhin:
On 18/05/08 8:05 PM, in article
180520081235040670%Mitrokhin@[EMAIL PROTECTED]
"Mitrokhin"
<Mitrokhin@[EMAIL PROTECTED]
> 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 sup****t
> 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:john@[EMAIL PROTECTED]
|
