How to check for installed compnents?

[deko]

I'm trying to create an MSI in VS.NET that will check for installed Office
System components - so my MDE will only install if requirements are met.
I'm thinking about using VBScript to inspect Registry keys/values. Anyone
travel this road before? Other suggestions?

Thanks in advance.

[Don Leverton]

Hi,
Just an idea, but couldn't this be done using the FileSearch Object?

--
HTH,
Don
=============================
Use My*****@Telus.Net for e-mail
Disclaimer:
Professional PartsPerson
Amateur Database Programmer {:o)

I'm an Access97 user, so all posted code
samples are also Access97- based
unless otherwise noted.

Do Until SinksIn = True
File/Save, <slam fingers in desk drawer>
Loop

================================

"deko" <de*****@hotmail.com> wrote in message
news:PT*******************@newssvr25.news.prodigy. com...

I'm trying to create an MSI in VS.NET that will check for installed Office
System components - so my MDE will only install if requirements are met.
I'm thinking about using VBScript to inspect Registry keys/values. Anyone
travel this road before? Other suggestions?

Thanks in advance.

[deko]

> Just an idea, but couldn't this be done using the FileSearch Object?

I tried this:

Public Function CheckComponents() As Boolean
On Error GoTo HandleErr
Dim varExe As Variant
CheckComponents = False
For Each varExe In Array("WINWORD.EXE", "OUTLOOK.EXE", "EXCEL.EXE")
With Application.FileSearch
.NewSearch
.LookIn = "C:\Program Files\Microsoft Office\OFFICE11\"
.SearchSubFolders = False
.Filename = varExe
.MatchTextExactly = True
.FileType = msoFileTypeAllFiles
CheckComponents = IIf(.Execute(), True, False)
End With
If CheckComponents = False Then
MsgBox varExe & " is required for for this application to
function properly."
Exit For
End If
Next
Exit Function

But it's *very* slow. Still, the idea of checking for installed components
from within the app, rather than with an install routine, may be an
option...

[Trevor Best]

deko wrote:

Just an idea, but couldn't this be done using the FileSearch Object?

I tried this:

Public Function CheckComponents() As Boolean
On Error GoTo HandleErr
Dim varExe As Variant
CheckComponents = False
For Each varExe In Array("WINWORD.EXE", "OUTLOOK.EXE", "EXCEL.EXE")
With Application.FileSearch
.NewSearch
.LookIn = "C:\Program Files\Microsoft Office\OFFICE11\"
.SearchSubFolders = False
.Filename = varExe
.MatchTextExactly = True
.FileType = msoFileTypeAllFiles
CheckComponents = IIf(.Execute(), True, False)
End With
If CheckComponents = False Then
MsgBox varExe & " is required for for this application to
function properly."
Exit For
End If
Next
Exit Function

But it's *very* slow. Still, the idea of checking for installed components
from within the app, rather than with an install routine, may be an
option...

I put a timer function in yours similar to the one in my modified
version below:

Function CheckComps()
Dim varExe As Variant
Dim sngStart As Single
sngStart = Timer
CheckComps = False
For Each varExe In Array("WINWORD.EXE", "OUTLOOK.EXE", "EXCEL.EXE")
CheckComps = Len(Dir$("C:\Program Files\Microsoft
Office\OFFICE10\" & varExe)) > 0
If CheckComps = False Then
MsgBox varExe & " is required for for this application to
function properly."
Exit For
End If
Next
Debug.Print "CheckComps done " & Timer - sngStart

End Function

The result:
CheckComponants done 0.1875
CheckComponants done 0.1875
CheckComponants done 0.203125
CheckComponants done 0.1875
CheckComponants done 0.203125
CheckComps done 0
CheckComps done 0
CheckComps done 0
CheckComps done 0

Good old Dir$()

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Terry Kreft]

I realise these are first attempts but both are flwed to some extent as the
Office folder path is hardcoded.

If on the other hand you check the registry at
HKLM\Software\Microsoft\Office\{version}\{applicat ion}\InstallRoot\Path

Where
{version} is 8.0, 9.0, 10.0 etc.
{application} is Word, Outlook or Excel

This will tell you where the exe should be installed.
--
Terry Kreft
MVP Microsoft Access
"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...

deko wrote:

Just an idea, but couldn't this be done using the FileSearch Object?

I tried this:

Public Function CheckComponents() As Boolean
On Error GoTo HandleErr
Dim varExe As Variant
CheckComponents = False
For Each varExe In Array("WINWORD.EXE", "OUTLOOK.EXE", "EXCEL.EXE")
With Application.FileSearch
.NewSearch
.LookIn = "C:\Program Files\Microsoft Office\OFFICE11\"
.SearchSubFolders = False
.Filename = varExe
.MatchTextExactly = True
.FileType = msoFileTypeAllFiles
CheckComponents = IIf(.Execute(), True, False)
End With
If CheckComponents = False Then
MsgBox varExe & " is required for for this application to
function properly."
Exit For
End If
Next
Exit Function

But it's *very* slow. Still, the idea of checking for installed components from within the app, rather than with an install routine, may be an
option...

I put a timer function in yours similar to the one in my modified
version below:

Function CheckComps()
Dim varExe As Variant
Dim sngStart As Single
sngStart = Timer
CheckComps = False
For Each varExe In Array("WINWORD.EXE", "OUTLOOK.EXE", "EXCEL.EXE")
CheckComps = Len(Dir$("C:\Program Files\Microsoft
Office\OFFICE10\" & varExe)) > 0
If CheckComps = False Then
MsgBox varExe & " is required for for this application to
function properly."
Exit For
End If
Next
Debug.Print "CheckComps done " & Timer - sngStart

End Function

The result:
CheckComponants done 0.1875
CheckComponants done 0.1875
CheckComponants done 0.203125
CheckComponants done 0.1875
CheckComponants done 0.203125
CheckComps done 0
CheckComps done 0
CheckComps done 0
CheckComps done 0

Good old Dir$()

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[deko]

> If on the other hand you check the registry at

HKLM\Software\Microsoft\Office\{version}\{applicat ion}\InstallRoot\Path
Where
{version} is 8.0, 9.0, 10.0 etc.
{application} is Word, Outlook or Excel

This will tell you where the exe should be installed.

Good suggestion. What I really want to do is prevent installation of the
MDE if any of the Office programs are missing. If the MDE installs without
the other programs, the result is Missing References and ugly errors.

I've successfully created a basic MSI, and have a VBScript that checks those
registry locations - on the assumption the component is installed if the
InstallRoot\Path Key is not null, but getting the script into a Custom
Action in the Installer has been a real time suck. I'm new to creating
MSI's - but my version of Visual Studio can create them and that's what I've
been using. If I could figure out the Installer I'd be all set.

[Trevor Best]

Terry Kreft wrote:

I realise these are first attempts but both are flwed to some extent as the
Office folder path is hardcoded.

I don't try to be too clever when writing aircode or modifying someone
elses code for usenet purposes, had I been writing this in a real app I
would have used SysCmd(acSysCmdAccessDir), a bit easier than snooping
around the registry :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[deko]

> would have used SysCmd(acSysCmdAccessDir), a bit easier than snooping

around the registry :-)

I came up with this, but in testing it never ran - I just got the "Missing
Reference" errors. The start up form never had a chance to open. Oh well,
back to the Installer...

Anyway, thanks for the help.

Public Function CheckComponents() As Boolean
Dim varExe As Variant
Dim strApp As String
Dim blnQuit As Boolean
blnQuit = False
For Each varExe In Array("WINWORD.EXE", "OUTLOOK.EXE", "EXCEL.EXE")
CheckComponents = Len(Dir$(SysCmd(acSysCmdAccessDir) & varExe)) > 0
If CheckComponents = False Then
blnQuit = True
Select Case varExe
Case "WINWORD.EXE"
strApp = "Word"
Case "OUTLOOK.EXE"
strApp = "Access"
Case "EXCEL.EXE"
strApp = "Excel"
End Select
MsgBox "Microsoft " & strApp & " is required for for this " & _
"application to function properly.", vbCritical, " Microsoft " &
strApp & " Not Found"
End If
Next
If blnQuit Then DoCmd.Quit
Exit Function

[Trevor Best]

deko wrote:

would have used SysCmd(acSysCmdAccessDir), a bit easier than snooping
around the registry :-)

I came up with this, but in testing it never ran - I just got the "Missing
Reference" errors. The start up form never had a chance to open. Oh well,
back to the Installer...

Anyway, thanks for the help.

That's because you're using early binding still, you will need to
uncheck the references and use late binding (use early binding for
development to get intellisense, etc), then for example change:

Dim wb as new excel.workbook
wb.dosomthing

to

dim wb as object
set wb=createobject("excel.workbook")
wb.dosomthing
--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[David W. Fenton]

"Terry Kreft" <te*********@mps.co.uk> wrote in
news:7d********************@karoo.co.uk:

I realise these are first attempts but both are flwed to some
extent as the Office folder path is hardcoded.

If on the other hand you check the registry at
HKLM\Software\Microsoft\Office\{version}\{applicat ion}\InstallR
oot\Path

Where
{version} is 8.0, 9.0, 10.0 etc.
{application} is Word, Outlook or Excel

This will tell you where the exe should be installed.

Note that Access itself does not follow the same rules.

A97 uses:

HKEY_LOCAL_MACHINE, "SOFTWARE\Microsoft\Office\8.0\OfficeBin\Path

A2K uses:

HKEY_LOCAL_MACHINE,
"SOFTWARE\Microsoft\Office\8.0\Access\InstallRoot\ Path

OR

HKEY_LOCAL_MACHINE,
"SOFTWARE\Microsoft\Office\8.0\Common\InstallRoot\ Path

It's a pain. A real pain.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

Terry Kreft wrote:

I realise these are first attempts but both are flwed to some
extent as the Office folder path is hardcoded.

I don't try to be too clever when writing aircode or modifying
someone elses code for usenet purposes, had I been writing this in
a real app I would have used SysCmd(acSysCmdAccessDir), a bit
easier than snooping around the registry :-)

Wow, I feel dumb.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

deko wrote:

would have used SysCmd(acSysCmdAccessDir), a bit easier than
snooping around the registry :-)

I came up with this, but in testing it never ran - I just got the
"Missing Reference" errors. The start up form never had a chance
to open. Oh well, back to the Installer...

Anyway, thanks for the help.

That's because you're using early binding still, you will need to
uncheck the references and use late binding (use early binding for
development to get intellisense, etc), then for example change:

Dim wb as new excel.workbook
wb.dosomthing

to

dim wb as object
set wb=createobject("excel.workbook")
wb.dosomthing

And you'll want to have error correction in there to handle the lack
of Excel being installed.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

David W. Fenton wrote:

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

deko wrote:

would have used SysCmd(acSysCmdAccessDir), a bit easier than
snooping around the registry :-)
I came up with this, but in testing it never ran - I just got the
"Missing Reference" errors. The start up form never had a chance
to open. Oh well, back to the Installer...

Anyway, thanks for the help.

That's because you're using early binding still, you will need to
uncheck the references and use late binding (use early binding for
development to get intellisense, etc), then for example change:

Dim wb as new excel.workbook
wb.dosomthing

to

dim wb as object
set wb=createobject("excel.workbook")
wb.dosomthing

And you'll want to have error correction in there to handle the lack
of Excel being installed.

Isn't that the point of the thread? To check that Excel is installed
when first run?
--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Terry Kreft]

You're right Trevor that syscmd would work in an installed db but I thought
this thread was about installing it?

--
Terry Kreft
MVP Microsoft Access
"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...

Terry Kreft wrote:

I realise these are first attempts but both are flwed to some extent as the Office folder path is hardcoded.

I don't try to be too clever when writing aircode or modifying someone
elses code for usenet purposes, had I been writing this in a real app I
would have used SysCmd(acSysCmdAccessDir), a bit easier than snooping
around the registry :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[deko]

> Isn't that the point of the thread? To check that Excel is installed

when first run?

The Windows Installer, I think, is the best solution for this kind of thing.
I've set up a Launch Condition in the Installer that checks for the .exe
files - seems to work pretty well (I had thought this would require VBScript
in a Custom Action). The install aborts if a component is missing. The
joker in the pack is if the user did a custom install of Office (since I use
a hard-coded path to the exe). Reading the Path value in the InstallRoot
Key and using that in the Launch Condition may take some more tinkering.

