I worked on my school IT project from home, on a newer Delphi (RAD Studio 10 Seattle). Now when I copied my program to work on it at school (Delphi 2010), it got an error when compiling Vcl.Forms.Dcu not found.
I have looked at other StackOverflow questions and my Unit Output Library is correctly set to $(BDSCOMMONDIR)\Dcp, so I do not know what is the problem.
The VCL unit prefixing was added in XE2 to differentiate between same-named units in the VCL and (newly added) FMX frameworks. Removing the Vcl. prefix will correct the error.
Unit Scope Names were introduced in XE2, so the Vcl.Forms unit does not exist in Delphi 2010, it was still known as Forms instead.
The correct solution in this situation is to refer to the Forms unit in your code as simply Forms, not as Vcl.Forms. In your Seattle project options, make sure that Vcl is listed in the compiler's Unit scope names configuation field.
This way, when compiling the code, D2010 will look for Forms.dcu only, and Seattle will look for Vcl.Forms.dcu when it cannot find Forms.dcu.
Related
I'm using Delphi 10.3.3. Today, I added a TActionManager to a form containing a TCheckList and set a few actions.
When I tried to compile, the IDE insisted on adding IDETheme.ActnCtrls to my Uses list, then failed to compile because it couldn't find the file.
I've been using Delphi since Borland Pascal, and this one is new to me.
What can I do? I've tried deleting, building instead of compiling, starting a new unit, a new project, restarting the IDE and starting a new project.
John Treder
Known issue in 10.3.3:
RSP-27035: [dcc32 Fatal Error] F2613 Unit 'IDETheme.ActnCtrls' not found.
Marco Cantu said:
Unfortunately there is a an incorrect dependency in the IDE. If you close the file unit from the IDE, and remove that uses statement with another editor, it should compile (from the IDE) and work correctly. We are looking into a solution
Patrick Premartin said:
il you add an empty unit named IDETheme.ActnCtrls to the project, you probably can compile without changing source file outside Delphi
A patch was released for the issue:
#30903: RAD Studio 10.3.3 IDE and VCL Patch
I found a workaround for a bug (QC#25702) in the Delphi VCL unit Grids.pas, so I copied that file to my project's source folder, added it to the project and changed a few lines of code. That was with Delphi 2007, and everything worked as expected.
Now, with Delphi XE2, the project no longer compiles. It complains about incompatible types "TCustomGrid" and "TdzVirtualStringGrid" (which is a descendant of TCustomGrid). It turns out that one unit refers to TCustomGrid as declared in my copy of Grids.pas, the other to TCustomGrid as declared in Vcl.Grids.pas. This happens even though both units have "Grids" in their uses clause (rather than Vcl.Grids). Any idea how I could solve this?
Your problem is that you are including the Delphi 2007 Grids unit in your XE2 project. That won't work at all. What you need to do to modify an RTL/VCL unit in this way is as follows:
Start with the source code for the unit supplied with the Delphi version that you are using. In this case start with Vcl.Grids.pas supplied with XE2.
Make a copy of that unit inside your project directory, and add that unit to your project.
Make any modifications to the implementation section of the copied unit.
I'm moving my code to Delphi XE3 from XE2, but it should compile in both. I notice that some units get 'System.Actions' auto added to the USES clause. This then causes an error when returning to XE2 with:
F1026 File not found: 'System.Actions.dcu' (unit scope "System" indicates Win64, OSX32, Win32 only)
I've never really understood unit scope properly. Is there a correct solution to resolve this rather than wrapping stuff within compiler version {$IFDEF}'s?
Thanks
There is no Actions unit in XE2. It is new in XE3, as part of refactoring work to bring Actions support into FireMonkey. This is documented:
What's New in Delphi and C++Builder XE3:
Actions: FireMonkey now supports actions and action lists, two features that were previously supported only in VCL:
Important: Every FireMonkey or VCL application that uses actions must specify the System.Actions and System.Classes units in the uses section.
Changes in Implementation of VCL Actions
The System.Actions unit is created in the RTL package. Classes from the Vcl.ActnList unit that provide framework-independent action features are moved into this unit. Classes in System.Actions extend the most fundamental behavior of action features introduced in the TBasicAction and TBasicActionLink classes.
Important: As a result of these changes, you need to add the System.Classes and System.Actions units into the uses section.
Implementation of Actions in FireMonkey and VCL
FireMonkey (FMX)
The framework-independent implementation is common to FireMonkey and VCL:
This basic actions functionality is extended in the new System.Actions RTL unit.
VCL
Framework-independent action features that were implemented in the Vcl.ActnList unit in previous RAD Studio releases are now in the new System.Actions unit in the RTL (common to VCL and FireMonkey).
Important: As a result of these changes, you need to add the System.Actions unit to the uses section (or #includes) in your VCL applications that use actions.
You will have to either remove the reference to Actions if you are not actually using actions in your code, or else {$IFDEF} it out.
What Remy said is quite correct, but there may be an easier way to make your code work in both XE2 and XE3. Simply add a unit alias from System.Actions to Vcl.ActnList.
Add this in your project options, on the Delphi Compiler page. You need to add the following:
System.Actions=Vcl.ActnList
Note that if you need to compile in both XE2 and XE3 using the same .dproj file then you are out of luck. That unit alias setting will stop the program compiling under XE3. However, if you have have different .dproj files for XE2 and XE3, then this will allow you to use the same source in both. Or, if you only need to compile for XE2 at the command line, then you could add this unit alias there. I can't tell whether or not this will help you, but I know that the unit alias feature has helped me out of a similar spot on more than one occasion in the past.
If you have ONE project file you still can solve the problem with a "dummy" System.Actions.pas file in your project path directory:
This file will be taken under XE2.
The XE3 compiler will find his System.Actions.dcu in the IDE /lib directory.
Anyway: In normal cases you should use different project files - then the solution with the unit alias is recommended.
The dummy System.Actions.pas could look like:
unit System.Actions;
(*
XE2 compatibility unit: since XE3 unit System.Actions will be inserted into every
interface in units which use actions.
compilerswitch in [uses] is ignored by IDE - so this solution enable successful
compilation in XE2 with same project file than XE3
*)
interface
implementation
end.
First of all, I have never written a property editor from scratch, but had some help with one in another question. Refer to the accepted answer there. This was in Delphi 7, and now I have started using XE2 and I have to make sure my property editor is compatible with both 7 and XE2.
It's essentially a collection editor, with the difference that each collection item has its own named component in the parent form. Is there anything new about the property editors in XE2 since 7, since it is a huge version jump?
I do NOT want to make a complete copy of my unit for different versions. I want to maintain all possible versions in one unit.
Edit
It appears that Delphi XE2 has the same property editors as Delphi 7, but the issue I was facing was that although I was including DesignIDE in my package, it could not find anything, so I had to add the ToolsAPI folder to my library path.
However, now I have a new issue after this.
[DCC Fatal Error] ToolsAPI.pas(18): F1026 File not found: 'DockForm.dcu'
I'm lost in the whole concept of BPL packages and requiring others, etc.
DesignIntf, DesignEditors, DesignMenus, DesignWindows are part of DesignIDE.bpl and is found in \Embarcadero\RAD_Studio\9.0\lib\win32\release\designide.dcp. But there is no designide.dcp for 64bit which is why it throws an error when compiling a 64bit package that references these units.
There is no 64bit version of DesignIDE because it is for a design time package and design time packages are 32 bit only (remember Delphi IDE is still only 32 bits). So always set your design time package as 32bit, not 64bit. :)
Mike
The DockForm.pas source code is available neither in Delphi XE nor in Delphi XE2.
You may try this accepted answer posted on SO applying to similar issue on Delphi 2010.
Presumably, it is compiled and included within some package already distributed with Delphi XE2.
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