edhasted
asked on
Where to declare variables when using Procedures held in used units?
I've got a program made up of 20+ units that I am trying to clean up.
Several of them use the same procedure, so it makes sense to put the common routines into a separate unit and call the routines as required. That way the code only exists once.
But these routines have a lot of variables which are declared in the parent unit.
When I compile the shared routine I get lots of "Undeclared Identifier" errors (what a surprise!)
PARENT
Declares the variables
Has a USE to the shared routine
Call the shared routine
ROUTINE
has the common procedure
Where should I declare the variables? Or do I need to make them all global and be done with it?
Ed
procedure LoadPerCentData;
Several of them use the same procedure, so it makes sense to put the common routines into a separate unit and call the routines as required. That way the code only exists once.
But these routines have a lot of variables which are declared in the parent unit.
When I compile the shared routine I get lots of "Undeclared Identifier" errors (what a surprise!)
PARENT
Declares the variables
Has a USE to the shared routine
Call the shared routine
ROUTINE
has the common procedure
Where should I declare the variables? Or do I need to make them all global and be done with it?
Ed
procedure LoadPerCentData;
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can also pass variables as parameter to your routine. This will increase the work and effort but will make your routine generic.
or, if there are many such variables, you can put all of them in a record, declare it global and pass it around the routins (it's a used method in delphi. see for example TFormatSetting structure ;) ). this also allows a better concurrent access control and easier copying the variables between threads/applications. but now I'm getting into too many details/complications
I would go with ciuly suggestion, it is very extensible, you just have to pass one variable around (of the type of the record) and if you need a new variable, you just add it to the record and voila, is available
Programming 101. No Globals...
ASKER
Will work on this over the weekend - many thanks - Ed
@kfoster11
Globals have their place, and, as has been pointed out, even Borland use them on occasion.
Globals have their place, and, as has been pointed out, even Borland use them on occasion.
ASKER
Hope to get some time to work on this today - very many thanks for everyone's input - Ed
ASKER
Many thanks to you all - I appreciate the issues with Globals but for this little piece of jobbing code it hit the mark.
With best wishes,
Ed
With best wishes,
Ed