Is including Excel9.olb in the installation files necessary?

10 Sep 2010 4:19 AM

Mike S

I made an Inno installer script for a program that automates Excel,
based on my P&D setup.lst, which includes the Excel object library:

[Setup1 Files]
.....
Fil***@EXCEL9.OLB,$(WinSysPath),,$(Shared),3/19/99 10:00:32
PM,638976,9.0.0.2719

I read here that this file is installed with Excel when part of Office 2000:

"File Description: Microsoft Office 2000 component".

http://www.bleepingcomputer.com/filedb/excel9.olb-22355.html
---

This MS page verified that, and mentioned a new location of the object
library in Office 2002-3:

"...If you are automating Microsoft Excel 2000, choose Microsoft Excel
9.0 Object Library for which the default location is the C:\Program
Files\Microsoft Office\Office\Excel9.olb.
If you are automating Microsoft Excel 2002 and Microsoft Office Excel
2003, the object library is embedded in the file Excel.exe. ..."

http://support.microsoft.com/kb/178749
---

It sounds like every Office installation that includes Excel includes an
Excel object library file. Is it necessary to include the olb my P&D
Wizard included when installing a program that automates Excel? It seems
redundant. Installing it on a machine that doesn't have Excel doesn't
seem like it will accomplish anything, except maybe allowing you to trap
an error telling you Excel is not installed with a more specific error
number. Can I safely remove this file from the installer no matter what
version of Office, or what OS (XP or later)?

Mike

10 Sep 2010 5:00 AM

Tony Toews

On Thu, 09 Sep 2010 21:19:10 -0700, Mike S <ms***@yahoo.com> wrote:

>Is it necessary to include the olb my P&D
>Wizard included when installing a program

No. It's just a pointer file or something similar. We had a big
discussion on this a short while ago that I likely initiated that
explained all this but I can't find the discussion right now.

>that automates Excel?

And you likely can't legally redistribute it anyhow.

Finally are you sure you even want to reference it? What happens if
the user has a different version of Excel? Or Excel isn't installed
at all? In the Access world I point folks to the following article
on late binding and it should stil be quite relevant to VB6.

"Late Binding in Microsoft Access" page at
http://www.granite.ab.ca/access/latebinding.htm

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

10 Sep 2010 5:40 AM

Mike S

On 9/9/2010 10:00 PM, Tony Toews wrote:
Show quoteHide quote

> On Thu, 09 Sep 2010 21:19:10 -0700, Mike S<ms***@yahoo.com> wrote:

>> Is it necessary to include the olb my P&D
>> Wizard included when installing a program

> No. It's just a pointer file or something similar. We had a big
> discussion on this a short while ago that I likely initiated that
> explained all this but I can't find the discussion right now.
>> that automates Excel?

> And you likely can't legally redistribute it anyhow.
> Finally are you sure you even want to reference it? What happens if
> the user has a different version of Excel? Or Excel isn't installed
> at all? In the Access world I point folks to the following article
> on late binding and it should stil be quite relevant to VB6.
> "Late Binding in Microsoft Access" page at
> http://www.granite.ab.ca/access/latebinding.htm
> Tony

Thanks very much, this sounds perfect, I'll try this and see how it works.

Mike

10 Sep 2010 5:26 PM

GS

> And you likely can't legally redistribute it anyhow.

This is definitely a NO-NO!

>
> Finally are you sure you even want to reference it? What happens if
> the user has a different version of Excel?

Whatever version of
excel you ref in your project, it will be updated to whatever version
is running on the user's machine. It's just considered good practice in
the Excel programming world to always develop for the earliest version
you expect users to use.

> Or Excel isn't installed at all?

You will get a MISSING! flag in the refs dialog. It's always good to
test (using CreateObject) if the target machine has Excel installed,
whether or not you use early binding for development. Just don't
execute the code if Excel is not installed, and display a notification
to the user of the requirement for Excel to be installed.

Here's one of several test functions I use for checking installation of
required MSO apps. I have one for each MSO app I'd be inclined to
automate.

Public Function bExcelAvailable() As Boolean
' Determines whether Excel is available for automation on the computer.
Dim xlApp As Object

