Cater for unregistered DLL
 

Normally my VB6 ActiveX DLL should be registered in user's system, and a
reference set to it in my project. However, before running my main routine,
I want to ensure it is indeed registered and avert all the problems of a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb opens and the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at the top of
Module2.

If I only declare the DllRef at procedure level - no problem, but I do need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no difference if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Hi Peter,

How about use AddFromGUID?
In VBA you can use AddFromFile, but not sure this works the same in VB6.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Normally my VB6 ActiveX DLL should be registered in user's system, and a
reference set to it in my project. However, before running my main
routine,
I want to ensure it is indeed registered and avert all the problems of a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb opens and the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at the top
of
Module2.

If I only declare the DllRef at procedure level - no problem, but I do
need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no difference
if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Hi Bart, thanks for responding.

Although AddFromGUID might be one way to add a reference to
..ActiveVBProject.References that's not my problem. This reference would
definitely exist, assuming the dll is registered.

The problem is if for any reason the DLL is not registered on the system as
should have been by the install app. Eg, user forgets a dll is required,
thinks no problem to copy an ordinary looking xla to another system. That
can and does occur.

So I do want to test the dll is registered on the system. My open routine
and test is in a module that has no ref's of any kind to the dll. But if a
module level or public ref to the dll exists anywhere in the project, my
code breaks before having a chance to do anything.

I've tried playing around with conditional compilation without success.

FWIW, prior to the CreateObject(myDLL) test I described previously, I would
check a registry entry I would have set in the install routine confirming
the DLL was installed.

Regards,
Peter T

"RB Smissaert" wrote in message
...
Hi Peter,

How about use AddFromGUID?
In VBA you can use AddFromFile, but not sure this works the same in VB6.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Normally my VB6 ActiveX DLL should be registered in user's system, and a
reference set to it in my project. However, before running my main
routine,
I want to ensure it is indeed registered and avert all the problems of a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb opens and
the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at the top
of
Module2.

If I only declare the DllRef at procedure level - no problem, but I do
need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no
difference
if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Hi Peter,

Provided you know the file path, how about just running Regsvr32 in any
case, registered with Windows or not?
Maybe I still misunderstood.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart, thanks for responding.

Although AddFromGUID might be one way to add a reference to
.ActiveVBProject.References that's not my problem. This reference would
definitely exist, assuming the dll is registered.

The problem is if for any reason the DLL is not registered on the system
as
should have been by the install app. Eg, user forgets a dll is required,
thinks no problem to copy an ordinary looking xla to another system. That
can and does occur.

So I do want to test the dll is registered on the system. My open routine
and test is in a module that has no ref's of any kind to the dll. But if a
module level or public ref to the dll exists anywhere in the project, my
code breaks before having a chance to do anything.

I've tried playing around with conditional compilation without success.

FWIW, prior to the CreateObject(myDLL) test I described previously, I
would
check a registry entry I would have set in the install routine confirming
the DLL was installed.

Regards,
Peter T

"RB Smissaert" wrote in message
...
Hi Peter,

How about use AddFromGUID?
In VBA you can use AddFromFile, but not sure this works the same in VB6.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Normally my VB6 ActiveX DLL should be registered in user's system, and
a
reference set to it in my project. However, before running my main
routine,
I want to ensure it is indeed registered and avert all the problems of
a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb opens and
the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at the
top
of
Module2.

If I only declare the DllRef at procedure level - no problem, but I do
need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no
difference
if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Hi Bart,

If my test, run from the open event, indicates the DLL is not registered I
would attempt to find the dll in the current path or system folder. Then
register it, either with Shell(Regsvr32, fullpath&name) or using API's.
Would also need to tell user to restart Excel.

But - if the DLL is not registered I cannot do any of this because my code
will break immediately the first routine (open-event) starts to run. The
break occurs not in the open routine but highlights a public ref to the dll
in another module.

Regards,
Peter T


"RB Smissaert" wrote in message
...
Hi Peter,

