×
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.
On Feb 7, 2008 4:02 PM, Barbara Morris <bmorris@xxxxxxxxxx> wrote:
Barbara Morris wrote:
I forgot to say that using EXTPROC('myproc') will only work if the
procedure is exported.
If the procedure is local to the module, you have to use this technique
to call it with a different prototype.
D myproc pr
D ... parms ...
D myproc_reset pr extproc(myproc_procptr)
D myproc_procptr s * procptr inz(%paddr(myproc))
--
Something strange I've noticed about pointer based procedures and EXPORT.
I have a program that, instead of using compile time, top down logic (nested
if/then/else structures) uses run time bottom up logic (state machine).
*
* ... pointer based procedures ...
*
d procProxy pr * ProcPtr ExtProc(procProxy@)
*
* ... standalone variables ...
*
d procProxy@ s * ProcPtr
d seed s Like(pmSeed) Inz(0)
*
* Mainline
*
/free
*InLR = *On;
procProxy@ = init(seed);
DoU ( procProxy@ = *NULL );
procProxy@ = procProxy();
EndDo;
eoj();
Return;
BegSR *INZSR;
//
// seed for random number generator
//
If ( %PARMS >= 1 );
seed = pmSeed;
EndIf;
EndSR;
/end-free
This program is bound to a module containing:
init()
eoj()
reset() (possibly)
plus one or more unknown procedures.
The init routine returns the pointer of the first procedure
to be executed. Every executed procedure returns a pointer to the
next procedure to be executed (or *NULL upon end of job).
What I find curious is that the only procedures that have
to be exported are init() and eoj(); I can execute the private
procedures (through a pointer based procedure) if I know
their addresses.
I like this; I can table drive my logic at run time.
Chris
--
www.brilligware.com
midrange.com
