|
Larry, What you COULD do is to define your procedure which actually DOES stuff (and includes the static variables) as internal only (i.e. not exported) and then create a number of exported procedures in the same module which are effectively 'shell' wrappers to your internal procedure - they simply apss parameters and receive a return value or whatever). Thus you could have an internal unexported procedure called "I_ProcessData()" and a number of other exported procedures such as "CreateData()", "DeleteData()", "InitializeData()" etc. OK, you'd still need to include a 'mode' parameter from each of them, but this method can make for a nice clean implementation, as well as shielding all your exported wrapper procedures from changes to the structure of the data itself. Even if you need to make changes to the internal procedure parameters, you only need to change the exported procedure internals, not the procedures which call them. For instance, I have a module in a service program which includes a single internal procedure which loads data from a file into a statically defined array and then 10 wrapper procedures to load the array from the file, retrieve entries from the array, based on different key combinations and also clear the array and reset all its related static variables (it's a useful technique if you have an application which needs to get control file data quickly and you don't want to deal with lots of file I/O). Just a thought... Rory
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.