×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Joe Pluta wrote:
... But if you're not, then changing the number of
parms is as good a way to communicate as any. If you normally DO pass
parameters, then DON'T pass any to signal a initialization. If you
normally DON'T pass any parameters, then DO pass one to signal
initialization.
A problem with this technique is that you have to make all the
parameters *NOPASS. There's a way to get around it: Create a second
prototype for the procedure with the same EXTPROC, but no parameters;
call it something like myproc_reset. Then when you want the procedure
to reset itself, call myproc_reset() instead of myproc(parms).
I'm of at least two minds about the relative goodness of the two
techniques, but the "lying to the compiler" aspect of having two
prototypes for a procedure seems less likely to cause maintenance
problems that having all the parameters for the normal call be
options(*nopass).
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.
midrange.com
