I added a basicHttpBinding to an existing Service I have in production in order to expose it for use in Delphi.
When I try to use the WSDLImporter from Delphi 7 on the wsdl file, it doesn't work right.
A section in the resulting tlb says
// ************************************************************************ //
// The following types, referred to in the WSDL document are not being represented
// in this file. They are either aliases[#] of other types represented or were referred
// to but never[!] declared in the document. The types from the latter category
// typically map to predefined/known XML or Borland types; however, they could also
// indicate incorrect WSDL documents that failed to declare or import a schema type.
// ************************************************************************ //
This service is consumed fine by .NET client. The service is using complexTypes but they are in the files and they are the newer split out to multiple files for imports by xsd.
Any way of doing this in Delphi 7? I even tried pulling all imported types back to 1 wsdl document. No difference.
Thanks,
David
I know this is old (very) but it might help someone else out struggling through this like we were with WCF interoperability with Delphi.
What made the difference in my own experience was
using basicHttpBinding
using the Delphi wsdlImp command line tool
enforcing Soap 1.1
pointing to the SingleWsdl address.
Here is an what our WsdlImp command looks like:
wsdlimp -P -XName -Ox- -SOAP11 -Oa- -Ol+ -ob+ -= http://srvAddress:1253/WCF.Server/Utils.svc/metadata?singleWsdl=UtilsWsdl.pas
First guess is that the WCF service is SOAP 1.2, for which support was added in Delphi 2010.
For Delphi 7, you could try some of the answers to this question.
--jeroen
Related
I am writing an exe OLE server to embed it in my own application. I am running OLE server (exe) with /regserver parameter as a normal user and I am getting following error:
Error accessing the OLE registry
I don't need any other programs to use this server. It is just for my own client and it will not be a DLL. Is there a way to register it as standard user?
Other problem is that i see codes which are not pascal in ridl file. Types of properties are C not Pascal. For example i see DATE but i don't see TDateTime in the list. I am using XE5.
Use switch "/REGSERVERPERUSER"
I use XE5, it work.
Delphi write corresponding register keys
Use the PerUserRegistration to ensure that your COM server self-registers to the per-user HKCU hive. Or simply write the registry settings yourself. Which is the recommended approach anyway if you are writing an install program.
RIDL is a flavour of Interface Description Language (IDL). It is used to describe the interface of your COM server. It is not Pascal. It's not passed to a Pascal compiler. It's processed by a tool that understands RIDL. Everything is as expected.
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 am trying to port some Delphi XE code to XE2, it uses a unit called InvRules.pas, which according to the XE2 docs, has no namespace prefix.
It also isn't in the soap folder where I expect it:
C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\source\soap
The simplest answer is that it's been removed (accidentally or on purpose) from XE2.
Has anyone figured out what's up? This unit contains functions like GetStackTypeSize, and RetOnStack, which are used sometimes in custom TRIOHelper type classes.
This unit is no longer used by the soap runtime so it's not being shipped anymore. In previous releases, it was part of the soaprtl runtime package. There were some significant changes made to the soap runtime for the XE2 release to make the code portable to x64 and less reliant on BASM code that was essentially duplicated in the RTTI support units. The change log entry associated with the commit states:
Refactor out InvRules, use RTTI to get type sizes.
Remove InvRules, PrivateHeap from soap package.
If you have code which relies on the helper routines in this unit you should be fine using the source from a previous release. You may also want to diff the Invoker.pas, InvokeRegistry.pas, OPToSOAPDomConv.pas and Rio.pas units between XE and XE2 to see how the code changed so it no longer relies on the InvRules.pas unit.
I have a .net dll which I could import to Delphi 6. But it loses some information.
I have a demo application in VB.net to use this dll which shows 2 interfaces called
IRedeemTransactionItemBundle and ITransactionItemBundle. In Visual Studio 2008 I could see that ITransactionItemBundle is the base type of IRedeemTransactionItemBundle. So when I declare a variable of type IRedeemTransactionItemBundle, I could access all properties of both interfaces.
But when I import the dll to Delphi 6, I could see both IRedeemTransactionItemBundle and ITransactionItemBundle declaration part. But there is no information that shows ITransactionItemBundle is the base type of IRedeemTransactionItemBundle. Also when I declare a variable of type IRedeemTransactionItemBundle in Delphi, I am not able to access properties of ITransactionItemBundle (the base type).
When I tried to register the library in tlb editor by setting the base type of IRedeemTransactionItemBundle to ITransactionItemBundle, I am getting the error: “Parent Interface already has a member with id:1610743808”. I could see properties of both interfaces have same ID in the tlb editor.
I tried to import the same dll using Delphi 7 also. But no help.
Is that a problem with Delphi? Have any of you experienced such a problem in importing kindly give me some thoughts?
I would suggest you to make COM visible wrapper for the DLL in C# or VB.NET which will import necessary functionality in the way Delphi can interact with correctly.
Apart from using COM interop, you can do an unmanaged export. Simply put, you need a new specific version of the .net dll.
Please head to this post for details of the technique using Delphi.
I'm trying to generate _TLB import units for Outlook 2003, 2007 and 2010 (and also other OLE servers) analogous to the ones bundled with Delphi for Outlook 2000 and 2002. However, I couldn't get the type library importer to also generate the code for capturing events from the OLE servers that is found in the bundled units. The option to "Generate component wrappers" only creates wrappers for servers that are directly instantiatable but not for objects that are only returned via methods of other objects like TInspector, TExplorer, etc.
I could of course create the event handling code myself but that would be really tedious work.
Does anyone know if the importer contained with Delphi 2010 (tlibimp.exe) can be tweaked to generate that code? I really doubt that back in the day Borland created the existing Outlook2000.pas and OutlookXP.pas units manually...
Are there maybe any other tools around that can do this?
Good question! I never noticed that those components were not created (I only use Word_TLB). After playing a bit with tlibimp I found out that you need the -Yc+ flag. Probably all ignore flags are default on.
NB: this is on Delphi 7 with tlibimp.exe version 7.0.4.453