As the title suggest, I can't find that unit.
Is there an equivalent?
I am trying to port a unit from VCL to Firemonkey which contains OleServer in its uses clause, but I can't find any information on Embarcaderos website regarding this problem.
I have also tried to Google it, but no success.
Where can I find TOleServer and/or its unit OleServer that is compatible with Firemonkey?
Or how can I implement that unit in my Firemonkey project?
Hi i have the same problèm before and i made change in OleServer
Copy Vcl.OleSever to your project and rename it to FMX.OleServer
in implementation section do change like this:
implementation
uses
FMX.Controls;
resourcestring
sNoRunningObject = 'Unable to retrieve a pointer to a running object registered with OLE for %s/%s';
at the initialization section change to FMX.Controls.TControl
initialization
GroupDescendentsWith(TOleServer, FMX.Controls.TControl);
end.
Finally rename VCL.OleServer to FMX.OleServer in your imported library unit
Indeed the main issue with compiling TLB (typelibrary) units for COM/OLE Servers seems to be some unit renaming that has occured. Ideally the Delphi IDE should detect this automatically and fix it.
Based on Doug Rudd's comment above I fixed my "uses OleServer" to "uses Vcl.OleServer" in my TLB unit.
Since there's a "source" folder under Delphi installation folder even for the Pro version now (at least at 10.2.2 Tokyo version that I'm currently using), I could also easily spot (using GrepWin free tool) where the "EmptyParam" that was causing my TLB to not compile had gone. It is under System.Variants unit that one also needs to use in their TLB (before it was in System so you didn't need to use some unit for it).
Guess I could have imported the COM/OLE Server again to make new TLB import unit, but since it was hand-ended (to remove using of "Graphics", "StdVcl" and "OleCtrls" units that were bloating the executable size in older versions of Delphi) and that hand-edited imported TLB used to work fine for a command-line application, I didn't have any reason to reimport the Type Library.
You can see the changes I did to make my XSLer tool work with the latest Delphi at https://github.com/Zoomicon/tranXform/commit/e99f42049b8a4c1534d9edb78ed5e6493e6e5786. That XSLer command-line tool is using MSXML (Microsoft XML) automation server.
Related
I am supporting some legacy Delphi project. This project is divided into modules that stored in DLLs.
I need to compile one of the modules (last compiled in 2007). This module uses module DualListBox and has a variable of type TDualListBox:
uses DualListBox ....;
...
lbMasterOrders: TDualListBox;
lbChildOrders: TDualListBox;
The problem is, I don't know where to find module DualListBox. I can't find it on my machine, and I can't find it on the internet.
As far as I understand, the TDualListBox component must be something like ListBox that can Add rows at runtime.
At first, i thought that DualListBox is a part of RxLib, but RxLib's component is called DualListDialog and it's something completely else.
So maybe this is the self-written module by prev developer, that was deleted somehow.
But somehow the compiled DLL (that was comiled in 2007) is working perfectly fine. Maybe I can investigate where to find that module by decompiling that DLL?
If so, where should I look in the decompiled project? I'm using DeDe for decompiling.
The unit is called duallist and is automatically generated by Delphi 2007 (and also Delphi 10.1 and 10.2, don't know about other versions, but I would be surprised if they didn't have it) when you open a VCL project and click:
File
New
Other
Delphi Projects
Delphi Files
Dual list box
These units are usually taken from the object repository, which by default is located in the ObjRepos subdirectory of the Delphi installation.
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 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.
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W
In the company that i work, we develop all the GUI in C#, but the application kernel is mainly developed in Delphi 5 (for historical reasons), with a lot of components made in COM+. Related to this very specific sort of application a I two questions:
Experienced guys in Delphi and/or COM, do you have any workrounds to work with the buggy TLB interface ?
Some of the bugs are: IDE crashing during edition of a large TLB, lost of methods IDs, TLB corruption, etc.
Here, we haven't found any good solution. Actually we tried do upgrade do the new 2007 version. But the new IDE TLB interface has the same bugs that we found before.
How do you control TLBs versions ? The TLB file is in a binary format and conflict resolutions are very hard to do. We tried to do it exporting the interfaces descriptions to IDL and commiting into CVS, but we didn't found any good way to generate TLBs from IDL using Delphi. Additionaly, the MIDL tool provided by Microsoft, didn't parse correctly the IDL files that we exported from delphi.
I think you should have a good look at Delphi 2009.
Delphi 2009 has changes to the COM support, including a text-based replacement for the binary TLB files.
You can read more on Chris Bensen's blog.
In the distant past (before I started working for CodeGear) I gave up on the odd Delphi-ized IDL language that the IDE presented, and wrote my own IDL and compiled it using MS midl. This largely worked; the only catch, IIRC, was making sure dispids (id attribute) were correct on automation interfaces (dispinterfaces) for property getters & setters - there was some invariant that tlibimp expected but midl didn't guarantee.
However, now that Delphi 2009 uses a safe subset of midl syntax, and includes a compiler for this midl in the box and integrated into the IDE, these problems should be a thing of the past.
We have also just installed Delphi 2009 and it does seem to have improved the support for Typelibraries. However I have worked with COM and type libraries for quite some time and here are my general gotchas that I have found over the years. I would agree its pretty buggy and is all the way up to Delphi 2006 (our version prior to using 2009).
Always have every file writeable before opening. This may sound obvious, but when working with source control sometimes we forget to do this and try to remove readonly flag after opening a file - Delphi cant deal with this. Ensure tlb is writable before opening.
If editing a standalone typelibrary you MUST have a project open. For some reason if you open a type library on its own it will not save. Create a blank project and then open your typelibrary. For some reason this allows the type library to be saved.
If your type library is used by an application or COM+ ensure that application is shut down or COM+ disabled before opening the type library. Any open apps will prevent the type library from being saved.
However I think your best solution is probably an upgrade. You get Unicode support too.
Using Delphi 2009 has greatly taken much of the pain out of huge TLB files, and conversion of our existing objects was painless, but our com objects don't use any third party libraries.
We will be migrating our gui applications over once the library vendors release supported versions.
Same experience with the TLB interface here: we simply stopped using it.
We work with several separate IDL files (hand-build) for different parts of our framework, making use of the #include construct to include them into the IDL of the actual application, then generate the single tlb using MIDL and tlibimp it. If the application has no IDL of it's own, pre-compiled version of the different framework TLB files are available.
Whenever the framework enters a new version, a script is run to re-generate the GUIDS on all necessary interfaces in the IDL files.
This has served us well for many years, and for us to move over the new Delphi 2009 IDL/TLB toolset will have to be not only integrated into the IDE, but also versatile when it comes to automated builds and whatnot. Can't wait to get my hands dirty with some experiments!