The other issue is dealing with References - If I develop in Office 2003,
then my references are to the Office11 libraries. When I make the MDE,
these references are compiled into the app. So the app will only run with
Office 2003. I assume this means I will have to somehow down-rev the app
for Office 2002 and set References for the Office10 libraries if I want to
distribute to clients running Office 2002. So I have to offer 2 different
versions: one for Office 2002 and one for Office 2003. Is this correct?

.... anyone going to Mountain View tonight for the C# Roadshow?

[Trevor Best]

deko wrote:

Isn't that the point of the thread? To check that Excel is installed
when first run?

The Windows Installer, I think, is the best solution for this kind of thing.
I've set up a Launch Condition in the Installer that checks for the .exe
files - seems to work pretty well (I had thought this would require VBScript
in a Custom Action). The install aborts if a component is missing. The
joker in the pack is if the user did a custom install of Office (since I use
a hard-coded path to the exe). Reading the Path value in the InstallRoot
Key and using that in the Launch Condition may take some more tinkering.

The other issue is dealing with References - If I develop in Office 2003,
then my references are to the Office11 libraries. When I make the MDE,
these references are compiled into the app. So the app will only run with
Office 2003. I assume this means I will have to somehow down-rev the app
for Office 2002 and set References for the Office10 libraries if I want to
distribute to clients running Office 2002. So I have to offer 2 different
versions: one for Office 2002 and one for Office 2003. Is this correct?

... anyone going to Mountain View tonight for the C# Roadshow?

Just the lowest common denomiator is needed I think. If your app
references Exec10, then Access 2003 would be old enough and ugly enough
to work out that Excel11 will do.
--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

Terry Kreft wrote:

You're right Trevor that syscmd would work in an installed db but I thought
this thread was about installing it?

After reading deko's last response I see that's the case. D'oh!

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Don Leverton]

Hi Folks,

This conversation is quite a ways over my head, but I've been following this
thread thinking "I seem to remember something about a program that allowed
you to package all of the required libraries with your distribution". This
is probably similar to the MSI that Deko has been talking about?

Does your program actually require that Excel is installed, or just it's
libraries etc.? I really don't know a lot about the developer aspect and the
associated legalities. If all that is required is the library files, is it
legal to distribute them seperately, if they a dependency of another
application developed using a Microsoft application (Access)?

Anyway, the program that I'm thinking of is called Active Delivery. It
claims to be able to put you in control of the install paths and
modifications to the Windows Registry, etc. If you're interested (and you
guys will understand it better than I do for sure) have a look at:
http://www.activedelivery.com/ad/index.htm

===========
HTH, Don

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:py********************@karoo.co.uk...

You're right Trevor that syscmd would work in an installed db but I thought this thread was about installing it?

--
Terry Kreft
MVP Microsoft Access
"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...

Terry Kreft wrote:

I realise these are first attempts but both are flwed to some extent

as

the Office folder path is hardcoded.

I don't try to be too clever when writing aircode or modifying someone
elses code for usenet purposes, had I been writing this in a real app I
would have used SysCmd(acSysCmdAccessDir), a bit easier than snooping
around the registry :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[deko]

> This conversation is quite a ways over my head, but I've been following
this

thread thinking "I seem to remember something about a program that allowed
you to package all of the required libraries with your distribution". This
is probably similar to the MSI that Deko has been talking about?

Does your program actually require that Excel is installed, or just it's
libraries etc.? I really don't know a lot about the developer aspect and the associated legalities. If all that is required is the library files, is it
legal to distribute them seperately, if they a dependency of another
application developed using a Microsoft application (Access)?

I'm not sure how ActiveDelivery differs from the Windows Installer (i.e. an
msi package), but a key feature of this database is it's use of automation
to integrate with Word, Outlook, and Excel, so those apps need to be there.
The Windows Installer (as I am painfully aware) has a steep learning curve,
but is more than powerful enough for what I'm trying to do.

