D
Dim
I've come up with somewhat "different" solution to the issue of external
ocx'es.
What i managed to do is to bring the ocx along INSIDE the database and
extract it when needed
Look at the code.
Here's short description
When deveolping the DB i have created an additional table with only one row
where one field is an OLE Object
You are hopefully familiar with binary operations and OLE Object field.
So before i distributed my DB i created a simple function ('commented one in
the code') which i ran once
and which took the path of the OCX i used, opened file in binary mode, read
in as a byte array
and threw it into that OLE Object field.
Now i have the OCX as a binary data inside the database.
All what's left was to create a function which is run by a Autoexec macro
that checks if my OCX is already
installed on the system where db is running. This is done by On Error and
CreateObject.
If CreateObject succeeds then i can be pretty sure that everything is ok.
If not, then i jump to next function where following happens;
A byte array created and filled with binary data of my ocx from OLE Object
field
File (ocx) is saved in the same folder as database. Then ShellExecute
RegSvr32, register the OCX and the job is done ;-)
if you have a startup form that uses the OCX, you can remove it from Startup
options in Access and open it after OCX processing
is finished instead. that way you assure that form will open with a working
control.
Check out the code for all this btw.. you are free to use code however
you wish.
http://www24.brinkster.com/diman1/dynocxreg.zip
Code is virus checked, but you are encouraged to test it again with your
antivirus.
ocx'es.
What i managed to do is to bring the ocx along INSIDE the database and
extract it when needed
Look at the code.
Here's short description
When deveolping the DB i have created an additional table with only one row
where one field is an OLE Object
You are hopefully familiar with binary operations and OLE Object field.
So before i distributed my DB i created a simple function ('commented one in
the code') which i ran once
and which took the path of the OCX i used, opened file in binary mode, read
in as a byte array
and threw it into that OLE Object field.
Now i have the OCX as a binary data inside the database.
All what's left was to create a function which is run by a Autoexec macro
that checks if my OCX is already
installed on the system where db is running. This is done by On Error and
CreateObject.
If CreateObject succeeds then i can be pretty sure that everything is ok.
If not, then i jump to next function where following happens;
A byte array created and filled with binary data of my ocx from OLE Object
field
File (ocx) is saved in the same folder as database. Then ShellExecute
RegSvr32, register the OCX and the job is done ;-)
if you have a startup form that uses the OCX, you can remove it from Startup
options in Access and open it after OCX processing
is finished instead. that way you assure that form will open with a working
control.
Check out the code for all this btw.. you are free to use code however
you wish.
http://www24.brinkster.com/diman1/dynocxreg.zip
Code is virus checked, but you are encouraged to test it again with your
antivirus.