A2K7 RT & references

[Stanley L.]

When an AC2007 app is deployed on a user machine having 2007 RT only, how are
the non-builtin references reconciled. Are they included in the ACCDR, the RT
files or must they be specifically placed/copied onto the user's PC? Thank
you in advance for your help.
Stanley L

 

[Rick Brandt]

When an AC2007 app is deployed on a user machine having 2007 RT only,
how are the non-builtin references reconciled. Are they included in the
ACCDR, the RT files or must they be specifically placed/copied onto the
user's PC? Thank you in advance for your help.
Stanley L

The latter. That is why it is best to not use any non-default
references. If you must use an external library use late binding so that
a reference is not required.

 

[Stanley L.]

Please educate me on the 'late binding' your referred to and how I implement
it. Or a reference I can read. Thanks.

 

[Albert D. Kallal]

Please educate me on the 'late binding' your referred to and how I
implement
it. Or a reference I can read. Thanks.

For the basic standard references, you don't have to do anything. It is when
you reference Excel, word etc. that you run into problems. The solution is
to
use what is late binding. this means that regardless of what version of word
or excel or whatever the user has your code will continue to run.

I mean, if you not automating word, or other applications, then you don't
those references anyway. So, unless you actually doing word, outlook excel
automaton, then late binding is not of any concern to you. However if you
*are* using some of these other applications, then late binding is MUST do.

This concept is explained here:

http://www.granite.ab.ca/access/latebinding.htm

 

[Stanley L.]

I'm a little confused. I've read about binding in the reference you stated
and in MS in MSDN.
I run a routine that lists all my references. Some I know where they apply
like I have some ADO code in a datafile linking procedure. Others like
MSO.dll I don't know where that is used but it must be somewhere othewrwise
it wouldn't be on the list. I can only assume that a user's PC has none of
the references and hence I must install them on his machine. Not doing so
will sooner or later produce an error whether early binding or late bginding.
You say that ignoring a reference using late binding will not produce an
error. I don't understand how that is possible if the user's pc does not have
the reference at all.

BTW I have a total of 13 references only 2 of which are builtins. How can a
missing reference not produce an error as you imply? I have in the past
gotten errors when a reference wasn't missing(was on the pc) but was not
checked in the reference list.

 

[Albert D. Kallal]

I'm a little confused. I've read about binding in the reference you stated
and in MS in MSDN.

You say that ignoring a reference using late binding will not produce an
error. I don't understand how that is possible if the user's pc does not
have the reference at all.

The above does not apply to the standard default references that access has
by default. These references will *always* exist in/on the target machine
because you've installed access to run the application.

I don't understand how that is possible if the user's pc does not
have the reference at all.

We're **ONLY** talking about references when your code uses external
applications (3rd party applications).

For example if you have some word automation in your application, and use
early binding, this will of meant that while in the code editor you'll go
into tools ->references and have added a reference to the word object
libary. It is this reference to that we're talking about getting broken if
it's missing on the target machine. So if you have a reference to word in
tools->references, and on the target machine word has not yet been
installed, you now have a broken reference and your code is going to break
and cause errors (in fact it will not even compile and run properly on the
target machine).

However if you change your "word" code to what is called "late binding",
then you will NOT use nor have a reference in the tools-->references setting
to word. Since you don't have a reference to word in the settings for your
code, then it can't break your code if word is missing on the target
computer.

So, the simple story here is that late binding lousy to automate a other
applications without using tools->referes to that external application such
as word, outlook etc...

So if you're using any of the standard or default references that access has
set by default, I've never seen any these break. Furthermore no one here is
suggesting to use late binding for the built in or standard references that
MS access has set by default. Furthermore as mentioned the standard default
set of references that access has will ***always*** be installed on the
target machine when either the runtime or the full version of access is
installed.

The breakage to the references we talking about is ***ONLY*** for external
programs and applications that are not part of MS access.

if you want to determine the absolute minimum or basic settings for MS
access references, simply create a blank acccDB data base and then go into
the code editor and see what the references are. This will give you what
your absolute minimum references are for an application that will
successfully run on a targer computers without breakage. In your case if
you're using the ADO object library, that is likely the ONLY additonal
referce settign you need.

On my computer when I create a blank database and 2007, I see the following
references:

Visual basic for Applications
Microsoft access 12.0 object libary
OLE Automation
Microsoft office 12.0 Access database engine object

That is it...4 refs.

So the above is the absolute minimum number of references you'll need to run
correctly. In your case if you're using the ADO object library, then that
would be the one extra reference you have to add. and you can be absolutely
sure, almost 100% sure that ADO will be installed on the target machine, in
fact I think it's part of the windows xp/vista install and not even part of
MS access.

So, if you have any more references than the above, then you have to ask
yourself why are those references there? In other words you don't want to
make a reference to anything in your tools->references setting that you
don't need.

Virtually all of the above references will be installed on the target
computer because the above parts are what MS access installs on the target
machine. The suggestion to use late binding is only for when you're going to
do some automation of other applications that are not part of the basic
ms-access installation.

 

[Albert D. Kallal]

So, the simple story here is that late binding lousy to automate a other
applications without using tools->referes to that external application such
as word, outlook etc...

oppos...sorry, that should read:

So, the simple story here is that late binding allows you to automate other
applications without using tools->references to that external application
such as word, outlook etc...

 

[Rick Brandt]

I'm a little confused. I've read about binding in the reference you
stated and in MS in MSDN.
I run a routine that lists all my references. Some I know where they
apply like I have some ADO code in a datafile linking procedure. Others
like MSO.dll I don't know where that is used but it must be somewhere
othewrwise it wouldn't be on the list. >

Bad assumption. While you are developing it is not hard to experiment
with certain controls in the "Additional Tools" area and add references
to your project. Even if you don't ultimately use those tools the
references will still be there. You should un-check any reference you
aren't sure of and then see if your project will still compile. If it
does then you do not need that reference.

I can only assume that a user's
PC has none of the references and hence I must install them on his
machine.

One problem here is that many references that might end up in your
project could be to libraries that you are not legally allowed to
distribute to other users. Just because they are installed on your PC
does not guarantee that you have distribution rights.

Not doing so will sooner or later produce an error whether
early binding or late bginding. You say that ignoring a reference using
late binding will not produce an error. I don't understand how that is
possible if the user's pc does not have the reference at all.

If the user does not have that library installed and you use late binding
then the code that calls that library *will fail*. The difference is
that with late binding the rest of your project will still work. A
missing reference causes many code routines to bomb, even though they
have nothing at all to do with the missing library. In many case the
project becomes completely unusable.

Another big adantage of late binding is that it is largely version-
neutral. If you automate Word your code only requires that the user have
Word installed. If you use early binding they must have the same exact
same version installed (even service packs in many cases) as you have on
your development machine.

BTW I have a total of 13 references only 2 of which are builtins.

13? Unless you are in a tightly controlled corporate environment where
nearly perfect consistency is maintained concerning installed software
(and versions of same) you have very little chance of making this project
work for multiple users.

 

[Stanley L.]

Thanks Albert & Rick. I marvel at you MVPs and your expertise.
I'm beginning to understand. Of the 13 references I have 2 are builtins, 2
are ActiveXs I use and 1 is for ADO code that I use. The remaining 8 I will
test their need by unchecking them and seeing if the app compiles. I assume
you are talking of the compile option in the VBIDE menu and not the compiling
in making an ACCDE.

One thing not clear in my mind is how do I implement late binding. What is
the code to do so or is it other than code?

On the legal issue of whether a reference file can be installed on a user's
PC, I respect the issue. I only want to do what is right. But in reality, how
can I know what can or cannot be installed on a user's PC. I guess I can say
that anything copyrighted cannot be installed on a user's PC. That would be
safe but that would also exclude everything because everything is
copyrighted. From another point of view, MS intends that RT2007 be used and
by inference everything needed to make RT2007 work is MS intentions....This
may be too presumptious and wrong but I'm at a loss to know what is right. If
being precise about what references are truly needed on a user's PC
eliminates any legally-questionable files, then that is the optimum. You
appreciated assistance to achieve that is the ultimate best and is my goal.

 

[Douglas J. Steele]

Tony Toews has an introduction to the topic of late binding at
http://www.granite.ab.ca/access/latebinding.htm

