TOUGH PROBLEM: Multiple clients for a DLL server, and an OCX control!

Hi everyone!

I have a problem... I am using a COM DLL (lets call it DLL A) that contains a form with a Winsock OCX control on it.
The job of DLL A is to connect to a remote computer and send and receive text strings from it.

Another DLL (DLL B) is referencing DLL A, and accept event raises from it.

Furthermore, a Standard EXE application, (App EXE) is referencing both DLL A and DLL B.

So the situation is... that DLL B is using events from DLL A, while App EXE is using events from both DLL A and DLL B.

It is my understanding that upon runtime, two instances of the DLL A will be created, one in-process for DLL B, and another in-process for App EXE.

But suppose once the two instances are created, and then the Winscock OCX on DLL A wants to connect to a remote computer. If DLL B calls a public Sub on DLL A, instructing DLL A to send a message to the remote computer through its embedded OCX control, will App EXE also be able to send messages to the same remote computer through DLL A?

In other words, will the two instances of Winsock OCX be able to share the IP connection to the same computer? Or will it not be possible to do so?

This is like saying that if you have a nut and a bolt, and you suddenly create another nut, you cannot connect both to the same bolt, if you have the constraint of a 1-1 connection that you have with a single IP and a single TCP port.

To clarify the problem further:

DLL B -----> DLL A >>> Connected to REMOTE WINSOCK >>> IP 202.33.42.5 port 500

APP Exe -----> DLL A >>> Connected to REMOTE WINSOCK >>> I IP 202.33.42.5 port 500

SEE THE DISCREPANCY ABOVE: TWO INSTANCES OF THE DLL CANNOT CONNECT TO THE SAME IP AND SAME PORT!!!

Whats the solution? is it an Active X EXE Server instead of DLL A ?

u will have to clarify urself about following 3 things:
1)a dll is in process .and it is not necessary that a new object is created every time u refererence a class in the library(dll).it depends on the settings of the dll.

2)I suggest (i repeat only suggest) u rethink about the Model u r implementing ..becuase it doesn't need to be so complicated ..
one solution :
initially let dll A create a object .(i.e open a connection)
dll B and the exe use the same reference ..
look for some of the sample programs on this site and other implementing winsock .. and u mayn't have to code a line

....good luck ...
( of course u might have reasons to shout back at me ...)

i understand perfectly becuase I had to do the same thing..Here is the deal.

You will need the app to get the running isntance of dll A. You would normally do this with GetObject..but VB does not support this..Do the following to work around that.

First add this code to the main class of dll A

Code:

---

Option Explicit

Private Type GUIDs
    Data1 As Long
    Data2 As Integer
    Data3 As Integer
    Data4(0 To 7) As Byte
End Type

' Declares needed to register object in the ROT
Private Const ACTIVEOBJECT_STRONG = 0
Private Const ACTIVEOBJECT_WEAK = 1
Private Declare Function CLSIDFromProgID Lib "ole32.dll" (ByVal ProgID As Long, rclsid As GUIDs) As Long
Private Declare Function CoDisconnectObject Lib "ole32.dll" (ByVal pUnk As IUnknown, pvReserved As Long) As Long
Private Declare Function RegisterActiveObject Lib "oleaut32.dll" (ByVal pUnk As IUnknown, rclsid As GUIDs, ByVal dwFlags As Long, pdwRegister As Long) As Long
Private Declare Function RevokeActiveObject Lib "oleaut32.dll" (ByVal dwRegister As Long, ByVal pvReserved As Long) As Long

Private OLEInstance As Long

Private Sub Class_Initialize()
Dim typGUID As GUIDs
Dim lp As Long

OLEInstance = 0
' This code is responsible for creating the entry in the rot
lp = CLSIDFromProgID(StrPtr("VegaCOMM.clsSocket"), typGUID)
If lp = 0 Then
    lp = RegisterActiveObject(Me, typGUID, ACTIVEOBJECT_WEAK, OLEInstance)
End If

End Sub


Private Sub Class_Terminate()
' Once we are done with the main program, lets clean up the rot
' by removing the entry for our ActiveX Server

If OLEInstance <> 0 Then
    RevokeActiveObject OLEInstance, 0
End If

CoDisconnectObject Me, 0

End Sub

---

change "VegaCOMM.clsSocket" to your dllprojectname.dllclass

now you can use getobject from your exe

Dim a As Object

Set a = GetObject(,"youdllname.classname")

voila... a points to dll a and you can access it like you need..

Cander wowzers man thats some nifty code :)
thanks

uh oh...i have a problem...

chris wrote:
**********************************************
change "VegaCOMM.clsSocket" to your dllprojectname.dllclass

now you can use getobject from your exe

Dim a As Object

Set a = GetObject(,"youdllname.classname")

voila... a points to dll a and you can access it like you need..

*********************************************

as in the above example, i substituted projectname.classname for both of the required lines... but I sitll cannot access the methods of a. When i type "a." the list of methods does not pop up. What am i doing wrong???

You done get intellisense when using Getobject or createobject. but since you made dll A, you should know what the methods are.

In this case, how would the DLL'S event raises be programmed ion the Standard EXE ?

There lies the one problem with this...you cant get events to raise in teh standard exe for the dll..at least not anyway I have been able to find.