MSWinsck.ocx - Not Licensed for use 2

[craigsboyd]

I've created an install set using Installshield professional and have included the MSWinsck.ocx in a self-registering file group, so it is being registered. However, when the install is run on a target computer I receive an error regarding the control not being licensed for use. From what I have read so far on the web it is due to the fact that I am dynamically creating the control in code rather than having it on a form somewhere so the licensing information is not compiled in. I guess the MSWinsck control was never designed to be created dynamically using createobject(). I don't really want to add the control to an invisible dummy form to fix this. Does anyone know how to get around this problem and properly license the MSWinsck.ocx on a target computer? Thanks.

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]

 

[Mike Gagnon]

SlightHaze

Knowing to code that you have, what happens when you use the code in example 214 "Initializing the Winsock service for the VFP application", from Initializing the Winsock service for the VFP application form

http://www.news2news.com/vfp?

Wouldn't the target computer already have the required winsock?

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[rgbean]

"I don't really want to add the control to an invisible dummy form to fix this." Why?

It's trivial code, and I believe the only way to get past the licensing issue is to buy and install a MS developer product on each user's system - this would seem to be a rather expensive alternative.

Rick

 

[craigsboyd]

Thank you Mike and Rick for the responses.

Mike,

The API code runs fine on the target computers, however the code I have is using the MSWinsck.ocx which is not on the target computers (or at least I cannot rely on it being there).

Rick,

"Why?" A good question and should this problem roll around in the back of my mind much longer I will most certainly go ahead with the dummy form workaround. Just seems to me that there are some missing Registry settings that are causing this. At this point it is more a case of personal interest as to what is going on and how to fix it...also there might be times when I want to use the winsck.ocx in a program that doesn't have any forms and thus nothing to put the ocx on so the only option would be to create and use it dynamically.



Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]

 

[rgbean]

There is actually a couple of things that are required to use some MS controls in "developer" mode, so it's not as simple as a Registry tweak. Assuming you really don't want to ignore/circumvent the MS licensing, your only simple solution is using a container (usually a Form) wrapper. Some code I use to get the IP returned:

** GETIP.PRG
LOCAL oForm1, lcIP
oForm1 = CREATEOBJECT("dummyform")
lcIP = oForm1.Olecontrol1.LocalIP
RELEASE oForm1
RETURN lcIP

*************************************
DEFINE CLASS dummyform AS form

   DoCreate = .T.
   Caption = "dummyform"
   Name = "dummyform"

   PROCEDURE INIT
   IF .F.
	** This sucks the class into the project automatically.
       SET CLASS TO ep_winsock
   ENDIF
   THISFORM.NewObject("olecontrol1", "ep_winsock", "ep_winsock")
ENDPROC

ENDDEFINE

Note: Class ep_winsock is nothing but an OLE class that has winsck.ocx in it!

Rick

 

[craigsboyd]

Rick,

Thank you. I hadn't really thought that by using the ocx without placing it in a container of sometype that I could actually be circumventing the MS licensing. You may have a very good point there. I find it odd that MS has not better documented the ocx controls that require such a wrapper, and I wonder what the other ones (if any) are. I find the restriction difficult to understand, but I am sure they had some good reason for doing it the way they did. Perhaps they thought that should a developer want to use winsock functions without placing the winsck.ocx on a form that they would just use the dlls.

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]

 

[codetyko]

I too faced the same problem with a clients' pc until i found this site:

http://www.piclist.com/techref/os/win/instMSwinsock.htm

download the file

http://www.sxlist.com/images/mswinsock.zip

which has an instruction on how to use the batch file to copy the ocx and register it in the registry. It works for WinME as well.

 

[craigsboyd]

codetyko,

will take a look at it and get back to you. Thanks.

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]

 

[ramani]

Slighthaze,

May be this is trivial, but

SET OLEOBJECT ON

By default VFP keeps this ON but I dont know any BUG is there preventing to look into registry.



ramani
(Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[craigsboyd]

codetyko,

That works, thanks for the link.

Ramani,

I don't think I have ever even looked at the SET OLEOBJECT before. Even though it didn't fix my problem I learned something from your post. Thanks.

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]