A Form in XE8 gets automatically the uses System.ImageList added. Like on the embarcadero site is said:
System.ImageList contains the common for both FireMonkey and VCL code implementing the most basic device-independent features of image lists. System.ImageList contains the code supporting interaction between images in an image list and using them components (like controls, menu items, and so on).
But my colleagues are mostly still using XE7. Now, they need to remove that uses constantly after my commit. My XE8 automatically adds this uses when I would remove it. I could remove the uses before I commit with another editor of course. But it would be more productive when I could prevent XE8 from adding this part of code. Or would Firemonkey and VCL stop working properly?
So my question is: Can I prevent XE8 from adding System.ImageList to my uses in a Form?
Can I prevent XE8 from adding System.ImageList to my uses in a Form?
No. The IDE will do this come what may. Your options include:
Wrapping the unit in a conditional so that the XE7 compiler does not see it.
Create a dummy, empty unit, named System.ImageList, that you list in the .dpr file, again wrapped in a conditional so that it is only seen by the XE7 compiler.
Maintain separate .dproj files for the different versions. In the XE7 version add a unit alias that maps System.ImageList to System.
Removing the unit before committing using a text editor or a script.
Having your team standardise on a common version of Delphi.
Personally I would recommend the latter option. Remember that you can happily install multiple Delphi versions side-by-side and, if necessary, use different versions for different projects. This is essential when maintaining release branches of your program.
If you simply cannot do this then the unit alias is perhaps the least invasive option. I guess you don't have the .dproj file under revision control because if you did then you'd be facing similar issues with XE7 modifying the XE8 version and vice versa. So if the .dproj file is outside revision control it should be easy enough to make the modifications locally just for the XE7 users. But a trick like that should only ever be viewed as a temporary stepping stone to keep you afloat until you are all on the same version of Delphi.
More generally, Embarcadero are currently releasing new versions very frequently. It costs time to upgrade. You have to install, iron out any compilation problems, test the build under the compiler, and deal with any defects that arise. You don't have to take every upgrade. It's fine to skip some. It can be more efficient to do so. At my workplace we moved from XE3 to XE7 and are not going to take XE8. If you do take an upgrade, make sure the benefits outweigh the costs.
This code enables System.ImageList only in XE8 and later versions
uses
System.Classes,
System.SysUtils,
{$IF CompilerVersion >= 29}System.ImageList,{$IFEND}
VCL.Forms,
VCL.Dialogs,
VCL.StdCtrls,
VCL.Controls,
VCL.Buttons,
Vcl.ExtCtrls,
Vcl.ImgList,
Vcl.ComCtrls,
Vcl.ToolWin;
Related
I have a VCL component that runs on Delphi 7 to 10.3. I am now porting it to FMX.
To avoid maintaining two codebases, I will use conditional defines in my source to separate any custom FMX and VCL code. When I compile the component for distribution a script will output either the VCL or FMX source files.
My problem is how to make the VCL DCUs and FMX DCUs co-exist on the same system (for users who have both the VCL and FMX versions of my component) as both folders will need to be on the Delphi path.
In other words, my VCL units are named: myunit1.pas, myunit2.pas, etc.
And the FMX versions: fmx.myunit1.pas, fmx.myunit2.pas, etc
(Ideally I would name the VCL ones vcl.myunit1.pas, vcl.myunit2.pas, etc. That way the VCL version of the component would only see the vcl.-.pas files and the FireMonkey only the fmx.-.pas files. Unfortunately I cannot do this because then it won't work on older Delphi versions).
Now when I compile a FireMonkey app it tries to use the non-fmx prefixed source files, in preference to the fmx._.pas ones. I need to "hide" the vcl source folder to get it to compile (re-ordering the Delphi paths does not help).
If there another way to make FireMonkey avoid using the vcl files?
(I fear I will need to write a script to give all the files a new name, e.g. FMXmyunit1.pas and update all of the references in all of the files).
Because Delphi does not provide predefined compiler conditionals to distinguish between the Firemonkey and the VCL framework you can add the symbol $(FrameworkType) into the conditional defines list of the application project settings. This enables the differentiation of the framework within your library by using the conditional compiling symbols FMX and VCL.
Example of typical usage:
uses
{$IFDEF FMX}
FMX.Forms,
{$ENDIF}
{$IFDEF VCL}
VCL.Forms,
{$ENDIF}
This works in my own cross-platform library for pure VCL and FMX projects, where I let integrate the source files directly into the project. In this simple way, the DCU will be recompiled each time. In the case of mixed projects, the $(FrameworkType) contains the initial framework of the application.
When you deliver a package (bpl) things get more complex. You must provide two versions of your bpl for FMX and VCL. If you also provide the source code for debugging purposes, the only option is to completely differentiate the source code files for the FMX and VCL versions, as long as they have platform-dependent code.
Well, I don't know if it's really a solution, but it works for me.
I wrote an application that copies all my VCL files to my FireMonkey folder and renames them with an FMX prefix, i.e myunit.pas becomes FMXmyunit.pas. It also updates all the references in the pas files and adds a {$DEFINE FMX} to the header. Now both my VCL and FMX versions coexist happily.
Also, I have set my merge tool (Beyond Compare) to ignore the FMX prefix, so I can merge either platform version directly to my local Git copy.
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 trying to modify my Delphi 2010 code to compile in XE7 (and want to retain the ability to compile it in 2010). So in the unit that houses my mainform I added conditional directives. The following works fine in 2010
uses
{$IF CompilerVersion >= 24}System.Actions, {$ELSE}Actnlist,{$IFEND}
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;
But XE7 automatically adds a System.Actions at the end to create a uses clause that now has System.Actions declared twice (see below), and gives an error message [dcc32 Error] MyForm.pas(10): E2004 Identifier redeclared: 'System.Actions'. Why is XE7 not accepting the unit from within the conditional directive ?
uses
{$IF CompilerVersion >= 24}System.Actions, {$ELSE}Actnlist,{$IFEND}
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
System.Actions; // <- automatically added
As Ken says, the interface uses clause will be modified by the IDE and the processes by which this is achieved are somewhat less than sophisticated (as you have discovered). The same problem affects the project uses clause. Unfortunately this is much harder to avoid in the case of Form/DataModule uses clauses.
You could use a Unit Alias (see David Heffernan's answer) but need to be aware that if you create an alias for a unit that the IDE wishes to add, then the IDE will still add a reference to the required unit since it does not recognise the alias as identifying that required unit. Aliasing to the System unit will avoid this since it is already (implicitly) used by every unit.
Another alternative is to remove all such conditionals from your uses list and instead create place-holder units as required so that the different compilers you wish to use on the project can each be satisfied by the single uses list combined from the list that each IDE insists is required (the IDE won't remove unused units from the uses list, something that is often a complaint but in this case actually helps solve your problem).
In this case, in your Delphi 2010 project create an empty Actions unit:
unit Actions;
interface
implementation
end.
You will of course need to ensure that this unit is not in the project path for your XE7 version of the project.
One way to achieve that would be ensure that the empty Actions.pas unit is not explicitly listed in the DPR uses list, but is placed in a subfolder of your project source (e.g. 'placeholders'). You can then add this subfolder to the project search path for the Delphi 2010 version but not the XE7 version:
\Project Folder
project2010.dpr
project2010.dproj
projectXE7.dpr
projectXE7.dproj
\placeholders
Actions.pas
If you find that you need placeholders for each of the different versions then you will need separate placeholder folders. You might create further version specific subfolders, for example:
\placeholders
\2010
Actions.pas
\XE7
D2010UnitNotPresentInXE7.pas
This sort of structure might be advisable simply from the point of view of creating an auto/self documenting organisation.
Note that this is only required for dealing with unit references in the uses clause of the interface section of Forms (or Frames etc). In non-visual units or in the implementation section, the IDE does not interfere so conditional compilation directives should present no issues there.
The easiest way to fix this is to add a unit alias to your Delphi 2010 project. You'll need to use different .dproj files for your different Delphi versions, but you need to do that anyway.
In the unit aliases settings for the Delphi 2010 project add this:
Actions=System
I'm using System as the alias target because the System unit is automatically included in every Delphi unit and so aliased inclusions are benign. It's the simplest way that I can think of to make the compiler effectively ignore an entry in a uses clause.
Then you can declare your uses clause like this:
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
Actions, Actnlist;
This will compile fine in Delphi 2010, because the alias processing will map Actions onto System. In XE7 you are also fine because there is no alias, and the IDE is satisfied by the presence of the Actions unit and so feels no compulsion to modify the uses clause.
Would there be something wrong with
{$IF CompilerVersion < 24}Actnlist,{$IFEND}
or is this an academic argument?
Addendum...
Then add a dummy System.Actions.dcu containing nothing into your 2010 compile-path.
I'd theorise that the IDE would then insist on inserting uses ... System.Actions, 2010 has what it wants, XE7 has what it wants.
But I don't have XE7 so I can't test it out.
we had the same issue...
The easiest way is to do it that way:
{$IF CompilerVersion < 24}{$ELSE}System.Actions,{$IFEND}
{$IF CompilerVersion >= 24}{$ELSE}Actnlist,{$IFEND}
If you open the file in old IDE's, than you may see an error, which says "unit X" not found, but it will compile fine and no automatic adding is performed.
It looks not so nice, but it works quite well...
Kind regards,
Bernd
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.
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