MelissaEvans
asked on
Licensing Issue for OCX
I have created a large OCX that is basically a user interface. I had to do this so I could use it in my own shell and so that another developer could use it too. There are many, many pieces to this OCX, and the install program for it was obnoxious. In order to get it to the other developer, I gave hims a "stub," an interface really; all of the properties and methods are there, but no code. The non-intrinsic controls were removed for simplicity's sake. When a customer gets his shell, we'll just "upgrade" the OCX to the functional version without making the other developer recompile his code... at least that was the plan. When I try it from an NT station (not the development computer), I get the error message:
"You do not have an appropriate license to use this functionality."
(Wouldn't it be nice if it told me what wanted the license and what functionality it's denying me? *sigh*)
I got a test development computer and made a simple shell to test and got the same results.
On the computer that's giving the error message, my shell program with my complete OCX is installed and working fine - so the OCX is not missing a dll or whatever.
Also, I tried it on a Windows 2000 machine and got a different error message:
"License Agreement Error
File LICENSE.DAT not found. License agreement cannot be completed."
I know that I used some purchased controls in my OCX, but I've gone through them all and installed them on the test development machine, and I still get the errors. I include all the components and references that are in the real developement environment, and get the same problem.
Any ideas?
Thanks for your time
~Melissa
"You do not have an appropriate license to use this functionality."
(Wouldn't it be nice if it told me what wanted the license and what functionality it's denying me? *sigh*)
I got a test development computer and made a simple shell to test and got the same results.
On the computer that's giving the error message, my shell program with my complete OCX is installed and working fine - so the OCX is not missing a dll or whatever.
Also, I tried it on a Windows 2000 machine and got a different error message:
"License Agreement Error
File LICENSE.DAT not found. License agreement cannot be completed."
I know that I used some purchased controls in my OCX, but I've gone through them all and installed them on the test development machine, and I still get the errors. I include all the components and references that are in the real developement environment, and get the same problem.
Any ideas?
Thanks for your time
~Melissa
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Did run install the developer's installation of the ocx's, or just install and register the ocx's and supporting dll's? You need to install the purchased developer's licenced package on the "test" development machine.
One suggestion is to pinpoint the errored control. Do you have a global area within your OCX where you are referencing the other controls? You should not get an errors when you reference them such as; "Private WithEvents TSocket as Telnet.clsConnect"
But, you will recieve error messages when you attempt the "Set TSocket = New Telnet.clsConnect" - so I would suggest placing some counter or message routine within this area and determine which exact DLL/OCX is the snafu.
Once this is resolved, then you can determine whether or not you are missing dependency files or have a lisence issue. Hope this helps!
But, you will recieve error messages when you attempt the "Set TSocket = New Telnet.clsConnect" - so I would suggest placing some counter or message routine within this area and determine which exact DLL/OCX is the snafu.
Once this is resolved, then you can determine whether or not you are missing dependency files or have a lisence issue. Hope this helps!
ASKER
I did the official "install" for the purchased controls on the test development station.
I get the error message during the initialization of my control, before anything is done.
~Melissa
I get the error message during the initialization of my control, before anything is done.
~Melissa
Let me get this straight - you have an OCX which is part of a interface program and your OCX includes/utilizes other OCX/DLLs? If this is true, within your own OCX, you can streamline the debug process by determining when and where the error is coming from while you are initializing the 'other' OCX/DLLs. Just as I mentioned above, this way at the bare minimum you will know which control it is that is causing the snafu!
Such as:
Public Sub InitializeAll()
on error goto errInit
sMsg = "Attempting Winsock DLL"
Set WSock = New Winsock
sMsg = "Attempting WinInet DLL"
Set WInet = New WinInet
exit sub
errInit:
Msgbox sMsg,vbexclamation,"Initia
'or use RaiseEvent if you implemented this
End Sub
This will help to pinpoint the exact nature of the erroring DLL.
Such as:
Public Sub InitializeAll()
on error goto errInit
sMsg = "Attempting Winsock DLL"
Set WSock = New Winsock
sMsg = "Attempting WinInet DLL"
Set WInet = New WinInet
exit sub
errInit:
Msgbox sMsg,vbexclamation,"Initia
'or use RaiseEvent if you implemented this
End Sub
This will help to pinpoint the exact nature of the erroring DLL.
You probably didn't set this, but when you created the control, there is a control property (Project Properties) checkbox entitled "Require License Key" under the General tab. Make sure it's not "checked" if you want to allow other distributors to use your control.
Other than that, I'd have to agree with some of the comments above. One of the constituent controls is not properly licensed on the other development machine.
--
Could you possibly create an alternate 9and temporary) version of your control with those licensed controls removed (and all code commented) so that you can determine if the problem is with your control or a purchased control?
Other than that, I'd have to agree with some of the comments above. One of the constituent controls is not properly licensed on the other development machine.
--
Could you possibly create an alternate 9and temporary) version of your control with those licensed controls removed (and all code commented) so that you can determine if the problem is with your control or a purchased control?
ASKER
rspahitz - The "Require License Key" checkbox is not checked. The commented version you mentioned is what I'm calling the "stub." It has the interface (so it's compatible as far as the computer knows), but no functional code. That's what I gave the other developer, but it won't do the customer any good; so the plan is to "upgrade" it to the real OCX that has the actual code and such. The stub version works as expected (it shows the pretty picture, and puts up some message boxes when certain methods are called). Putting in the real OCX is where I'm getting the error.
PBuck - I looked at the code in my Init sub and noticed I was playing with the SSTab control. In the stub, the tab control has been removed; in the real OCX, it's there. The code dies when I try to use it.
I looked at the tab's ocx files on the real development machine and on the test one; the version on the test machine was newer. I realized that I applied SP5 to the test system, but not the real one. So I installed SP5 on the real one, and recreated the install package - but I still get the same error. The tab ocx file is the same on all three computers now (real, test, and host).
Am I making sense so far? I don't mean to leave out information to help you help me; but sometimes it's hard to know what you need to know, ya know? =)
~Melissa
PBuck - I looked at the code in my Init sub and noticed I was playing with the SSTab control. In the stub, the tab control has been removed; in the real OCX, it's there. The code dies when I try to use it.
I looked at the tab's ocx files on the real development machine and on the test one; the version on the test machine was newer. I realized that I applied SP5 to the test system, but not the real one. So I installed SP5 on the real one, and recreated the install package - but I still get the same error. The tab ocx file is the same on all three computers now (real, test, and host).
Am I making sense so far? I don't mean to leave out information to help you help me; but sometimes it's hard to know what you need to know, ya know? =)
~Melissa
The SSTab is royalty free and comes with VB6 inherently, I was only concerned with purchased controls. Did you buy some type of GridControl, TCP/IP control, or any such control that did not come with VB6?
If you did purchase some controls, how are you using them? Meaning ... do you have to use the 'Set XXX = New XXX' or are they graphical in nature and you just moved them to the form?
In general, you need not have to worry about ANY controls that came with Visual Basic or Visual Studio - we are just concerned about purchased controls.
Let us know please ...
If you did purchase some controls, how are you using them? Meaning ... do you have to use the 'Set XXX = New XXX' or are they graphical in nature and you just moved them to the form?
In general, you need not have to worry about ANY controls that came with Visual Basic or Visual Studio - we are just concerned about purchased controls.
Let us know please ...
ASKER
The code won't get past the init sub. Here's the code that's in there:
Public Sub UserControl_Initialize()
On Error GoTo CtlInitError
MsgBox "in init"
tabPersonnelInfo.Tab = 0
MsgBox "played with tab"
tabPersonnelInfo.TabVisibl
lblVersion.Caption = "Version " & App.Major & "." & App.Minor & "." & App.Revision
MsgBox "Done in init"
Exit Sub
I get to the first MsgBox "in init" fine; the next line will cause the error. When I comment it out, it will still die at the lblVersion.Caption line. If everything but the MsgBox lines are commented out, it gets through this sub. I encounter a different problem though (which is beyond the scope of this question, so I won't burden you with that one in this thread).
As far as the purchased controls go, they are graphical in nature that simply get put onto the form; no "new-ing" needed.
~Melissa
Public Sub UserControl_Initialize()
On Error GoTo CtlInitError
MsgBox "in init"
tabPersonnelInfo.Tab = 0
MsgBox "played with tab"
tabPersonnelInfo.TabVisibl
lblVersion.Caption = "Version " & App.Major & "." & App.Minor & "." & App.Revision
MsgBox "Done in init"
Exit Sub
I get to the first MsgBox "in init" fine; the next line will cause the error. When I comment it out, it will still die at the lblVersion.Caption line. If everything but the MsgBox lines are commented out, it gets through this sub. I encounter a different problem though (which is beyond the scope of this question, so I won't burden you with that one in this thread).
As far as the purchased controls go, they are graphical in nature that simply get put onto the form; no "new-ing" needed.
~Melissa
I'm not sure that it's good practice to set values to controls that haven't been created yet (i.e. I think that controls are not created until after the Initialize.)
It seems that setting object properties should go in the InitProperties event procedure.
It seems that setting object properties should go in the InitProperties event procedure.
Here's Microsoft's comment, which is totally unclear to me:
"
InitProperties Event
...
Remarks
This event allows the author of the object to initialize a new instance of the object. This event occurs only when a new instance of an object is being created; this is to allow the author of the object to distinguish between creating a new instance of the object and loading an old instance of the object.
By putting in code to initialize new instances in the InitProperties event rather than the Initialize event, the author can avoid cases where loading data through a ReadProperties event into an old instance of the object will undo the initialization of the object.
"
"
InitProperties Event
...
Remarks
This event allows the author of the object to initialize a new instance of the object. This event occurs only when a new instance of an object is being created; this is to allow the author of the object to distinguish between creating a new instance of the object and loading an old instance of the object.
By putting in code to initialize new instances in the InitProperties event rather than the Initialize event, the author can avoid cases where loading data through a ReadProperties event into an old instance of the object will undo the initialization of the object.
"
I am at a loss about the MS blurb also ;-)
I do all my initialization of controls during the form_load event. So maybe as rspahitz has suggested, place the above code later in the startup routines (such as InitProperties/form_load).
I do all my initialization of controls during the form_load event. So maybe as rspahitz has suggested, place the above code later in the startup routines (such as InitProperties/form_load).
ASKER
You comments about using items that don't exist yet make sense; but why does it work in my shell?
I'm sorry I'm being slow, I'm trying to get through another problem before I can verify any of this works. I promise I will award the points as soon as I can.
I know this is a side question, but if anyone knows about compatibility, I have a (hopefully) easy question. I know that for Binary compatibility, you point to a file that you want subsequent makes to be compatible with. On the real development machine, it's pointing at the "stub" OCX I sent to the other developer and am using on the test development machine. This way, I know that the real OCX is compatible with the Stub OCX... only it isn't. I get the "Failed to load <control> from <ocx>. Your version of <ocx> may be outdated. Make sure you are using the version of the control provided with your application." Well, I'm not using the same one; that's the point - but I was under the assumption that by using the stub as the reference, it would be compatible with it. Am I missing something really silly?
~Melissa
I'm sorry I'm being slow, I'm trying to get through another problem before I can verify any of this works. I promise I will award the points as soon as I can.
I know this is a side question, but if anyone knows about compatibility, I have a (hopefully) easy question. I know that for Binary compatibility, you point to a file that you want subsequent makes to be compatible with. On the real development machine, it's pointing at the "stub" OCX I sent to the other developer and am using on the test development machine. This way, I know that the real OCX is compatible with the Stub OCX... only it isn't. I get the "Failed to load <control> from <ocx>. Your version of <ocx> may be outdated. Make sure you are using the version of the control provided with your application." Well, I'm not using the same one; that's the point - but I was under the assumption that by using the stub as the reference, it would be compatible with it. Am I missing something really silly?
~Melissa
The only thing I know about 'Binary' compatability is that it provides a method for keeping the OCX/DLL in a controlled version. Meaning, it will notify you when compiling if you break compatibility by adding/subtracting functions or procedures.
If code is added to the current functions with no Sub name changes - then the control maintains capatability with projects that are using it. And when running executables with your 'Binary' compatability set to on, they should continue to run when you update your OCX/DLL (as long as compatability isn't broken).
This is just my understanding of how it works - someone may provide a more technical description :-)
If code is added to the current functions with no Sub name changes - then the control maintains capatability with projects that are using it. And when running executables with your 'Binary' compatability set to on, they should continue to run when you update your OCX/DLL (as long as compatability isn't broken).
This is just my understanding of how it works - someone may provide a more technical description :-)
ASKER
Sucks to be me 'cause of that. Thanks for your time.
ASKER
On my test development station, I put in all of the purchased controls and still got the errors. =(
~Melissa