Caphyon offers a freeware wrapper for Windows Installer 2.0 that's great for
making simple msi's - http://www.advancedinstaller.com/download.html

When you build a Setup Project in Visual Studio, it creates an msi (both ver
2 and 3, I think), and also a setup.exe, which is nice. If you can figure
out the Conditional Statement syntax for Launch Conditions, and write
VBScript for Custom Actions, you've got everything you need. Still, some
will say InstallShield is the gold standard... if you've got the gold to buy
it...
http://www.installshield.com/products/comparison.asp

[David W. Fenton]

Trevor Best <nospam@localhost> wrote in
news:40**********************@auth.uk.news.easynet .net:

deko wrote:

Isn't that the point of the thread? To check that Excel is
installed when first run?

The Windows Installer, I think, is the best solution for this
kind of thing. I've set up a Launch Condition in the Installer
that checks for the .exe files - seems to work pretty well (I had
thought this would require VBScript in a Custom Action). The
install aborts if a component is missing. The joker in the pack
is if the user did a custom install of Office (since I use a
hard-coded path to the exe). Reading the Path value in the
InstallRoot Key and using that in the Launch Condition may take
some more tinkering.

The other issue is dealing with References - If I develop in
Office 2003, then my references are to the Office11 libraries.
When I make the MDE, these references are compiled into the app.
So the app will only run with Office 2003. I assume this means I
will have to somehow down-rev the app for Office 2002 and set
References for the Office10 libraries if I want to distribute to
clients running Office 2002. So I have to offer 2 different
versions: one for Office 2002 and one for Office 2003. Is this
correct?

... anyone going to Mountain View tonight for the C# Roadshow?

Just the lowest common denomiator is needed I think. If your app
references Exec10, then Access 2003 would be old enough and ugly
enough to work out that Excel11 will do.

But for the reference to work, doesn't the path have to be the same
for the Excel directory?

Late binding is still the way to go.

Then you could install the application even if Excel is not
installed, and the non-Excel dependent features could still be used.
With references, nothing at all is going to work, ever.

I can't see why anyone would use anything other than late binding,
except if they don't know any better.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"deko" <de**@hotmail.com> wrote in
news:Hj*******************@newssvr25.news.prodigy. com:

The Windows Installer (as I am painfully aware) has a steep
learning curve, but is more than powerful enough for what I'm
trying to do.

The MSI is garbage. It breaks way too easily.

My workstation simply won't install a number of applications, and
it's because the MSI is hosed for some reason. I have tried the
downloads from MS that are supposed to clean up and re-initialize
the MSI, and nothing seems to fix it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[deko]

> My workstation simply won't install a number of applications, and

it's because the MSI is hosed for some reason. I have tried the
downloads from MS that are supposed to clean up and re-initialize
the MSI, and nothing seems to fix it.

I've not used it enough to see any problems - the msi's I've created so far
work fine. What OS are you running? What are the alternatives?

[deko]

> Then you could install the application even if Excel is not

installed, and the non-Excel dependent features could still be used.
With references, nothing at all is going to work, ever.

So if I use late binding, then I don't need any references? If Excel (or
whatever) is not there, a friendly error message is all I need if I can
forget the references. But isn't there a performance hit with late binding?
I think I remember reading something like that and started checking those
little boxes...

[Trevor Best]

David W. Fenton wrote:

Trevor Best <nospam@localhost> wrote in
news:40**********************@auth.uk.news.easynet .net:

deko wrote:

Isn't that the point of the thread? To check that Excel is
installed when first run?
The Windows Installer, I think, is the best solution for this
kind of thing. I've set up a Launch Condition in the Installer
that checks for the .exe files - seems to work pretty well (I had
thought this would require VBScript in a Custom Action). The
install aborts if a component is missing. The joker in the pack
is if the user did a custom install of Office (since I use a
hard-coded path to the exe). Reading the Path value in the
InstallRoot Key and using that in the Launch Condition may take
some more tinkering.

The other issue is dealing with References - If I develop in
Office 2003, then my references are to the Office11 libraries.
When I make the MDE, these references are compiled into the app.
So the app will only run with Office 2003. I assume this means I
will have to somehow down-rev the app for Office 2002 and set
References for the Office10 libraries if I want to distribute to
clients running Office 2002. So I have to offer 2 different
versions: one for Office 2002 and one for Office 2003. Is this
correct?

