Get a handler from a script
dburgun at dsl.pipex.com
Mon Mar 20 06:24:05 CST 2006
Yes, this really is the problem. In order to parse and identify a
function/handler 100% correctly you need to do most (if not all) of
the work of the TranScript Parser in the Script Compiler. In the past
I've written any number of language parsers and I know it is non-
trivial to get it 100% right. The best solution IMO would be to add
code to RunRev that allows the script to find out if a handler/
function is defined or not. One way would be to add a function that
checks for the existence of a hanlder/function (without looking at
the text of the script), another would be to hold an array of
functions/handlers as a property of the Object. For instance if the
script compiler built two arrays and stored them as a property of the
functionArray["FuncrtionName"] = StartLine,EndLine
handlerArray["HandlerName"] = StartLine,EndLine
Where StartLine is the line number in the script that contains the
"on" or "function" text.
Where LineLine is the line number is the script that contains the
I should imagine it is possible to parse the script and get it 100%
correct using TranScript, but:
1. It is likely to be quite a bit of work to code/test.
2. If the underlying script syntax is changed it could break.
3. It is likely be very slow and impact performance badly unless you
are very careful about how/when it was used. One way would be to run
some code at preOpenStack time that scanned through the scripts of
objects in the stack and built the arrays described above.
I was quite shocked when I discovered that the ability to check for
the existence of a function/handler was not actually built into to
RunRev when so much other information about objects is present.
All the Best
On 20 Mar 2006, at 01:12, Geoff Canyon wrote:
> I feel like the harbinger of doom here (with Alex as my able
> partner in doomsaying) but:
> This would still be subject to failure if, anywhere in the script, /
> * or */ appeared _not_ as block comment delimiters, but as part of
> a string.
> On Mar 19, 2006, at 4:22 PM, Dick Kriesel wrote:
>> On 3/19/06 3:41 PM, "Alex Tweedly" <alex at tweedly.net> wrote:
>>> You should try that script on itself :-)
>>> The "/*" in the first 'offset' line, and the "*/" in the second
>>> line are (incorrectly) recognized as a block comment, with fairly
>>> disastrous results.
>> I did, and verified that it removed the comment. I didn't notice
>> that it
>> also eviscerated the function! A trivial fix avoids that problem:
>> on mouseUp
>> put removeBlockComments(the script of me)
>> end mouseUp
>> /* this is a comment
>> as is this */function removeBlockComments pText
>> put pText into tText
>> put offset("/" & "*",tText) into tOffset
>> if tOffset > 0 then
>> delete char tOffset to tOffset + offset("*" & "/",tText,tOffset)
>> + 1 \
>> of tText
>> put removeBlockComments(tText) into tText
>> end if
>> return tText
>> end removeBlockComments
>>> I suspect that proper recognition of block comments
>>> isn't as easy as it might seem - need to handle all forms of string
>>> delimiter, which themselves may be inside comments.
>> Since I don't recognize that need, would you elaborate on it, please?
>> Thanks for catching my oversight, Alex.
>> -- Dick
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode