Catch 22 problem.

[Andrew Smith]

I have written an application used for statistical process control (SPC).
Currently the SPC charts are generated by shelling out to an external
application, which is rather a slow process. Recently I have obtained some
ActiveX controls for generating the charts, and have incorporated these into
the application.

I have a form that launches the SPC charts, and this is set up so that it
will either shell out to the SPC program or will open the form holding the
ActiveX controls, depending on the value of a function that detects whether
the ActiveX controls are available.

All this works fine on my machine where the ActiveX controls are installed.
However there is a bug that causes it to fail on machines without the
ActiveX controls, and I can't locate the bug! If I try and debug the code on
a machine without the ActiveX controls installed I get compile errors
because the ActiveX controls are not installed. On my machine I can't
reproduce the error because it does not occur if the ActiveX controls are
installed.

I'd appreciate any advice on what to do about this. My original plan was to
create a single front end that would function whether or not the ActiveX
controls were available. However, perhaps it would be better to create two
different front ends, even though I'd rather avoid this to make maintenance
easier.

 

[Robert Taylor]

I had a problem similiar to this once because the
computers I was attempting to run the database on did not
have the same DLL files as the computer I created the
database on. In order for the database to run on those
computers I had to update the reference files in question.

Also, just curious, but have you tried using the charts
that are already in Access?

Robert

 

[Scott McDaniel]

This isn't a "bug". If the Activex control isn't installed on the target
machine, then there is no way your application will run in that environment.
Your frontend contains a reference to the control, which is naturally
missing, and missing references are a leading cause of installation
troubles. No bug at all ... just behaving the way you would expect.

In short, you must install the Activex controls on the target machine. Did
you purchase these controls? If so, you most likely received a distribution
license (and if you didn't, well, you're stuck with a bunch of nifty
controls that will run on your machine and noone elses, unless you want to
violate the EULA).

Note also that is this is done in Access, get ready for some fun!!! Unless
those controls have been specifically designed to run in the Access
environment, you're in for a wild and hairy ride ... or should I say
hairless, cause you'll end up pulling out handfuls of the same before you
get those controls to behave properly!!!

 

[Andrew Smith]

I guess you must be right. I had thought that the presence of the ActiveX
controls would not matter provided the forms that contain them and any
modules that refer to them are not loaded. This should be the case on
machines that do not have the controls installed, but I still get these
errors.

Currently I have the controls for evaluation only and only have a single
licence. Hopefully I will be able to obtain enough licences for all the
users in the future, but I had hoped that I could keep the application
working even on machines that do not have the controls installed. It looks
like I'll need to keep two versions of the front end for this.

As far as I can see the controls do behave properly - at least I've had no
problems with the tests I've done on my machine. AFAIK they have not been
produced specifically for Access - all the documentation examples are for
VB. Why do you think I should have problems - I'd like to know before I get
any further down this path!

Andrew

 

[Andrew Smith]

Thanks for the reply.

I have made use of the charts in Access in parts of the application.
However, the SPC controls have a number of advantages - in particular they
carry out all the statistical calculations, display control limit lines and
show targets and/ or specifications. They will also produce such things as
CUSUM and exponentially weighted moving average charts with no additional
programming. I suppose I could do all this via queries, but I really don't
fancy doing it, and it would be a mammoth task to reproduce all the
functionality that is offered by these controls.

That said, I doubt if many of the users will make use of all of this ...

 

[Scott McDaniel]

No, this shouldn't be the case on machines that do not have the controls
installed. When you insert an Activex control on a form, it makes a
reference to the control's library in the Access container (check this on
your develpment machine) ... when you copy your database to another machine,
Access will attempt to resolve your references, and will not, of course, be
able to resolve the reference to the control you're using, since the library
won't be available.

If the controls behave properly on your machine, they **may** behave
properly on other machines. There are many, many issues surrounding Activex
controls in Access apps ... even the ones that ship with the Developer
edition of Access, which are supposedly designed to work with Access, give
troubles. I would encourage you to Google on this issue ("ms access activex
troubles" or something similar) and familarize yourself with these issues.
I'm not saying you can't use Activex controls on forms (I use several), but
you need to be aware of the pitfalls associated with them. For one thing,
make sure you turn off Name AutoCorrect in your database ... according to a
recent article in Access Advisor, it can cause troubles with forms that
contain Activex controls.

Also, before you decide to purchase these controls, see if the makers supply
runtime licenses for them ... that way, you don't have to worry about
additional licenses when you distribute your app.