In compiling a Delphi 2007 project, I receive the following error:
E203: Undeclared identifier: TChangeLink
This appears to belong to the Vcl > ImgList library.
My limited understanding is that Vcl is part of the native Delphi libraries. How do I verify that it is correctly referenced?
It's because ImgList isn't in your uses clause. Based on information you provided in a comment,
uses contains this line:
Clipbrd{$IFDEF DELPHI4}, ImgList {$ENDIF}, dxCommon{$IFDEF DELPHI6}, Variants{$ENDIF}
It's because the {$IFDEF DELPHI4} is excluding it, presumably because DELPHI4 isn't defined. This is typically caused by using code that is in open-source or commercial component sets that use those version defines to support multiple Delphi versions with the same source. (This is usually done in a .INC file of some sort; Jedi uses JEDI.INC, for instance, for all of the version defines for various compiler and IDE related differences.)
The best solution (to maintain cross-version compatibility) would be to update the definitions to include Delphi 2007, but I can't offer advice on how to do so because I don't know where the define is located. The other alternative is to just remove the {$IFDEF DELPHI4} from the uses clause, if you don't need to worry about earlier versions of the IDE/compiler.
Related
Why can't I uses Generics.Collections or Generics.Default or even just Generics in Lazarus?
Uses
Generics.Collections;
Uses
System.Generics.Default;
Uses
System.Generics.Collections;
Uses
System.Generics.Default,
System.Generics.Collections;
Uses
SysUtils,
Generics;
Cannot find Generics.Collections used by uTest of the Project Inspector.
Cannot find Generics.Defaults used by uTest of the Project Inspector.
Cannot find Generics used by uTest of the Project Inspector.
Lazarus is the IDE for the open-source FreePascal compiler. Neither of them have ANYTHING to do with Delphi. FreePascal is a completely separate Pascal compiler than the one Delphi uses.
FreePascal has a Delphi compatibility mode, and does implement various Delphi units and classes, to help users port existing Delphi code to FreePascal.
But as far as Generics is concerned, FreePascal provides its own Generics syntax and implementation that is different from, and not compatible with, Delphi's Generics (actually, support for Delphi-style Generics was added in FreePascal 2.6, but "still may be not 100% compatible" with Delphi. Also see delphi language features which fpc does not have - Generics Syntax).
Read FreePascal's documentation for more details about its flavor of Generics:
http://wiki.freepascal.org/Generics
http://www.freepascal.org/docs-html/ref/refch8.html
The System.Generics.Default and System.Generics.Collections units are only available in Delphi, they do not exist in FreePascal. However, there is a 3rd party implementation of these units available for FreePascal.
Generics.Collections library (with Generics.Defaults module) has been added to FPC trunk as rtl-generics package in r34229. Latest version of precompiled FPC trunk (with Generics.Collections) for Win32 + Lazarus trunk available at http://newpascal.org . The repository of Generics.Collections ( https://github.com/dathox/generics.collections ) will be still used for maintenance (should be synced often with FPC trunk).
I recomend you to use the Generics.Collections package made by Maciej Izak.
I'm using Anders Melander's DragDrop package.
It works fine in Win32 mode, but needs adjustment for 64 bit.
I do this by adding {$IFNDEF CPUX64} to comment out the references to the designIDE.
However when I change the package source from
requires
rtl,
DesignIDE;
to
requires
rtl
{$IFNDEF CPUX64} ,DesignIDE{$ENDIF};
The compiler simply throws away the DesignIDE line in the package source, leaving only:
requires
rtl;
Which works fine for X64, but breaks as soon as I rebuilt for 32-bit.
Is there a way to have one package including design-time items for win32 with the conflicting items IFDEF'ed out for X64? Or am I forced to create a separate Runtime package for X64?
No, you cannot use conditionals in any project main file. The IDE owns and controls it, and is subject to discarding (and even destroying) any customization you do with conditionals. You will need to create a second package for this, which is normal practice for using DesignIDE anyway. Even if it weren't for supporting 64bit, you're not permitted to deploy DesignIDE with any application. It is for the sole purpose of integrating with the IDE, which for legal reasons, must only reside in a Design-Time package.
Bear in mind also that the Design-Time package must only be Win32, as the Delphi IDE is only 32bit. Then, the Run-Time package can be any supported platform you wish (i.e. Win64), of course as long as it's supported by any framework it might be using.
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.
I am upgrading from Delphi 6 to Delphi XE. In Delphi 6 I was using HTML help files (.chm) and used the StoHtmlHelp to make it so that I could call context sensitive help like we used to call .hlp files. I'm upgrading to Delphi XE so I need to use that native HTML help support.
I know I'm supposed to add HTMLHelpViewer to the uses clause of the project, but when I do I get a compiler warning that it couldn't find the file.
Could not compile used unit 'HTMLHelpViewer.pas'
Does anyone know why Delphi isn't finding this file by default? It should be built in.
Not being able to compile a file and not finding a file arent't the same thing. If Delphi is trying to compile HTMLHelpViewer.pas you must either:
have the vcl source folder(s) on your library path (not recommended), or
another HTMLHelpViewer.pas file is somewhere on your library path, that path comes before the standard Delphi lib folder, and that HTMLHelpViewer.pas file contains something that Delphi XE is not happy about.
The first is not likely and it would be very strange indeed if Delphi could not compile one of its units (apart from system.pas).
The second seems more likely... And if that unit used to compile, the complaints from Delphi XE could well be due to differences between Delphi 6 and Delphi XE.
You don't actually need to add it the uses clause of the .dpr file – you just need to use it from some unit in your project.
Having said that, you may actually prefer to add it to your .dpr file, and if so then do it like this:
uses
Forms,
HtmlHelpViewer,
MyUnit in 'MyUnit.pas',
I'm guessing that you have something like this:
uses
Forms,
HtmlHelpViewer in 'C:\Program Files\Borland\Delphi6\Source\VCL\HtmlHelpViewer.pas',
MyUnit in 'MyUnit.pas',
This will fail because you are asking XE to compile D6 source.
For RTL/VCL units its best to omit the path to the file and let the compiler find it (it knows where to look).
In this question (link) it was said that the line below (in each unit) would remove as much RTTI as possible:
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
The posting didn't mention what Delphi version it works with, but I assume D2010. However, when I include the line above, I get this error:
DCC Fatal Error: E2158 System unit out of date or corrupted:
missing TVisibilityClasses.
I'm using a "stock" version of D2010 and have never done anything that I'm aware of that would change the default installation or the libraries.
Any suggestions? TIA
Related question: link.
Make sure you put the "{$RTTI" line below the "unit unit1;" line.
Note that as of XE5 and newer, this directive needs to be in each individual unit for which you want to disable RTTI. Before that (as in comments, which applies only to XE4 and below) it could be in the DPR file and would apply to all units in the project.
The new RTTI is for Delphi 2010 and up.
It can be removed, but then lots of things will have limited functionality (like JSON conversion, part of DataSnap and many of the newer 3rd party libraries that do ORM or other mappings).
Things depending on TValue are gone anyway.
"old style" RTTI (which was introduced in Delphi 1 and is still present in Delphi 2010) cannot be removed.
So: it is recommended to remove RTTI only from your own units, and not from the RTL and VCL.
--jeroen