Provided you know the file path, how about just running Regsvr32 in any
case, registered with Windows or not?
Maybe I still misunderstood.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart, thanks for responding.

Although AddFromGUID might be one way to add a reference to
.ActiveVBProject.References that's not my problem. This reference would
definitely exist, assuming the dll is registered.

The problem is if for any reason the DLL is not registered on the system
as
should have been by the install app. Eg, user forgets a dll is required,
thinks no problem to copy an ordinary looking xla to another system.
That
can and does occur.

So I do want to test the dll is registered on the system. My open
routine
and test is in a module that has no ref's of any kind to the dll. But if
a
module level or public ref to the dll exists anywhere in the project, my
code breaks before having a chance to do anything.

I've tried playing around with conditional compilation without success.

FWIW, prior to the CreateObject(myDLL) test I described previously, I
would
check a registry entry I would have set in the install routine
confirming
the DLL was installed.

Regards,
Peter T

"RB Smissaert" wrote in message
...
Hi Peter,

How about use AddFromGUID?
In VBA you can use AddFromFile, but not sure this works the same in
VB6.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Normally my VB6 ActiveX DLL should be registered in user's system,
and
a
reference set to it in my project. However, before running my main
routine,
I want to ensure it is indeed registered and avert all the problems
of
a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb opens and
the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at the
top
of
Module2.

If I only declare the DllRef at procedure level - no problem, but I
do
need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no
difference
if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Hi Peter,

In that case maybe you will either have to make a loader, another VB6 exe
that registers the dll and then loads your main VB6 app, or you need to take
care of this in the installer. This is quite easy with INNO.
I have used a combination of both, partly in a loader .xla and partly in the
INNO setup file.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart,

If my test, run from the open event, indicates the DLL is not registered I
would attempt to find the dll in the current path or system folder. Then
register it, either with Shell(Regsvr32, fullpath&name) or using API's.
Would also need to tell user to restart Excel.

But - if the DLL is not registered I cannot do any of this because my code
will break immediately the first routine (open-event) starts to run. The
break occurs not in the open routine but highlights a public ref to the
dll
in another module.

Regards,
Peter T


"RB Smissaert" wrote in message
...
Hi Peter,

Provided you know the file path, how about just running Regsvr32 in any
case, registered with Windows or not?
Maybe I still misunderstood.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart, thanks for responding.

Although AddFromGUID might be one way to add a reference to
.ActiveVBProject.References that's not my problem. This reference would
definitely exist, assuming the dll is registered.

The problem is if for any reason the DLL is not registered on the
system
as
should have been by the install app. Eg, user forgets a dll is
required,
thinks no problem to copy an ordinary looking xla to another system.
That
can and does occur.

So I do want to test the dll is registered on the system. My open
routine
and test is in a module that has no ref's of any kind to the dll. But
if
a
module level or public ref to the dll exists anywhere in the project,
my
code breaks before having a chance to do anything.

I've tried playing around with conditional compilation without success.

FWIW, prior to the CreateObject(myDLL) test I described previously, I
would
check a registry entry I would have set in the install routine
confirming
the DLL was installed.

Regards,
Peter T

"RB Smissaert" wrote in message
...
Hi Peter,

How about use AddFromGUID?
In VBA you can use AddFromFile, but not sure this works the same in
VB6.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Normally my VB6 ActiveX DLL should be registered in user's system,
and
a
reference set to it in my project. However, before running my main
routine,
I want to ensure it is indeed registered and avert all the problems
of
a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb opens
and
the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at the
top
of
Module2.

If I only declare the DllRef at procedure level - no problem, but I
do
need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no
difference
if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Hi Bart,

I already have an install routine that should register the DLL. Also an INNO
in preparation with earlier help from your good self.

As I've said, I'm only trying to cater for the scenario my xla gets loaded
without user using my install, or the dll subsequently becoming
un-registered.

I quickly tried moving the public ref to the DLL to a vba class, effectively
public once this class is instanciated. I now seem to be able to run a dll
test without the code blowing up, but need to test for implications.

