I have an application with an automation object.
In the delphi IDE I can register it via the button "register type library".
As an alternative I can use codegear's tregsvr.
But how should I register the application when it's installed on other computers?
Should the setup include the tregsvr.exe? Am I allowed to contribute the tregsvr.exe?
Thanks for your advice!
Windows has a regsvr32.exe which is able to register DLLs (or OCXs). If your server is an EXE you should be able to register it using the command line switch /REGSERVER.
This mechanism is called self-registration, so your COM server library performs registration itself.
RegSvr32 yours.dll
RegSvr32 /u yours.dll
Actually, along with this, there are lot of Windows built-in registration behaviours, all of them are simple, you only need to list your file eg. in RegisterDlls INF section. Those are merely a calls to DllRegisterServer and DllUnregisterServer functions
Related
i am using Delphi XE4 to create a Voip program. i am using an outdated VOIP SDK From a company called BigSpeed which is no longer around the current code points to the following path 'C:\Program Files (x86)\BigSpeed Voice SDK\' where the active x controls are stored.
LIBID_bsVoiChatCln: TGUID = '{D2A88515-99E0-4EEE-A030-E5D2AB306A03}';
IID_IbsVoiChatClnX: TGUID = '{5055A626-56A1-4E58-A461-000A69CA3E03}';
DIID_IbsVoiChatClnXEvents: TGUID = '{665DB561-22D3-4624-B55B-4416309A2E03}';
CLASS_bsVoiChatClnX: TGUID = '{BE761C1E-1F6C-46F8-A99B-0AB29C9B2D03}';
How can i create a new GUID and have the program access the active x controls from a new directory.
You don't want to create new GUIDs. The GUIDs are the identifiers of that component. All you want to do, as far as I can tell from the question and your comments, is to register the DLL at a different location.
The ActiveX DLL almost certainly uses self-registration. This means that you can put the DLL somewhere else and register it there. For instance, suppose the DLL is located in:
C:\MyFolder\MyDll.dll
Then you could register it by executing this command:
regsvr32 C:\MyFolder\MyDll.dll
Looks like you do not understand (or do not explain) relations between your program, the library and the GUIDs.
How can i create a new GUID and
1) GUID is just a 128-bit random number. So you can "create new GUID" simply by editing its hexadecimal string. Or you can press Ctrl+Shift+G in Delphi source editor in designtime. In runtime you can use CreateGUID function of SysUtils unit.
http://docwiki.embarcadero.com/CodeExamples/XE5/en/UsingGUIDs_(Delphi)
http://docwiki.embarcadero.com/Libraries/XE2/en/System.SysUtils.CreateGUID
http://en.wikipedia.org/wiki/GUID
But i don't think creating new GUID will do you any good. If anything, it should mean explicitly declared incompatibility with old GUIDs (hence incompatibility with VOIP library)
from a new directory.
2) Why do you think your VoIP library is arranged as a set of ActiveX control ? Just because there are GUIDs there? Not any text file with GUIDs inside would be ActiveX.
ActiveX are specifically arranged Windows servers, that are registered in the registry so that any program could call them. Sometimes you can register them after the fact, if the installer failed it.
http://en.wikipedia.org/wiki/Activex
http://en.wikipedia.org/wiki/Regsvr32
http://support.microsoft.com/?id=207132
So you should read manuals for your library whether they constitute ActiveX or not, and if they do, how to register them in Windows (should be done by the library installer)
If installer does not provide for it, then you can not be sure that the library can work from a different place. Not only your program needs a connection to it, but also the library itself may need connection to its other parts.
have the program access the active x controls
3) If your library really conforms to ActiveX specifications and if it was correctly installed (registered) then you can just import them into Delphi IDE and drop them onto the form like you drop tables and dialogs.
http://docwiki.embarcadero.com/RADStudio/XE3/en/Import_Component_Wizard
http://delphi.about.com/library/howto/htaddactivex.htm
http://www.delphisources.ru/pages/faq/master-delphi-7/content/LiB0125.html
4) if you do not want to drop your VoIP component onto the form, then you can try to create it in runtime with CoCreateInstance. But first you have to read some tutorial about Microsoft COM for beginners. You may miss some advanced concepts, but you should understand the most basic things like how interfaces are similar to and different from classes, how their lifetime is managed, how COM runtime is initialized and finalized for your program and so on.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686615.aspx
http://delphi.about.com/library/weekly/aa121404a.htm
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1135
How to use CoCreateInstance() to get a com object?
https://stackoverflow.com/search?q=%5Bdelphi%5D+cocreateinstance
all the MS Office related examples in c:\RAD Studio\9.0\OCX\Servers\
5) you may also try to bypass the proper Windows ways of locating and loading the server and try to do it yourself, using DllGetClassObject routines in proper DLLs. If the library is permissive, it will work. But if it does rely on Windows-provided services that has a potential for all kinds of crashes and unmet expectations.
https://www.google.com/search?client=opera&q=CoCreateInstance+and+DllGetClassObject&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680760.aspx
How do I use a COM DLL with LoadLibrary in C++
DllGetClassObject return "No such interface supported" while CoCreateInstance can find it successful
If my memory serves me, You can find examples of that approach in early HTML Help units for delphi. Microsoft HTML Help provides for both late binding using CoCreateInstance and runtime ActiveX servers registry, or early binding towards htmlhlp.ocx treated as DLL. Early versions of HTML Help API for Delphi provided for both options. But i may be wrong here.
I'm a bit confused on something, being quite a while since I've used external controls. Basically, I'm writing a small test app with Delphi XE3 which uses an ActiveX control. A TLB file is generated as usual. I have tested on two machines (an Acer notebook and a Dell Latitude 10). When I test on my desktop Windows machine I get an error traceable to the OCX file. I was under the impression that the TLB.pas file was all that was needed to instantiate the control. Do I also need to install and register the OCX file ? Does COM component need to be distributed with its .DLL file ? TIA for your anticipated help.
Brian Corll
The type library only describes how to call the library. The .pas file generated from the type library also only describes how to call the library. That's all compile time. At run time when you actually call the library, you need the library to be registered and present.
So yes, you'll need to distribute and register the library.
I'd like to build an out-of-process COM server with Delphi that does not need any visual forms. The main purpose of that server is to provide some "out-of-process" processing for other Windows Services.
Is it possible to place COM objects into simple console application? I expect it will (at least) need some kind of message-handling loop inside.
Can I place it inside of Windows Service instead?
You could do message handling yourself, but the Component Services tool in the Administrative Tools that are available in Windows, since Windows 2000 if I remember correctly, provides a way to select an ActiveX dll and have it run from a dllhost.exe process, optionally as an NT-service.
If you really want to you could start a plain exe project and add TAutoObject's to it, even to an NT-service project, but there's a little extra work to be done to get multi-instancing, security and concurrency right.
You can check SvCom for an explanation on what's different in running a DCOM server as a service, and for a library implementing it fully, supporting latest Delphi releases also.
I have a Delphi application with an automation object.
On the start of the program, I want to register the COM object automatically in the registry (instead of using the /regserver switch).
The old version of the program was written in Delphi 7 and I think I remember that this version registered itself after program start. But now it's compiled with D2009 and it doesn't register itself now. Maybe somebody know something about this?
Thank you very much!
This is probably failing because you are running on a machine with UAC and you don't have rights to write to HKLM. You aren't going to find a satisfactory solution using the /regserver switch because it will always try to write there.
You could switch to registry free COM, although it might just be better to do the registration as part of installation. That's when you are expected to do it because that's when you know that you will have sufficient rights.
You can use ComServer.UpdateRegistry(True); to register your com objects and ComServer.UpdateRegistry(False); to un-register.
ComServer is found in ComServ.pas
http://docwiki.embarcadero.com/VCL/en/ComServ.TComServer.UpdateRegistry
I want to design Delphi plugin framework. There are three options:
1. DLL
2. BPL
3. COM interface
Every option has some disadvantage.
DLL - Promblem with MDI apllication, forms from plugin cannot be embeded to the host exe - mdi application.
BPL - Every *.bpl plugin and *.exe host application must be compiled with the same version of Delphi.
COM - Interfaces {xxx-xx-xxx-xx} must be registered in system, (regsvr) So plugin framework cannot be portable!
Is everything true what I wrote above? If not, please correct me, or is there some other possibility?
thanks
Yes, what you wrote is correct. All of these have advantages and disadvantages, the question is what is important for you, you didn't say what you want to do, so we can't tell you how to do it.
In general, I would pick BPL by default, use DLL if you need to use it from non Delphi apps, and pick COM only if you really have to.
The alternative is to not build your own, since there are several Delphi plugin frameworks available.
Also, this topic has been discussed here before, check out:
how-best-to-add-plugin-capability-to-a-delphi-program
plugins-system-for-delphi-application-bpl-vs-dll
Another possibility is having a scripting interface, such as with Python or Pascalscript. There are many advantages to this approach, not least of which is that the plugin source is also the executable, making it easy to debug and share.
I would look at Hydra from Remobjects.
Another candidate would be a combination of PaxCompiler (scripting) and EControl Form Designer (form designer).
We use DLLs, even when using only with a Delphi application.
Dll forms are embedded in the main form and use Tabs instead of MDI.
For DLL to work properly we also use a shared memory manager and built with runtime packages: vcl, rtl and our own package.
Have you taken a look at http://www.tmssoftware.com/site/tpf.asp