References in MDE

[GeorgeMar]

I have read the threads of correspondence regarding
references not being able to be changed in MDE. However, I
am trying the fix the location of my reference to be
common on all workstations and having some difficulties.

I include a reference to two Kodak Ocxs in my application.
The problem initially was that the Ocxs are store on
different locations depending on the Windows version.

What I want to do is to place the Ocxs in a folder on the
C: drive of the workstation. On the development machine, I
do the same and hopefully it will also work on my client's
workstations.

What I have found, is that even though, I manage to change
the path of the Ocxs in the Tool/References sometimes, it
reverts to the old path and I get caught at the client's
site. Also, I have found that on some machines that there
are two listings of the same Ocx, one with the C: path
and the other with the System path.

What is the proper approach to redirecting the path of the
ocx?

Is there a way to redirect the path before compiling to
ensure that the MDE will always search on the C: drive?

many thanks
george

 

[Alex Dybenko]

What you have to make sure - that proper OCX version is registered on a PC
using regsvr32.exe. This is enough for access to make a correct reference to
it. these is no need to change path

 

[GeorgeMar]

Thank you Alex.

Is there a way to see a list of the OCXs that is
registered on the pc?

In a fresh installation, can the regsvr32 be run form a VB
exe that starts up my application setup, without having
the client running it independently?

many thanks
george

 

[Paul Overway]

The referenced files should be distributed, installed, and registered by
your setup package. If you create a proper installer, there is no need to
know what is installed on the client's PC. A proper installer will register
the OCXs automatically during the install.

 

[GeorgeMar]

Thanks Paul.

I am not using a third party setup package. My
installation program does a number of things, including
version control.

I need to know the best way to incorporate the
regsvr32.exe in my program; i.e are there any pitfalls to
lookout for.

regards

george

 

[Paul Overway]

You aren't making any sense...you say you're not using a 3rd party setup
package, and then you say "my installation program". Which is it? Or are
you trying to say you're wanting to develop some home grown installer? In
any case, regsvr32 is already installed as part of Windows. But honestly,
if you aren't familiar with regsvr32 and its purpose...and do not have a
solid understanding of references... you probably shouldn't be trying to
create your own installer. Those are very basic development topics. Best
case, you'll get a lot of support calls...worse case, you'll get calls from
former customers cussing you out because you screwed up their PC.

It would appear from your description that you are using a library (OCX)
that has been released in one or more versions that are not binary
compatible. If the libraries were binary compatible, you wouldn't see 2
listings...nor would you be having trouble with references (assuming the
library was properly registered when installed). In any case, you need to
distribute, install, and register (using regsvr32 or functions within your
installer) the libraries YOU are using in your app. And since it appears
that this library has been released in versions that are not binary
compatible, you must ensure that you never overwrite an existing
version...so, the OCX(s) should probably be installed in your app directory.

The pitfalls to watch out for...don't rely on a home grown installer without
very extensive testing. Don't rely on a PDW generated installer at all.
TEST TEST TEST. If you want less problems, you should be looking at a 3rd
party installer. You still need to test, but it will be less likely that
you'll mess up the customers PC.

 

[GeorgeMar]

Thank you.

-----Original Message-----
You aren't making any sense...you say you're not using a 3rd party setup
package, and then you say "my installation program". Which is it? Or are
you trying to say you're wanting to develop some home grown installer? In
any case, regsvr32 is already installed as part of Windows. But honestly,
if you aren't familiar with regsvr32 and its purpose...and do not have a
solid understanding of references... you probably shouldn't be trying to
create your own installer. Those are very basic development topics. Best
case, you'll get a lot of support calls...worse case, you'll get calls from
former customers cussing you out because you screwed up their PC.

It would appear from your description that you are using a library (OCX)
that has been released in one or more versions that are not binary
compatible. If the libraries were binary compatible, you wouldn't see 2
listings...nor would you be having trouble with references (assuming the
library was properly registered when installed). In any case, you need to
distribute, install, and register (using regsvr32 or functions within your
installer) the libraries YOU are using in your app. And since it appears
that this library has been released in versions that are not binary
compatible, you must ensure that you never overwrite an existing
version...so, the OCX(s) should probably be installed in your app directory.

The pitfalls to watch out for...don't rely on a home grown installer without
very extensive testing. Don't rely on a PDW generated installer at all.
TEST TEST TEST. If you want less problems, you should be looking at a 3rd
party installer. You still need to test, but it will be less likely that
you'll mess up the customers PC.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com





.

 

[david epsom dot com dot au]

An MDE can reference an OCX in two ways: you can
add a 'reference' to the vba project, and you can
embed an object on a form.

In some cases, embedding an object on a form will also
cause Access to add a 'reference' in the VBA project.
This should be removed after development is complete.

The VBA 'reference' is handy while doing development,
but it is not required for anything.
It gives you easy access to the names of properties
and methods of the object, but your Access forms don't
need it. You should remove the reference and, if your
code requires objects other than form objects, use
only 'late bound' objects. It means that you can't use
named constants (which is bad), but it makes your VBA
project robust, instead of fragile.


(david)