An advanced - and possibly useless - technique in Priority

Someone asked how to execute a procedure within a form trigger. It's easy to execute a predefined external program such as 'sonraw' (explodes bills of materials) -

EXECUTE SONRAW :TMPART, SQL.DATE8, :ARC, 0;

but I assume that this was not what the person was asking. Rather, he wanted to execute a procedure which he had written in Priority from within a trigger. I can't think of any real reason to want to do this: passing data in the procedure is problematic and getting data out is even more problematic. Hopefully the person who asked the question will reveal what his motives are.

The answer came to me last night out of the blue. I had awoken in the middle of the night with my mind buzzing with ideas following a meeting in which I had participated earlier during the day. One of the ideas would require implementing a trigger in a standard form, and suddenly the solution to another problem - invoking an internal procedure from within a trigger - popped into my mind.

Looking back on the process now, I can see that there was some mental preparation: a few days earlier I had written a procedure which causes a report to be sent automatically to people via email. This procedure uses a certain technique to invoke an internal report, so it wasn't much of a mental jump to realise that I could use the same technique to invoke a procedure by subtly changing its parameters.

Here is the called procedure: its name is XXXX_TEST and it receives one parameter, STK, of type FILE. All the procedure does is create an external text file containing the values which had been passed.

LINK STACK TO :$.PAR;
WRNMSG 1 WHERE :RETVAL <= 0;
SELECT ITOA (ELEMENT) FROM STACK TABS 'R:/1.TXT';
UNLINK STACK;

The trigger which calls this procedure is as follows

SELECT SQL.TMPFILE INTO :STK FROM DUMMY;
LINK STACK TO :STK;
INSERT INTO STACK (ELEMENT)
VALUES (:$.ID);
EXECUTE WINACTIV '-P', 'XXXX_TEST', 'STACK', :STK;
UNLINK AND REMOVE STACK;

After running the screen which activates the trigger, I discovered that I had created a text file, R:/1.txt, with the contents 0, 1336; just as I expected.