More important things to do today though*, back tomorrow.

Regards,
Peter T

* only of interest to the cricketing world - off to the Oval for the last
day of the Ashes, interesting prospects in store!

"RB Smissaert" wrote in message
...
Hi Peter,

In that case maybe you will either have to make a loader, another VB6 exe
that registers the dll and then loads your main VB6 app, or you need to
take
care of this in the installer. This is quite easy with INNO.
I have used a combination of both, partly in a loader .xla and partly in
the
INNO setup file.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart,

If my test, run from the open event, indicates the DLL is not registered
I
would attempt to find the dll in the current path or system folder. Then
register it, either with Shell(Regsvr32, fullpath&name) or using API's.
Would also need to tell user to restart Excel.

But - if the DLL is not registered I cannot do any of this because my
code
will break immediately the first routine (open-event) starts to run. The
break occurs not in the open routine but highlights a public ref to the
dll
in another module.

Regards,
Peter T


"RB Smissaert" wrote in message
...
Hi Peter,

Provided you know the file path, how about just running Regsvr32 in any
case, registered with Windows or not?
Maybe I still misunderstood.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart, thanks for responding.

Although AddFromGUID might be one way to add a reference to
.ActiveVBProject.References that's not my problem. This reference
would
definitely exist, assuming the dll is registered.

The problem is if for any reason the DLL is not registered on the
system
as
should have been by the install app. Eg, user forgets a dll is
required,
thinks no problem to copy an ordinary looking xla to another system.
That
can and does occur.

So I do want to test the dll is registered on the system. My open
routine
and test is in a module that has no ref's of any kind to the dll. But
if
a
module level or public ref to the dll exists anywhere in the project,
my
code breaks before having a chance to do anything.

I've tried playing around with conditional compilation without
success.

FWIW, prior to the CreateObject(myDLL) test I described previously, I
would
check a registry entry I would have set in the install routine
confirming
the DLL was installed.

Regards,
Peter T

"RB Smissaert" wrote in message
...
Hi Peter,

How about use AddFromGUID?
In VBA you can use AddFromFile, but not sure this works the same in
VB6.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Normally my VB6 ActiveX DLL should be registered in user's system,
and
a
reference set to it in my project. However, before running my main
routine,
I want to ensure it is indeed registered and avert all the
problems
of
a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb opens
and
the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at
the
top
of
Module2.

If I only declare the DllRef at procedure level - no problem, but
I
do
need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no
difference
if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Do't add your DLL to references
And
Public pDllRef As object
And
Set pDdllRef =Createobject("MyDLL.Some"

--
bighea

-----------------------------------------------------------------------
bighead's Profile: http://www.excelforum.com/member.php...fo&userid=2704
View this thread: http://www.excelforum.com/showthread.php?threadid=46652

Cater for unregistered DLL
 

As I mentioned previously, sub classing the ref to a VB6-dll does appears to
work.

However it seems possible to achieve all the following in a VBA xls / xla

- A Reference to the DLL in tools / references (early binding)
- Public ref to the DLL in a normal module
- If the DLL is not registered, register the DLL (subject finding it)

I did this

In Project Properties, Conditional Compilation Arguments -
mbDllReg = 0

At top of the second added normal vba module

#If mbDllReg = False Then
Public myDLLref As Object
#Else
Public myDLLref As MyDLL.SomeClass
#End If

In the open routine, in the first module, check the dll is registered with
CreateObject. If not, register the DLL with Shell.

Effectively, with the above and just a little bit more, it seems possible
use early binding and have a public ref to the DLL, without even needing a
separate install app' to register the DLL.

Regards,
Peter T

"Peter T" <peter_t@discussions wrote in message
...
Hi Bart,

I already have an install routine that should register the DLL. Also an
INNO
in preparation with earlier help from your good self.

As I've said, I'm only trying to cater for the scenario my xla gets loaded
without user using my install, or the dll subsequently becoming
un-registered.

I quickly tried moving the public ref to the DLL to a vba class,
effectively
public once this class is instanciated. I now seem to be able to run a dll
test without the code blowing up, but need to test for implications.

More important things to do today though*, back tomorrow.

Regards,
Peter T

* only of interest to the cricketing world - off to the Oval for the last
day of the Ashes, interesting prospects in store!

"RB Smissaert" wrote in message
...
Hi Peter,

In that case maybe you will either have to make a loader, another VB6
exe
that registers the dll and then loads your main VB6 app, or you need to
take
care of this in the installer. This is quite easy with INNO.
I have used a combination of both, partly in a loader .xla and partly in
the
INNO setup file.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart,

If my test, run from the open event, indicates the DLL is not
registered
I
would attempt to find the dll in the current path or system folder.
Then
register it, either with Shell(Regsvr32, fullpath&name) or using
API's.
Would also need to tell user to restart Excel.

But - if the DLL is not registered I cannot do any of this because my
code
will break immediately the first routine (open-event) starts to run.
The
break occurs not in the open routine but highlights a public ref to
the
dll
in another module.

Regards,
Peter T


"RB Smissaert" wrote in message
...
Hi Peter,

Provided you know the file path, how about just running Regsvr32 in
any
case, registered with Windows or not?
Maybe I still misunderstood.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Hi Bart, thanks for responding.

Although AddFromGUID might be one way to add a reference to
.ActiveVBProject.References that's not my problem. This reference
would
definitely exist, assuming the dll is registered.

The problem is if for any reason the DLL is not registered on the
system
as
should have been by the install app. Eg, user forgets a dll is
required,
thinks no problem to copy an ordinary looking xla to another
system.
That
can and does occur.

So I do want to test the dll is registered on the system. My open
routine
and test is in a module that has no ref's of any kind to the dll.
But
if
a
module level or public ref to the dll exists anywhere in the
project,
my
code breaks before having a chance to do anything.

I've tried playing around with conditional compilation without
success.

FWIW, prior to the CreateObject(myDLL) test I described previously,
I
would
check a registry entry I would have set in the install routine
confirming
the DLL was installed.

Regards,
Peter T

"RB Smissaert" wrote in message
...
Hi Peter,

How about use AddFromGUID?
In VBA you can use AddFromFile, but not sure this works the same
in
VB6.

RBS


"Peter T" <peter_t@discussions wrote in message
...
Normally my VB6 ActiveX DLL should be registered in user's
system,
and
a
reference set to it in my project. However, before running my
main
routine,
I want to ensure it is indeed registered and avert all the
problems
of
a
missing ref.

I have something like this, which fails -

'Module1
Public mbDllReg As Boolean

Sub Auto_Open()
Dim obDLL As Object

On Error Resume Next

Set obDLL = CreateObject("MyDLL.Some")

If Not obDLL Is Nothing Then
Set obDLL = Nothing
mbDllReg = True
End If

End Sub

Sub StartHere()
If mbDllReg Then
DoMain
Else
MsgBox "DLL not registered"
End If
End Sub

'Module2
Public pDllRef As MyDLL.Some

Sub DoMain()

Set pDdllRef = New MyDLL.Some
' do stuff

End Sub

If I unregister the dll before opening my file, when the wb
opens
and
the
Open routine runs, the code breaks on "pDllRef As MyDLL.Some" at
the
top
of
Module2.

If I only declare the DllRef at procedure level - no problem,
but
I
do
need
a public ref to the DLL-class.

FWIW, Module1 is the first module added to the project, and no
difference
if
project is/not pre-compiled.

Any solution much appreciated,
Peter T

Cater for unregistered DLL
 

Thanks for the suggestion but I do want to use early binding.

Regards,
Peter T

"bighead" wrote in
message ...

Do't add your DLL to references
And
Public pDllRef As object
And
Set pDdllRef =Createobject("MyDLL.Some")


--
bighead


------------------------------------------------------------------------
bighead's Profile:
http://www.excelforum.com/member.php...o&userid=27048
View this thread: http://www.excelforum.com/showthread...hreadid=466525