In a nutshell:

1) Remove the reference
2) Ensure that you declare the automation variables As Object instead of,
for instance As Excel.Application
3) Ensure that you instantiate the automation objects using CreateObject or
GetObjecet instead of using New
4) Ensure that you provide values for all intrinsic constants included in
the reference you removed

 

[Albert D. Kallal]

But in reality, how
can I know what can or cannot be installed on a user's PC.

We only talking about 3rd party controls. And, most activeX controls have a
license scheme built in (this goes all the way back to windows 3.1).

So, you install application cool accounting system, and it has several
activeX
controls that you started using in your access application, you find that if
you copy those activeX controls to another computer they likey will not
work....

From another point of view, MS intends that RT2007 be used and
by inference everything needed to make RT2007 work is MS intentions.

Correct. The **only** issue in terms of references and licensing was in
regards that some of your 3rd party controls MAY NOT be licensed or have
been
purchased by your for purposes of copying. We were NOT referring to any of
the standard built in controls and default references that access has, we
were ONLY TALKING about 3rd party controls that don't come with ms-access.

So, tithe point being made here is if you started using a bunch of 3rd party
activeX controls, don't assume just because they are on your machine that
you have the legal rights to copy those 3rd party controls to other
computers. Also note that the access runtime will NOT install those 3rd
party controls for you, you have to include them in a separate install along
with a installer that correctly installs and registers those 3rd party
controls.
(useally the installer that came with the 3rd party contorls that you
purchased).

If you are not using any 3rd party controls, then this is simply not an
isuse for
you...

 

[Rick Brandt]

So, tithe point being made here is if you started using a bunch of 3rd
party activeX controls, don't assume just because they are on your
machine that you have the legal rights to copy those 3rd party controls
to other computers.

In fact you might not even be licensed to use them in Access on your own
PC. Some of those controls are licensed to be used ONLY by the software
that installed them. Certainly a great many would only be supported for
that.

 

[Tony Toews [MVP]]

We're **ONLY** talking about references when your code uses external
applications (3rd party applications).

For example if you have some word automation in your application, and use
early binding, this will of meant that while in the code editor you'll go
into tools ->references and have added a reference to the word object
libary. It is this reference to that we're talking about getting broken if
it's missing on the target machine. So if you have a reference to word in
tools->references, and on the target machine word has not yet been
installed, you now have a broken reference and your code is going to break
and cause errors (in fact it will not even compile and run properly on the
target machine).

However if you change your "word" code to what is called "late binding",
then you will NOT use nor have a reference in the tools-->references setting
to word. Since you don't have a reference to word in the settings for your
code, then it can't break your code if word is missing on the target
computer.

Also your reference is set to a specific version of Word or Outlook or
whatever. Using late binding means that it's no longer version
specific. This helps a great deal when half the users have upgraded
their Office to a newer version and half have not yet been upgraded.

Visual basic for Applications
Microsoft access 12.0 object libary
OLE Automation
Microsoft office 12.0 Access database engine object

Someone a while back, unknown universe stated they removed the OLE
Automation reference and never had a problem. However I wouldn't
recommend that.

Also, in one highly unusual situation, I used late binding to DAO.
However this was in VB 6.0 and was in the Auto FE Updater as I
attempted to access the latest version of DAO/ACE on the client's PC.
(I didn't put in any logic for the DAO which comes with A1.0/1.1 and
haven't had any complaints.)

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Stanley L.]

Thanks Rick and Albert. I am absorbing your knowledge like a dry sponge
absorbs water.

I have two ActiveXs that were purchased with full distribution rights but it
goes deeper than that and Albert hinted to that with "most activeX controls
have a license scheme built in ". Let me explain more thoroughly for those
readers who may be new to this subject. To use an ActiveX in design mode the
license file for the ActiveX must be in the same folder. To be more clear in
my case. I have, say, an encryption ActiveX that is placed on a form in
design mode. If the license is not present in the folder that placing will
not result in a functioning ActiveX. As I understand it those are the rules
everyone uses in ActiveX making and distribution. So the license allows me to
incorporate that ActiveX in my designs. When I send my program to a user, I
install and register the ActiveX on his machine but I do not install the
license file on his machine. All that makes the ActiveX readily available to
satisfy the Reference for Access. When I buy the ActiveX, I am licensed to
design the ActiveX into an unlimited number of applications and/or users but
I am not licensed to distribute the license file. To do so would be the
equivalent of selling another person's product.
I'm sure there are likely many options and variations on how one licenses
ActiveXs. That's a source-seller's perogative. My instincts tell me that the
way I described my specific ActiveX is likely how most of the sold ActiveX's
are controlled to avoid abuse.

In my 13 references, only 2 are what Albert refers to as 3rd party and those
are being handled properly as described above. In distributing my app I will
handle those 2 ActiveXs the same as any other file such as a CHM help file
except my code will have to know where they are (like in the Windows\system
folder) and I will have to register them with a RegEdit file. This is why I
use Inno Install in lieu of the MSI installer.

In summary for my case, I will test and try to eliminate as many references
as possible and those that I can't will be candidates late binding (assuming
I can learn how) or for installing on the user's PC since thay are not 3rd
party items. BTW, a number of the references are DLLs. Am I correct that OLB,
TLB and OCX files are considered ActiveX files?

Thanks again for your help and knowledge.

 

[Albert D. Kallal]

I have two ActiveXs that were purchased with full distribution rights but
it
goes deeper than that and Albert hinted to that with "most activeX
controls
have a license scheme built in ". Let me explain more thoroughly for those
readers who may be new to this subject. To use an ActiveX in design mode
the
license file for the ActiveX must be in the same folder.

The above is not the normal case for activeX controls. Perhaps this
is some design or part of the activeX control you purchased, but that has
NEVER been the case for the vast majority of ActiveX controls. You don't
have to install them in the same directory as your running file (nor does
some type of license file need be installed in the same dir either).

In *most* cases as long as the activeX control is installed and registered
on your computer then when you go tools->references you will see that
activeX control appear in that VERY long list. Note that VERY long list is
all of the activeX components installed on your computer. You can use anyone
object from that very long list and none of those objects are in your
current
directory of the access application, and none require a license file. If
the activeX control has no licensing restrictions, then you can freely copy
it to another computer and simply register it. That copy restrictions is not
tied to some other license file.

If the activeX controls DOES requite a license on the target computer, then
the compiler such as VB6, c++ or whatever will actually imbed the license
part of the activeX control into the resulting .exe or .dll code you create
with that compiler. When the application tries to load the activeX control,
that control will not work unless it finds the licenses **inside** of the
..exe trying to execute that activeX. So, this is generally how the licensing
works (and, it means that other applications on the target computer will not
be able to use the activeX control).

With ms-access, since we not producing .exe files, then I have no idea where
the license key resides, and I suspect that during the registering process
the activeX control has to be attached to something (likely some clsid in
the
registry..and that comes from using an installer). In fact, this quite much
means that the standard licensing controls for activeX can't be used for a
mdb or accdb file. In other words, I can't see how the activeX can be tied
ONLY to your application when using ms-access. It not really possible to do
so. (However I suspect it could be attached to say that the activeX
will ONLY run from msacces.exe file).