'Attempt to start an instance of Excel.
On Error Resume Next
Set xlApp = CreateObject("Excel.Application")
On Error GoTo 0
'Return the result of the test.
bExcelAvailable = (Not xlApp Is Nothing)
Set xlApp = Nothing
End Function 'bExcelAvailable()

So in my code I'd make anything that requires Excel to be installed
conditional on the return of the test function:

If bExcelAvailable Then
'do stuff
Else
NotifyAutomationFailure
End If

Sub NotifyAutomationFailure()
Dim sMsg As String
sMsg = "This application requires Excel to be installed on your
computer."
sMsg = sMsg & vbCrLf
sMsg = sMsg & "Excel failed to start. This application can not
continue!"
MsgBox sMsg, vbCritical, "Startup Failure!"
End Sub

HTH

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

10 Sep 2010 8:00 PM

Mike S

On 9/10/2010 10:26 AM, GS wrote:
Show quoteHide quote

>> And you likely can't legally redistribute it anyhow.
>
> This is definitely a NO-NO!
>
>>
>> Finally are you sure you even want to reference it? What happens if
>> the user has a different version of Excel?
>
> Whatever version of
> excel you ref in your project, it will be updated to whatever version is
> running on the user's machine. It's just considered good practice in the
> Excel programming world to always develop for the earliest version you
> expect users to use.
>
>> Or Excel isn't installed at all?
>
> You will get a MISSING! flag in the refs dialog. It's always good to
> test (using CreateObject) if the target machine has Excel installed,
> whether or not you use early binding for development. Just don't execute
> the code if Excel is not installed, and display a notification to the
> user of the requirement for Excel to be installed.
>
> Here's one of several test functions I use for checking installation of
> required MSO apps. I have one for each MSO app I'd be inclined to automate.
>
> Public Function bExcelAvailable() As Boolean
> ' Determines whether Excel is available for automation on the computer.
> Dim xlApp As Object
>
> 'Attempt to start an instance of Excel.
> On Error Resume Next
> Set xlApp = CreateObject("Excel.Application")
> On Error GoTo 0
> 'Return the result of the test.
> bExcelAvailable = (Not xlApp Is Nothing)
> Set xlApp = Nothing
> End Function 'bExcelAvailable()
>
> So in my code I'd make anything that requires Excel to be installed
> conditional on the return of the test function:
>
> If bExcelAvailable Then
> 'do stuff
> Else
> NotifyAutomationFailure
> End If
>
> Sub NotifyAutomationFailure()
> Dim sMsg As String
> sMsg = "This application requires Excel to be installed on your computer."
> sMsg = sMsg & vbCrLf
> sMsg = sMsg & "Excel failed to start. This application can not continue!"
> MsgBox sMsg, vbCritical, "Startup Failure!"
> End Sub
>
> HTH

I am using the approach Tony Toews suggested, "Late Binding in Microsoft
Access" http://www.granite.ab.ca/access/latebinding.htm
Apparently I was not clear enough, the olb file is now removed from the
installer. The late binding worked on Excel 2000.
Thanks Again Tony.

10 Sep 2010 8:42 PM

Tony Toews

On Fri, 10 Sep 2010 13:26:56 -0400, GS <gesan***@netscape.net> wrote:

>> Finally are you sure you even want to reference it? What happens if
>> the user has a different version of Excel?
>
>Whatever version of
>excel you ref in your project, it will be updated to whatever version
>is running on the user's machine.

That's not been my experience in the Access world.

>It's just considered good practice in
>the Excel programming world to always develop for the earliest version
>you expect users to use.

And Word and whatever else.

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

10 Sep 2010 9:50 PM

GS

Tony Toews formulated the question :

> On Fri, 10 Sep 2010 13:26:56 -0400, GS <gesan***@netscape.net> wrote:
>
>>> Finally are you sure you even want to reference it? What happens if
>>> the user has a different version of Excel?
>>
>> Whatever version of
>> excel you ref in your project, it will be updated to whatever version
>> is running on the user's machine.
>
> That's not been my experience in the Access world.

Apparently, some MSO apps behave differently. I've never had a need to
automate Access but I here the version ref is critical.

Outlook is a single-instance only app and so its test (and automation)
needs to be handled a bit different.

