Community
Participate
Working Groups
I'd like to request support for licensed COM controls (those that support the IClassFactory2 interface) in SWT. This would require adding a method to swtole.c that would take a license string and call IClassFactory2::CreateInstanceLic. In addition, modifications would need to made to COM and OleClientSite to call the the licensed method instead of CoCreateInstance when supplied with a license. -Stephen
Support for licensed ActiveX controls is already in place (see OleControlSite). What exactly do you mean? COM is quite big. We only support containers for ActiveX and Ole Documents. We currently use OleCreate not CoCreateInstance for Ole Documents. OleCreate does a large amount of work, much more than just calling CoCreateInstance.
I am attempting to pass in a license key from the Java side at runtime (the control is licensed by developer seat with unlimited deployment). I looked through the OleControlSite and associated code. I see a String member variable named licenseInfo that is never used. So, it looks you need to override getLicenseInfo(GUID) in to allocate the memory for your license string and return its address for use by IClassFactory2.CreateInstanceLic. Is this correct or is there a simpler approach? It would be great if there were a constructor that took a license string that did this for you.
I am not sure what version of the code you are looking at, but there is no licenseInfo string member variable in Eclipse 2.1. OleControlSite uses a BSTR which it extracts from the LICINFO struct obtained from the IClassFactory2 interface. I think perhaps your control is not installed correctly. It should have a .LIC file with all the licensing info contained in the file. You should not be passing in a licensing string. See: http://msdn.microsoft.com/library/default.asp? url=/workshop/components/activex/licensing.aspus/vccore/html/_core_activex_cont rols.3a_.licensing_an_activex_control.asp
ActiveX licensing is a three step procedure. The first two steps (involving IClassFactory2::GetLicInfo and IClassFactory2::RequestLicKey) occur only at development time. On the developer's machine, license info can be stored either in a .LIC file or in the \\HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\Licenses path of the registry. Either way, these values are accessed by IClassFactory2::GetLicInfo and IClassFactory2::RequestLicKey from the IDE , which embeds the resulting key into the application. At application runtime, the application calls IClassFactory2::CreateInstanceLic using the key that was embedded by the IDE. The deployed application does not call IClassFactory2::GetLicInfo or IClassFactory2::RequestLicKey. If it did, it would require that the developer's license be installed in the registry of the deployment machines, which most likely violates the licensing agreement. Currently SWT performs all three steps at application runtime. Thus, it mimics the IDE container in calling IClassFactory2::GetLicInfo or IClassFactory2::RequestLicKey. As such , this only works on the machine with the developer's license. A more appropriate approach to deploying a licensed ActiveX control with a SWT application would be to hardcode the license string into the application and return the address for that string from OleControlSite.getLicenseInfo (the license string can be pulled from the .LIC file or registry by the developer). Thus, the request for adding a contructor to take the license key as a parameter.
All that needs to be added is the following lines to OleControlSite: private char[] licInfo; public OleControlSite(Composite parent, int style, String progID, String key) { this(parent, style, programID); if(key != null) { this.licInfo = key.toCharArray(); } } protected int getLicenseInfo(GUID clsid) { if(this.licInfo != null) { int ptr = COM.SysAllocString(this.licInfo); if(ptr != 0) { return ptr; } } //... Do the rest of getLicenseInfo } Since getLicenseInfo() is called by the constructor, OleControlSite can't be extended to do this. Thanks for all of the COM utilities. It really makes it easy. -Stephen
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate
