How to install VBA ?

[Stephan Schaem]

We are using VBA and we are finding out that most office XP / 2003 user dont have this installed.

This is a huge pain to have to show users how to install it from their CD (if they know where it is)/

Is there a way for ISV to install VBA (like .net, directx, etc..) on the user machine automaticly ?
Or at least call the office install to force install that componant.

Beside that, We can take care of the "enable" / "desable" flag in the registry.



Stephan

 

[TC]

Since no-one else has answered: I really can't see that "most Office
XP/2003 users" would not have VBA installed. Surely VBA would be
installed as part of Office (since most if not all of the Office
programs support VBA).

Are you sure that it is not being disabled by a virus checker or
some-such?

HTH,
TC

 

[TC]

IOW, how do you know that it has not been installed?

TC

 

[TC]

IOW, how do you know that it has not been installed?

TC

 

[Stephan Schaem]

I dont beleive its installed when doing a minimal install.
We plan to verify all this next week.

Stephan

 

[TC]

I did a general groups search on "tell if vba is installed" (without
the quotes) & there were various hits.

One person said that VBA is "always installed with Office 2000". But
another one said: "I have noted on several clients machines that the
VBA portion was not installed. They say they installed using the
Typical install but for some reason this is not the case." (Not sure
what he meant by "this", in the previous sentence. They /did/ do a
typical install & they did not get VBA?)

Keep us posted,
TC

 

[Steve Rindsberg]

I did a general groups search on "tell if vba is installed" (without
the quotes) & there were various hits.

One person said that VBA is "always installed with Office 2000".

Always installed but of course macros may be disabled.

In later Office versions, it's possible to install w/o VBA, but I don't think
it's the default in either 2002 or 2003.

But

 

[TC]

Steve, assuming you read this, do you have any further info on this?

My main product uses VBA, so I am interested in anything that causes
VBA to fail (or not be there).

TIA,
TC

 

[Steve Rindsberg]

Steve, assuming you read this, do you have any further info on this?

My main product uses VBA, so I am interested in anything that causes
VBA to fail (or not be there).

No further info to add, no. It's not something I've run into often, if at all.
There've been a few support cases where I suspected that VB wasn't installed
but as far as I can remember, it's always turned out to be some sort of
permissions issue or a corrupted user profile that caused the problem.

 

[Stephan Schaem]

Here is what we did to guide user with potential VBA problems.
In our first small Ovation open beta a few user had VBA not install.

We used this now to determine whether VBA is enabled for Office applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;285884

I'm wondering if some virus protection tools set to "High protection" might turn off VBA because its considered a security risk ?

Stephan

 

[Steve Rindsberg]

Thanks for that link ... quite useful.

I'm not sure whether virus protection tools would themselves prevent VBA from
running, but they might turn on the security features already built into
Office apps; if security's set to High or Very High, it could prevent
unsigned macros from running.

Here is what we did to guide user with potential VBA problems.
In our first small Ovation open beta a few user had VBA not install.

We used this now to determine whether VBA is enabled for Office applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;285884

I'm wondering if some virus protection tools set to "High protection" might

turn off VBA because its considered a security risk ?

 

[TC]

We used this now to determine whether VBA is enabled for Office applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;285884

I find their example odd. It seems to be checking that VBA is installed
/for Word/. On my reading of it, it does not guarantee that VBA is
installed for Excel, for example.

TC

 

[TC]

if security's set to High or Very High, it could prevent
unsigned macros from running.

The AutomationSecurity property is your friend here. It works fine for
Access, I assume it works for the other Office apps. Google in
microsoft.public.access.security for posts from me (TC) containing
that word.

HTH,
TC

 

[Steve Rindsberg]

I find their example odd. It seems to be checking that VBA is installed
/for Word/. On my reading of it, it does not guarantee that VBA is
installed for Excel, for example.

In a standalone install of Excel or PPT, that's true, most probably.

But in the Office install, you don't have the opportunity to turn VBA on/off on
a per app basis, so if it's installed for Word, it's installed for the others,
no?

 

[TC]

But in the Office install, you don't have the opportunity to turn VBA on/off on
a per app basis, so if it's installed for Word, it's installed for the others,
no?

You'd know more than I would on that.

But, if what you say is true, why do they store the setting at the
"product" level (Word, Excel, Powerpoint, etc.)? Shouldn't they store
it at the /user/ level? Note how the example code queries the setting
for a specific product (Word) - not for a specific user.

TC

 

[Steve Rindsberg]

You'd know more than I would on that.

But, if what you say is true, why do they store the setting at the
"product" level (Word, Excel, Powerpoint, etc.)?
Shouldn't they store
it at the /user/ level? Note how the example code queries the setting
for a specific product (Word) - not for a specific user.

Maybe as a matter of convenience; it might work just as well to launch Excel or PPT
and query the product code for those, then use msiQueryFeatureState to determine
whether VBAFiles are installed for them. And perhaps it'd be necessary if your
concern is, eg installing a PPT addin and want to be sure you check correctly

[fires up VB, meddles with the code]

It appears to work correctly in Office 2003 if you substitute
PowerPoint.Application for Word.Application

Well. At least it gives the right answers and doesnt' blow up on my copy, with VBA
installed and enabled. ;-)

I'm guessing that if Office is installed to multiple user profiles, this code would
return the appropriate info for the user under whose login you run it. That is, if
VBA's installed in my profile and not yours, it'd tell us so.

If I put this to any serious use, I'd modify it so it tests the Office/App version
first, and if it's 9 or earlier, return that VBA is installed, since there doesn't
seem to be an option NOT to install it.

Whether or not it can be disabled, I don't know. Anybody?

 

[TC]

My worry is not whether it is installed for one user but not for
another. It is whether it is installed for /Word/ (which is what the
example code seems to check) but not for other Office products, eg.
Excel. It seems to me that if you are automating several Office
products (eg. Word /and/ Excel /and/ Powerpoint), you may need to run
their example code three times - once for each product.

Yes? No?

TC

 

[Steve Rindsberg]

My worry is not whether it is installed for one user but not for
another. It is whether it is installed for /Word/ (which is what the
example code seems to check) but not for other Office products, eg.
Excel.

Have another look at the Office installer. I don't think you have the option
of installing VBA for one product and not another. You get VBA (across all of
them) or you get no VBA (ditto).

I've no idea how this might play out if you installed standalone Word w/o VBA
then standalone Excel with VBA. Though come to think of it, do they even SELL
those two standalone?

It seems to me that if you are automating several Office
products (eg. Word /and/ Excel /and/ Powerpoint), you may need to run
their example code three times - once for each product.

Yes? No?

I don't *think* so but as a belt & braces kind of thing, it certainly couldn't
hurt to test all three just so you know if you've run into some kind of weird
case.

It takes a wee bit longer, but it's a one-time hit, right? You'd just be doing
this at install, right?

 

[TC]

Yes, I don't imagine that it would be noticeable if you checked all
three (instead of just one).

To summarize, my position is this. If VBA is an "äll or nothing"
thing, why doesn't it have its own product code?

Does anyone know?

Cheers,
TC

 

[Steve Rindsberg]

Yes, I don't imagine that it would be noticeable if you checked all
three (instead of just one).

To summarize, my position is this. If VBA is an "äll or nothing"
thing, why doesn't it have its own product code?

I can't answer that, but it makes sense ... VBA isn't a standalone product; it
can't exist w/o a host app (makes it sound vaguely verminous, doesn't it? <g>)