Can I prevent XE8 from adding System.ImageList?

Question

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?

Mintun

Better write {$IF CompilerVersion >= 29}System.ImageList, {$IFEND}. – Ruthenious

Or create a unit alias to System that is only defined in your XE7 project. Trying to have your dev team using different versions is not a great idea. – Darling

Or have everyone go back to XE7 until you are ready to move en masse to XE8. If you continue the way you are you'll just be doing ping pong between yourselves. – Darling

TLama's answer $IF CompilerVersion >= 29 should be an accepted answer IMHO. It is not always possible to keep developers environments all in sync for various reasons such as licensing or developer stubbornness for instance. – Rathe

Answer 1

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.

Darling

I usually go the way with the dummy unit placed in a special folder, which I add directly to the older IDE library path. This helps to keep the dpr clean and works for all projects right from the beginning. – Naphthol

Answer 2

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;

Starwort

While this code may answer the question, providing additional context regarding how and/or why it solves the problem would improve the answer's long-term value. – Hurtless