Note that Microsoft changed the name activeX to "com" object automaton, and
they both really the concept and technology now (you can very much
interchange the name activeX or "com" object when speaking about this type
of object code...

As I understand it those are the
rules everyone uses in ActiveX making and distribution.

No, that not the rules even for the general computer industry.

Also, note that access will setup references for you anytime you drop in an
activeX control on a form...

Try the following:

Bring up a form in design mode, and lets add the calendar control to your
form.

So, when your form is in design , click on the activeX option on the ribbon
(design tab).

then, scroll down to the

Calendar control 12.0

(the above control is an optional control that ships with ms-access 2007, if
the above is not in the above list, then you have to grab your original
access 2007 install disk and install this optional component ).

Hopefully it is installed...simply select the control form the listbox, and
then hit ok..you see the calendar control on your form. Now, save the form.
Now jump into the code editor (ctrl-g). Now go tools->references ...and you
will see a a reference to the calendar control!!!

So, anytime you place activeX control in a form, ms-access will automatic
create and place the reference for you in the tools->reference list from
the
code editor...

BTW, a number of the references are DLLs. Am I correct that
OLB, TLB and OCX files are considered ActiveX files?

Usually ocx, olb are, but not necessarily .dlls. Many types of .dll's are
simply what we call static library code that is NOT written to activeX/com
standards. That means the this .dll code can be run (called) from your
application , but you not talking to this code via "com" automaton. This is
like
calling a subroutine in some code as opposed to automaton of some code like
when automaton word.

A common example seen in these newsgroups is Stephens pdf creator software.
That is a .dll, but not a automaton object. The same goes for the MANY cases
when you call windows api code. You simply calling a library of code that
sits
in a .dll file, but are not using automaton.

so, in Stephens code you see a definitions like:

Public Declare Function ConvertUncompressedSnapshot Lib "StrStorage.dll" _
(ByVal UnCompressedSnapShotName As String, _
ByVal OutputPDFname As String, _
Optional ByVal CompressionLevel As Long = 0, _
Optional ByVal PasswordOwner As String = "", _
Optional ByVal PasswordOpen As String = "", _
Optional ByVal PasswordRestrictions As Long = 0, _
Optional PDFNoFontEmbedding As Long = 0 _
) As Boolean

Note how the above api function defines the .dll in the above as
StrStorage.dll. These types of .dll's do NOT need to be registered on one's
computer.

The above requires that the .dll libraries be installed in the
windows\system32 folder. If it not found there, then the current .exe dir is
used (in our case that would be the location of ms-access.exe file, not your
accDB/mdb file).

In my case, for my access winZip library, I as a developer made efforts and
you don't have to copy my .dlls to the windows system32 dir or the
ms-access.exe dir. The .dlls simply have to be in the same dir as the
mdb/mde/accdb/accde file and this was done on purpose (and I got the idea
from Stephens code which also does this). You can grab my zipping example
here:

http://www.members.shaw.ca/AlbertKallal/zip/index.htm


There is some reading on licensing of activeX controls here:

http://msdn.microsoft.com/en-us/library/aa751973(VS.85).aspx

 

[David W. Fenton]

But in reality, how
can I know what can or cannot be installed on a user's PC.

It's pretty simple:

If you haven't acquired a developer's license that explicitly allows
redistribution, then you can't redistribute it.

In other words, anything outside the Access runtime is off limits.

Which is exactly what people have been telling you in regard to late
binding.

 

[David W. Fenton]

Note that Microsoft changed the name activeX to "com" object
automaton

I thought it was:

OLE -> COM -> ActiveX

And now that ActiveX controls have gained such a bad name, everyone
has reverted to the more neutral COM.

At least, that's the way I interpret what I recall.

 

[David W. Fenton]

Someone a while back, unknown universe stated they removed the OLE
Automation reference and never had a problem. However I wouldn't
recommend that.

I *always* remove the OLE reference, as I never, ever use anything
that it provides -- it's not a general library, but one that adds
features that none of my Access apps have ever used.

 

[Stanley L.]

Albert, thanks for straghtening me out on ActiveX usage. I think I was
misinformed by others sources. I stand corrected.
Rick's words that with 13 references "you have very little chance of making
this project work for multiple users" really got my attention since I wasn't
aware of the true complications excessive references can cause. I have used
the suggestion of removing a reference and compiling to see if the reference
is truly needed. 13 references have been reduced to 8. 4 of those 8 are 2
builtins plus 2 for ActiveXs I use. That leaves 4 for further consideration
such as late binding and/or code modification. Of the 4, 2 are related to ADO
coding (ADODB and ADOX); 1 is related to Office ribbon components; and the
fourth and last 1 is related to Office data access objects (DAO).

Based on your experience and expertise, should I work with coding or late
binding to try to reduce the later four references even further? Perhaps
using late binding would be a good learning experience. Douglas has given
some good guidance on doing this. Any comments anyone?

 

[Tony Toews [MVP]]

I *always* remove the OLE reference, as I never, ever use anything
that it provides -- it's not a general library, but one that adds
features that none of my Access apps have ever used.

Ahh, ok. Good to know there is someone credible who has done that.

Thanks, Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/