if Runtime
exposed a lower level API the xTalk,Transcript ... community could build language
extensions.
Frank,
As a business applications programmer, I rarely have occasion to program at the level you describe; so pardon me if I'm missing the big picture.
* One can extend the language to recognize new commands by writing handlers to perform the functionality and placing them in a library stack or other script.
* One can extend the language to recognize new commands by writing externals in C or another language and including the externals in a library stack or other stack.
* One cannot write one's own version of a Transcript command with the same name and place it in the message path ahead of the engine [just tested this]
So it seems to me one can EXTEND Transcript functionality without too much difficulty. The problem arises when one tries to MODIFY existing Transcript command functionality or add/change compiler syntax..
Before I wrote a handler to resolve SDB field name references to the correct record field at runtime, I gave some thought to writing a script preprocessor that would let the developer reference fields by dataname in the Script Editor and convert the script text to change references like "TYPE:dataName" to "item [fieldNumber] of TYPEBuffer -- >TYPE:dataName<" before compiling and to convert the references back when the developer reedits the script.
With such a preprocessor, you should be able to script "x=1" and have the preprocessor convert that to "put 1 into x" and vice versa.
I run out of ideas that don't require cooperation from the Run Rev team at this point.
--
Rob Cozens CCW, Serendipity Software Company http://www.oenolog.net/who.htm
"And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631) _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