The test function example I posted was for Excel, but they all also
grab version info (removed for brevity) into global vars for each MSO
app so I know what's been installed.

In most cases, my apps will always contain version-specific code and so
it's mandatory they be version aware!

>
>> It's just considered good practice in
>> the Excel programming world to always develop for the earliest version
>> you expect users to use.
>
> And Word and whatever else.

Well, of course...<g>

>
> Tony

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

11 Sep 2010 12:13 AM

Tony Toews

On Fri, 10 Sep 2010 17:50:16 -0400, GS <gesan***@netscape.net> wrote:

>>> Whatever version of
>>> excel you ref in your project, it will be updated to whatever version
>>> is running on the user's machine.
>>
>> That's not been my experience in the Access world.
>
>Apparently, some MSO apps behave differently. I've never had a need to
>automate Access but I here the version ref is critical.

I shoud've been more specific. I meant Access as the programming
environment referencing Excel, Word or Outlook. In the Access world
if you had a different version of Excel, Word or Outlook than the
users then the Access app would fall over with wierd VBA errors long
before it even attempted to run your Excel, Word or Outlook specific
code.

>In most cases, my apps will always contain version-specific code and so
>it's mandatory they be version aware!

Ah, whereas I kept my code to be very simplish and generic. It likely
could've worked in Office 97 without any changes.

>>> It's just considered good practice in
>>> the Excel programming world to always develop for the earliest version
>>> you expect users to use.
>>
>> And Word and whatever else.
>
>Well, of course...<g>

You know that but lurkers might not.

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

11 Sep 2010 4:12 AM

GS

Thanks for that input! ..much appreciated.

So then, I suspect you work with Access the same way I work with Excel
as my base platform, automating the other MSO apps as/when required. In
my case, my frontloader VB6.exe will test for all MSO apps required by
my COMAddin app before creating its instance of Excel. Only when all
startup requirements are met will I actually create the Excel instance
I'll use, and then load the COMAddin.

In cases where clients don't use MSO I use a VB6.exe with Farpoint's
Spread, an awesome control which totally eliminates any dependancy on
Excel.

I don't have much experience with Access beyond building basic
databases to use with my apps when appropriate. I'm looking at using
SQLite with Olaf's dhRichClient components as an alternative. I just
don't get a lot of requests for database structures beyond what can be
done with plain text files and ADO.<g>

Kind regards,

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

11 Sep 2010 8:15 PM

Tony Toews

On Sat, 11 Sep 2010 00:12:29 -0400, GS <gesan***@netscape.net> wrote:

>Thanks for that input! ..much appreciated.
>
>So then, I suspect you work with Access the same way I work with Excel
>as my base platform, automating the other MSO apps as/when required.

Pretty much. Although I've been doing a lot of work in VB6 this last
year.

>In
>my case, my frontloader VB6.exe will test for all MSO apps required by
>my COMAddin app before creating its instance of Excel. Only when all
>startup requirements are met will I actually create the Excel instance
>I'll use, and then load the COMAddin.

Whereas I'm working on my Auto FE Updater which is a utility for use
by Access developers. So it too is a "front end" although with a very
different role in life.

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

11 Sep 2010 8:57 PM

GS

Tony Toews explained on 9/11/2010 :

> On Sat, 11 Sep 2010 00:12:29 -0400, GS <gesan***@netscape.net> wrote:
>
>> Thanks for that input! ..much appreciated.
>>
>> So then, I suspect you work with Access the same way I work with Excel
>> as my base platform, automating the other MSO apps as/when required.
>
> Pretty much. Although I've been doing a lot of work in VB6 this last
> year.

That's probably a good thing, especially if Access supports COMAddins.
I found this about the only way to obtain any reasonable level of code
security. Also, VB6 offers much better advantages over working with
VBA<IMO>.

Seems, though, that you've been around longer than that. Your posts
certainly have been appreciated!<g>

>
>> In
>> my case, my frontloader VB6.exe will test for all MSO apps required by
>> my COMAddin app before creating its instance of Excel. Only when all
>> startup requirements are met will I actually create the Excel instance
>> I'll use, and then load the COMAddin.
>
> Whereas I'm working on my Auto FE Updater which is a utility for use
> by Access developers. So it too is a "front end" although with a very
> different role in life.

