Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As far as I understand it what you've got should be perfectly valid. A little awkward but valid.</p> <p>But a better way might be to declare a variable in Unit B and have B initialize/finalize it. Since initializations happen before any other code is called it will be initialize before it is made available to Unit A as long as it is declared in the uses clause of Unit A. </p> <p>One other step you might want to consider is taking the unit variable of B one step further and have it as a function call for on demand loading, but that might also be dependant on your usage.</p> <p>for example</p> <pre><code>unit unitB; interface type TFoo = class // code... end; // code.... function UnitVarB:TFoo; implementation var gUnitVarB : TFoo; function UnitVarB:TFoo begin if not assigned(gUnitVarB) then gUnitVarB := TFoo.Create; result := gUnitVarB; end; finalization if assigned(gUnitVarB) then gUnitVarB.free; //or FreeAndNil(gUnitVarB); end; unit unitA; // code.. implementation uses unitB; var A: TStringList; //code... ...UnitVarB.... //code... initialization A:= TStringList.Create; finalization A.Free; end. </code></pre> <p>I seem to remember somewhere that unit initializations could be expensive in that if a unit that you no longer directly reference is still in your uses clause during a compile, the smart linker will not remove it because of the initialization section. While this may not sound that bad if every unit had an initialization section then most Delphi programs would be <em>MUCH</em> bigger than they already are. </p> <p>I'm not saying don't use them but my rule of thumb is to use them sparingly.</p> <p>Your initial code example breaks that rule. I thought I'd mention it.</p> <p>Ryan</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload