Get a handler from a script

David Burgun dburgun at
Mon Mar 20 07:24:05 EST 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  
"end" text.

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.
> gc
> On Mar 19, 2006, at 4:22 PM, Dick Kriesel wrote:
>> On 3/19/06 3:41 PM, "Alex Tweedly" <alex at> wrote:
>>> You should try that script on itself :-)
>>> The "/*" in the first 'offset' line, and the "*/" in the second  
>>> 'offset'
>>> 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
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:

More information about the Use-livecode mailing list