I can't imagine what that would be where Access is concerned. Most of
my solutions are user-defined task specific utilities that provide
custom analysis of existing database data. Thus, that part is already
in place for the most part, just requiring field mapping to integrate
with my app.

I use a frontloader for multiple purposes, mostly to qualify if startup
will happen. It's a good place to do a bunch of stuff that's common to
every app but doesn't really need to be compiled internally with the
app.exe. I'm referring to checking if required files exist, access
permissions haven't changed, Excel is installed, license validation,
and if all is well then workspace setup. (I pretty much like to use
dictator type configurations so my users aren't distracted with all the
unused features of Excel. I try to take this as far as possible so it
doesn't even seem like my users are working in Excel)

>
> Tony

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

12 Sep 2010 2:32 AM

Tony Toews

On Sat, 11 Sep 2010 16:57:49 -0400, GS <gesan***@netscape.net> wrote:

>> Pretty much. Although I've been doing a lot of work in VB6 this last
>> year.
>
>That's probably a good thing, especially if Access supports COMAddins.

That whole bit about COMAddins I know nothing about.

>I found this about the only way to obtain any reasonable level of code
>security.

There's only one outfit who stated they can retreive the code, without
comments of course, from an Access MDE.

>Also, VB6 offers much better advantages over working with
>VBA<IMO>.

Actually Access is a better GUI for desiging forms than VB6. The GUI
editor is much more refined with lots of little tweaks. For example
if you accidentally move a control in Access Ctrl+Z will put it back.
Not so in VB6.

But I wanted to use VB simply because it was a standalone utility and
didn't require anything else. Mind you that was ten years ago so I've
forgotten the exact reasons. I suspect part of the reason was simply
to play, err program, in a different environment.

>Seems, though, that you've been around longer than that. Your posts
>certainly have been appreciated!<g>

In this newsgroup I haven't been doing too much posting before about a
year ago. However there are a *lot* of similarities between VB6 and
VBA. Indeed there's an obscure bug while debugging code that happens
in both VB6 and VBA.

OTOH there are enough differences that, in one posting of mine in this
newsgroup,I was completely wrong with my solution. The solution works
in Access but not VB6. I was somewhat embarrassed so I've been a bit
more cautious ever since. <smile>

>> Whereas I'm working on my Auto FE Updater which is a utility for use
>> by Access developers. So it too is a "front end" although with a very
>> different role in life.
>
>I can't imagine what that would be where Access is concerned.

Visit the website as per my sig below. <smile> The first page should
give you the basics. I'm up to about 16K lines of code of which about
3K or 4K are imported API calls or user controls.

Once I add the options to copy subfolders I will be activating my
autofileupdater.com website and see if I can sell a generic solution
to copying sets of files to PCs. Dunno if that's feasible but it
isn't going to cost me much time to have a slightly different program.

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

12 Sep 2010 3:53 AM

GS

Actually, I've been browsing your site in general, as a source for
Access tips/info. Looks impressive to me!

<FYI>
(Interesting that your URL is '.ca'! I'm located in eastern Ontario on
the St. Lawrence)
</FYI> Where are you?

I'm not a database expert by any means, but I do know the basic rules
for building good relational databases. Fact is most of my work uses
flat tables of data, all of which can be easily stored/retrieved from
text files or Excel worksheets. An Excel workbook was my first database
because it provided an easy way to construct multi-table storage
without having to learn a new app (ie: Access). I can distribute an XLS
and work with it using ADO and so it shouldn't matter that the end user
doesn't have Excel. -Never tested this out but I suspect it's the case
since I know ADO works with MDBs on machines where Access is not
installed. It's the limitations of using an XLS that are driving me to
look at SQLite.

Otherwise, I just work with users' existing database app files and use
field mapping as mentioned earlier.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

12 Sep 2010 4:59 AM

Tony Toews

On Sat, 11 Sep 2010 23:53:25 -0400, GS <gesan***@netscape.net> wrote:

>Actually, I've been browsing your site in general, as a source for
>Access tips/info. Looks impressive to me!

Thank. I like to think that, while it's very ugly, it's among the best
five in terms of content for advanced Access folks.

My excuse for it being so ugly is that I started it in late 1995 using
Notepad and a help file describing HTML from a shareware HTML editor
called Hot Dog. Been too busy to do a site overhaul and too cheap to
pay anyone to update it.

><FYI>
>(Interesting that your URL is '.ca'! I'm located in eastern Ontario on
>the St. Lawrence)
></FYI> Where are you?

Alberta. That's the ab in the website URL. <smirk>

>An Excel workbook was my first database
>because it provided an easy way to construct multi-table storage
>without having to learn a new app (ie: Access).

Hehe. Many corporate IT nazis think of uninstalling Access because
users abuse it. My standard response is, at least the users are
trying to build a proper database. It'll be worse in Excel. <smile>

> I can distribute an XLS
>and work with it using ADO and so it shouldn't matter that the end user
>doesn't have Excel. -Never tested this out but I suspect it's the case
>since I know ADO works with MDBs on machines where Access is not
>installed. It's the limitations of using an XLS that are driving me to
>look at SQLite.

Embrace what is already present. <smile>

I'd not use SQLite because it requires another set of DLLs,
distribution, installation etc. I would suggest MDB format simply
because the Jet 4.0/DAO 3.6/ADO 2.8 DLLs come with Windows 2000 and
newer including Windows 7. You don't have to even think about them
because the Windows OS updates them for security patches.

For some information with respect to versioning on ADO see my blog
posting: I've never quite trusted ADO because ...
http://msmvps.com/blogs/access/archive/2010/07/01/i-ve-never-quite-trusted-ado-because.aspx

Of course we don't know what is going to happen in Windows 8 with
those DLLs. But I suspect a *lot* of apps depend on those so they may
be sticking around for a long time to come.

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

10 Sep 2010 8:14 AM

Dee Earley

On 10/09/2010 05:19, Mike S wrote:

> I made an Inno installer script for a program that automates Excel,
> based on my P&D setup.lst, which includes the Excel object library:

Did you not like my answer in the Inno groups? :)
I'd already said you can't distribute it and you acknowledged it...

