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

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

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

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

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

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

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

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