... anyone going to Mountain View tonight for the C# Roadshow?
Just the lowest common denomiator is needed I think. If your app
references Exec10, then Access 2003 would be old enough and ugly
enough to work out that Excel11 will do.

But for the reference to work, doesn't the path have to be the same
for the Excel directory?

No, it's registered from whatever directory it's installed in. I know
A2K2 will upgrade an Excel9 ref to excel10 but for late binding it's
whatever version of Ecel is inatlled will pick it up since you only use
createobject("exec.workbook") or whatever and not any particular
version. You needn't really check for existence of excel.exe at this
stage. Just error trapping is needed if CreateObject() fails.
Late binding is still the way to go.

Then you could install the application even if Excel is not
installed, and the non-Excel dependent features could still be used.
With references, nothing at all is going to work, ever.

I can't see why anyone would use anything other than late binding,
except if they don't know any better.

Certainly makes the code more portable :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

deko wrote:

Then you could install the application even if Excel is not
installed, and the non-Excel dependent features could still be used.
With references, nothing at all is going to work, ever.

So if I use late binding, then I don't need any references? If Excel (or
whatever) is not there, a friendly error message is all I need if I can
forget the references. But isn't there a performance hit with late binding?
I think I remember reading something like that and started checking those
little boxes...

Only if you're a benchmark program or you call createobject() many times
in a loop (in which case you're not programming efficiently anyway as
you'd call it once outside the loop unless you wanted separate instances
in which case early or late binding wouldn't matter, you're gonna take a
performance hit when the OS hits that swapfile).

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

deko wrote:

My workstation simply won't install a number of applications, and
it's because the MSI is hosed for some reason. I have tried the
downloads from MS that are supposed to clean up and re-initialize
the MSI, and nothing seems to fix it.

I've not used it enough to see any problems - the msi's I've created so far
work fine. What OS are you running? What are the alternatives?

David is running CP/M 2.2 with a version of Gem that has been ported to
run on top of it, it's the only way he could get his old Access 97 to
stop feeling old :-)

Wise/Vise seems to be good with VB, etc, I've only ever used Office
developer for peddling mdbs to clients without Access, then I use
separate setups for all support dlls, ocxs, etc like the Richy control
I've mentioned elsewhere. It may mean running 2 or 3 setup programs for
each workstation but I'm not exactly peddling an off the shelf application.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[David W. Fenton]

"deko" <de**@hotmail.com> wrote in
news:vS******************@newssvr25.news.prodigy.c om:

Then you could install the application even if Excel is not
installed, and the non-Excel dependent features could still be
used. With references, nothing at all is going to work, ever.
So if I use late binding, then I don't need any references? . . .

Yes.
. . . If
Excel (or whatever) is not there, a friendly error message is all
I need if I can forget the references. . . .
Yes.
. . . But isn't there a
performance hit with late binding? . . .
Only on the first invocation, assuming you initialize an object
variable for the relevant application the first time you need it.
. . . I think I remember reading
something like that and started checking those little boxes...

It's certainly easier until you run into reference problems.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Trevor Best <nospam@localhost> wrote in
news:40**********************@auth.uk.news.easynet .net:

deko wrote:

Then you could install the application even if Excel is not
installed, and the non-Excel dependent features could still be
used. With references, nothing at all is going to work, ever.

So if I use late binding, then I don't need any references? If
Excel (or whatever) is not there, a friendly error message is all
I need if I can forget the references. But isn't there a
performance hit with late binding? I think I remember reading
something like that and started checking those little boxes...

Only if you're a benchmark program or you call createobject() many
times in a loop (in which case you're not programming efficiently
anyway as you'd call it once outside the loop unless you wanted
separate instances in which case early or late binding wouldn't
matter, you're gonna take a performance hit when the OS hits that
swapfile).

Well, if you don't re-use your object variable, you could have a
performance hit.

But if you re-use it the same way I re-use my global reference to
CurrentDB(), it shouldn't even be hard. CurrentDB works something
like this:

Private dbCurrent As DAO.Database