--
Dee Earley (dee.ear***@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

10 Sep 2010 8:43 AM

Mike S

On 9/10/2010 1:14 AM, Dee Earley wrote:

> On 10/09/2010 05:19, Mike S wrote:
>> I made an Inno installer script for a program that automates Excel,
>> based on my P&D setup.lst, which includes the Excel object library:
>
> Did you not like my answer in the Inno groups? :)
> I'd already said you can't distribute it and you acknowledged it...

I read your post, and with all due respect, while you expressed an
opinion you gave no sources, so I did a little looking around with
Google, and came here to find out what I could learn. The answer I got
here was extremely helpful and just what I needed. I was fortunate
enough to benefit from a discussion by some very talented programmers
that I didn't even participate in. I think I understand the situation a
lot better now, so I can automate Excel, and avoid distributing one file
unnecessarily and potentially illegally. You may recall that the same
newsgroup also had a reply strongly recommending I contact MS to resolve
that issue. I consider myself fortunate to have received a better
understanding of the problem, and a solution, without dealing with any
phone support.

10 Sep 2010 12:38 PM

Kevin Provance

Show quote Hide quote

"Mike S" <ms***@yahoo.com> wrote in message
news:i6cr3c$q97$1@news.eternal-september.org...
:
: I read your post, and with all due respect, while you expressed an
: opinion you gave no sources, so I did a little looking around with
: Google, and came here to find out what I could learn. The answer I got
: here was extremely helpful and just what I needed. I was fortunate
: enough to benefit from a discussion by some very talented programmers
: that I didn't even participate in. I think I understand the situation a
: lot better now, so I can automate Excel, and avoid distributing one file
: unnecessarily and potentially illegally. You may recall that the same
: newsgroup also had a reply strongly recommending I contact MS to resolve
: that issue. I consider myself fortunate to have received a better
: understanding of the problem, and a solution, without dealing with any
: phone support.

There is no "potentially illegal" about it. One of the many license
agreements specifically says you cannot. I do not recall which as it's been
sometime since I played around with office components, but I do recall
seeing the text specifically in my research.