Why does “use unit” disappear when I have a new block?

I have a Unit test project for my application using the DUnit framework. This project has a unit surrounded by $IFDEF to output the test results to an xml file instead of gui or just the command line. The XML_OUTPUT definition is activated by switching the assembly configuration.

 program DelphiCodeToDoc_Tests; uses TestFramework, TextTestRunner, Sysutils, Forms, GUITestRunner, {$IFDEF XML_OUTPUT} XmlTestRunner2 in 'DUnit_addon\XmlTestRunner2.pas', {$ENDIF} DCTDSetupTests in 'IntegrationTests\DCTDSetupTests.pas', ... 

It works great. The problem starts with when I add a new block to this project from the IDE (new device with "File> New> Unit").

Testing project now:

 uses TestFramework, TextTestRunner, Sysutils, Forms, GUITestRunner, DCTDSetupTests in 'IntegrationTests\DCTDSetupTests.pas', ... MyNewUnit in 'IntegrationTests\MyNewUnit.pas'; 

As you can see, the XML_OUTPUT test has disappeared ... Each time I add a module, the Delphi IDE removes this test.

Do you know why and how I can avoid this?

+4
source share
5 answers

Only the code that is actually used is compiled into your application anyway, so it usually does not hurt to have units in Uses that are not used.

You can see all the code that is associated with your application when you run the program in your IDE. You should see blue dots next to all the compiled code.

The only caveat is that you should check the initialization section of the units that cause concern. Any code that is in the initialization section is automatically turned on by simply turning on the device, because any code in this section starts as soon as the application starts. You can add your compiler directive in the device initialization section, if necessary, to avoid binding the initialization and execution code.

+5
source

You can add a proxy block to the main program to circumvent this problematic behavior (which many of us consider a mistake, not a function).

 program DelphiCodeToDoc_Tests; uses ... XMLTestRunnerProxy, ... 

and

 unit XMLTestRunnerProxy; interface {$IFDEF XML_OUTPUT} uses XmlTestRunner2 in 'DUnit_addon\XmlTestRunner2.pas'; {$ENDIF} implementation end. 
+7
source

The DPR list uses a managed IDE. Unfortunately, there is nothing you can do about it. Officially, you should not put IFDEF in the middle of the list of DPR using , because it will do things like this.

I would do this by leaving the XmlTestRunner2 block in the project and placing the IFDEF inside the device itself so that if you do not have the XML_OUTPUT set, it will not compile anything.

+5
source

Stripping occurs anytime the IDE needs to modify the DPR USES clause. Using "Save As" to rename a device will do the same.

To get around this, I always create my new modules from the outside as an empty text file, and then add them to DPR manually. At first it’s a bit more, but in the end you only include units if necessary. Also note that when this happens, if you use anything later than Delphi 2005, you can go to the “History” tab at the bottom of the editing panel and copy the contents of the “Local file” to get the version until the moment the device was added and everything else was stripped.

And yes, this is a mistake. QC # 6294 and it is open, so Embarcadero is aware of this problem.

+5
source

Let's consider two projects. Once with additional code, without it. Then create what you want, or both. Using project groups, they will work well.

0
source

Source: https://habr.com/ru/post/1305686/


All Articles