Public Function dbApp() As DAO.Database
If dbCurrent Is Nothing Then
Set dbCurrent = CurrentDB()
End If
dbApp = dbCurrent
End Function

Replace that with:

Private objWordPeristent As Object

Public Function objWord() As Object
If objWord Is Nothing Then
Set objWordPersistent = GetObject(, "Word.Application")
End If
objWord = objWordPersistent
End Function

Then you can use objWord repeately.

Of course, if you want to use multiple instances, that's different.

But once Word is loaded into memory, all additional late bound uses
of Word will be as fast as early bound uses.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"deko" <de**@hotmail.com> wrote in
news:4I******************@newssvr25.news.prodigy.c om:

My workstation simply won't install a number of applications, and
it's because the MSI is hosed for some reason. I have tried the
downloads from MS that are supposed to clean up and re-initialize
the MSI, and nothing seems to fix it.

I've not used it enough to see any problems - the msi's I've
created so far work fine. What OS are you running? What are the
alternatives?

Win2K. I've seen this kind of problem since the MSI was introduced.
The first widely distributed use of it was the Office 2K installer,
if I'm remembering correctly.

And it was well-known back then that it was very fragile.

And so far as I can see, it hasn't gotten any better.

But mostly, I just don't like having a system component on my
machine one which huge numbers of programs depend, but over which I
have absolutely no control.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[deko]

> Wise/Vise seems to be good with VB, etc, I've only ever used Office

developer for peddling mdbs to clients without Access, then I use
separate setups for all support dlls, ocxs, etc like the Richy control
I've mentioned elsewhere. It may mean running 2 or 3 setup programs for
each workstation but I'm not exactly peddling an off the shelf

application.

I've heard these are good installers:

http://sourceforge.net/projects/wix/

http://nsis.sourceforge.net/download/

The Wix installer sounds interesting - OSS from MS - beta 4 released last
week

[deko]

> But mostly, I just don't like having a system component on my

machine one which huge numbers of programs depend, but over which I
have absolutely no control.

When you say you have no control, that is, you have no way to edit the
underlying database in the Windows Installer Engine? There are other
installers out there that are more transparent, if that's the issue.
Nevertheless, if I want a Setup routine for my app (mde, or whatever), I
need to build an MSI package using some kind of authoring tool - is this not
correct? How else do you install?

[deko]

The C# roadshow at the Microsoft campus was uneventful except for the QA
session where suggestions were taken for improvements to "Whidbey", the next
version of Visual Studio. Some pony-tail in the back with 2 cell phones and
a pager on his belt raised his hand and suggested integration with Apache
and other Open Source products. The moderator immediately called security
and the miscreant was ushered out, muttering "fools! I'll destroy them all!"

[David W. Fenton]

"deko" <de**@hotmail.com> wrote in
news:01*******************@newssvr25.news.prodigy. com:

But mostly, I just don't like having a system component on my
machine one which huge numbers of programs depend, but over which
I have absolutely no control.
When you say you have no control, that is, you have no way to edit
the underlying database in the Windows Installer Engine? . . .

I'm not talking about the developer's point of view -- I'm talking
about the *user's* point of view.

There's historically been a problem with dueling MSI versions, which
can corrupt each other, or fail because of incompatibilities. And
the problem I'm having right now, well, I don't know where it comes
from, but it causes certain installers simply to quit and not tell
why. Perhaps that's because the installer script hasn't been written
to report more information (I can't find a log file with any useful
info, either), but there is nothing I can do about this Windows
component. I can't uninstall it. I can't tweak it. I can't tell
which version is installed or not. I can't control what files it
keeps and what it discards.
. . . There
are other installers out there that are more transparent, if
that's the issue. . . .
I'm not talking about an area where I have a choice, as I know of no
software that provides alternate installers.
. . . Nevertheless, if I want a Setup routine for my
app (mde, or whatever), I need to build an MSI package using some
kind of authoring tool - is this not correct? How else do you
install?

You seem to me to have an enormous capacity to misunderstand the
things I write.

I don't create installers. It's not part of my business.

All I'm saying is that when I'm installing software, I prefer it to
be a non-MSI installer.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc