winsock control in active x dll 2

[griffitd]

How do i used the winwock control in an Active X dll.
I have no forms

Thanks

 

[BobRodes]

You can put a form in an ActiveX DLL, and make it invisible. If you do this, you will get better performance if you select "unattended execution" in the properties page. This property notifies the compiler that it doesn't have to listen for UI-based events, which saves overhead.

 

[strongm]

Why do that, when you can add Winsock as reference rather than as a control?

 

[BobRodes]

Well, that's true, and it's a better solution, but then you aren't using the winsock control any more, are you?

 

[strongm]

Yes, you are. You just aren't using the visual interface. There are a number of controls for which you can do this with VB.

 

[BobRodes]

Well, I'll be darned. I never liked putting a common dialog control on a form, seemed less than clean to me. So, I just referenced comdlg32.ocx from the references menu, and put up this code:

Private Sub Command1_Click()
Dim cdl As CommonDialog
Set cdl = New CommonDialog
cdl.ShowOpen
End Sub

And it works perfectly. Rack up another star.

I should mention, though, that the actual references menu support of this is a bit buggy. I went to the references menu, browsed to comdlg32.ocx, and selected it. It appears on the bottom row as "Microsoft Windows Common Dialog Control", with the box checked. I hit ok. When I go back in, the box is unchecked. Checking it again and hitting Ok gives the "name conflicts with existing module, project, or object library" error. When I then leave the references menu and come back in, the line item has disappeared. Browsing to the file again gives the name conflicts error also. Going into the Components menu and referencing the dialog control does so as well.

So, I have to conclude that the only way to dereference the object library is to do so by directly editing the .vbp file. I definitely will use this, but when I do will document this behavior, as anyone maintaining the code will have a tough time tracking this down if they're trying to dereference an ocx file in an application. Assuming, of course, that the commdlg32.ocx file isn't the only one that behaves this way.

Bob

 

[BobRodes]

p. s. I just tried this with the Winsock control, and get the same behavior.

 

[strongm]

>So, I have to conclude that the only way to dereference the object library is to do so by directly editing the .vbp file

Nah, just try and rereference it via browsing on the references menu just like when first adding it. It'll appear ticked in the references dialog. DOn'#t click 'OK' until unticking it. Voila.

 

[griffitd]

Hi

Thanks for all the replies.

Just another quick question. when I browse for winsock.dll and add it as a refernce i get can't add a reference to the specified file?

Am i doing something wrong

Thanks

 

[strongm]

MSWINSCK.OCX

 

[BobRodes]

griffitd, the way to find this is to go into the components menu and look for the control there. The file name will be listed. Then go to the references menu and browse to the file.

strongm, when I do what you suggest, the line item disappears, but the component remains in the object browser. Maybe it's a quirk in my installation or something.

 

[Nimroduk]

I have the same thing Bob but then I think it would only be a problem if I had post-10 cups of coffee shakes when selecting the object to reference in the first place.

strongm, fantastic little snippet of knowledge this. I had no idea you could do this and I love the support for "withevents" too. Just fantastic. It makes me wonder if working this way might have prevented my recent out-of-memory, form load limit problem.

regardless, a star from me. I thought I had seen it all from VB6

Option Explicit

Private WithEvents noSocket As MSWinsockLib.Winsock

Private Sub noSocket_Close()

End Sub

Private Sub noSocket_Connect()

End Sub

Private Sub noSocket_ConnectionRequest(ByVal requestID As Long)

End Sub

Private Sub noSocket_DataArrival(ByVal bytesTotal As Long)

End Sub

Private Sub noSocket_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean)

End Sub

Private Sub noSocket_SendComplete()

End Sub

Private Sub noSocket_SendProgress(ByVal bytesSent As Long, ByVal bytesRemaining As Long)

End Sub

 

[geoman1]

I got here by a long route. I need to add winsock.ocx to a VBA project in Excel. This project collects engineering data from from a server app at a specific IP /port. Ive got it working but the Winsock.ocx is only available on the devel machine, which has VB6 loaded, but the target machines don't. SO I cant activate the control from the Excel file.

I am having some trouble following this thread but I need to legally gain access to the Winsock ocx as this is in a commercial environment. Is there some way I can make it acessible via VBA on my target machines?

Can I use a .dll or xla or something else?

I could use a little more detail on what was done here (like step-by-step) to put the control into a .dll and gain access it. I am a little slow but I think this is close to my goal!

I have VB6, C++ and am using XP with Office 2003.

Thanks for any help,

Long time serching,
Geoman.

 

[dilettante]

This isn't going to help you, sad to say. Doing what you want requires Office Developer. Otherwise you don't have the necessary license to use the control as you need to.

The cleanest solution will probably be to use a 3rd party control for this. One solution might be to Google for SocketWrench Freeware Edition.

This is no longer supported and you can't get it from the vendor, but I did see this on their support forum:

SocketWrench 3.6 (the old freeware version) is no longer available for download from our site, although you can probably find it on one of the shareware download sites on the Internet.

Is the freeware version still available!?

 

[geoman1]

Well, I should have said that the devel was Office 2003 Pro and all the systems where this app will go are also.

I have placed the controls (I need 2 open ports so Winsock1 & Winsock2) on a form (frmTCP) . And then:
Load frmTCP
Unload frmTCP
:
Set wsDTA = ftmTCP.Winsock1 ' 1st use
:

So, for example in my VBA code I ref things like:
wsDAT.Protocol = 0 (TCP)

I seems to allow me to have access to the OCX on other systems as well - with no yelling about licenses.

There was one sample system where the OCX was not in the system32 directory. I placed it there and then started the Excel App and all was OK. Again no complaints about the any license.

Its not an issue of money to buy the control I need - its that the IS&T police will *not* allow freeware. Also they must approve *everything*. They guard admin privelege so normal users can't do harm. So I am lookin for ingenious way to get to the goal.

I was trying to follow the earlier part of the thread about creating an ActiveX dll that I would then distribute with the Excel app to the several systems that need it. If I can reference it rather than registering it I can be within guidelines.

Any thoughts??,

Geoman

 

[dilettante]

No, this doesn't get around the licensing (both on-paper and ActiveX licensing) or the need to register the compoment library.


Developer Editions of Office included tools and development licenses for a suite of components that overlapped those of VB6.

As far as I can tell there wasn't even an Office 2003 Developer Edition released. They expect you to limp along with Office 2003 Pro and buy the VSTO package to develop for Office in .Net!

INFO: Migrating from Microsoft Office XP Developer

Yet even if you were on an older Office version and had Developer Edition for that, you face deployment issues when moving your product to another machine. You'd need to create an Office Setup that would embed the runtime license in your application and would deploy and register things like the Winsock control.


About the only alternative I can think of is pretty nasty: try to use the Winsock API from your VBA code! This is not for the faint of heart, and might not be practical in VBA.