matchText question

[Peter M. Brigham]

OK, so based on all this, here is a handler for getting a handler from the script of an object (watch linewraps).

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig

---------

function getHandlerFromScript pObjRef, pHandlerName, pType
   -- returns the specified handler from the script of pObjRef
   -- pHandlerName should be the bare name of the handler
   -- if you have duplicate handler names, eg, a function and a command with
   --    the same name, or getprop and setprop handlers with the same name,
   --    then both/all will be returned,
   -- unless you specify the optional pType as
   --    "function" or "command" or "getprop" or "setprop"
   -- if not found, returns "no such handler:" && pType && pHandlerName
   -- requires caseSwitch()
   
   put the script of pObjRef into tScript
   put the revAvailableHandlers of pObjRef into hList
   delete word 5 to -1 of line 1 of hList
   filter hList with "* " & pHandlerName & " *"
   put caseSwitch(pType,"function=F","command=M","getprop=G","setprop=S","*=*") \
         into tType
   if tType <> empty then
      filter hList with "*" & tType & " *"
   end if
   if hList = empty then
      put "no such handler:" && pType && pHandlerName into tError
      replace "  " with space in tError
      return tError
   end if
   repeat for each line h in hList
      put line (word 3 of h) to (word 4 of h) of tScript & cr & cr after outScript
   end repeat
   delete char -2 to -1 of outScript
   return outScript
end getHandlerFromScript

function caseSwitch
   -- does a quick inline switch/case
   -- param 1 is checkValue
   -- params 2+ are in the form matchValue(s)>=<returnValue
   --    separate multiple matcheValues with commas
   --    and enclose each matchValue=returnValue pair in quotes
   -- if checkValue matches one or more items in matchValue(s),
   --    returns returnValue
   -- note that checkValue should NOT be enclosed in quotes
   -- use a matchValue of "*" to specify a default value,
   --    to be returned if no matches found in the list
   --    if the default is "*=*" then no match returns the original <checkValue>
   --    if no match and no default value specified, then returns empty
   -- usage:
   --    put caseSwitch(len(tZip),"5=zip","10=zip+4","*=not a zip code") \
      --             into zipCodeType
   -- from Ken Ray, use-LC list, originally named stsSwitch()

   put param(1) into tCheckValue
   set the itemDel to "="
   put "" into tDefault
   repeat with x = 2 to the paramCount
      put param(x) into tCheck
      put item 1 of tCheck into tMatch
      put item 2 of tCheck into tRetVal
      replace "," with "=" in tMatch
      if tCheckValue is among the items of tMatch then return tRetVal
      if tMatch = "*" then
         if tRetVal = "*" then
            put tCheckValue into tDefault
         else
            put tRetVal into tDefault
         end if
      end if
   end repeat
   return tDefault
end caseSwitch

---------

On Feb 28, 2015, at 10:14 AM, Richard Gaskin wrote:

> Peter M. Brigham wrote:
> 
> > On Feb 27, 2015, at 10:20 PM, Richard Gaskin wrote:
> >
> >> Peter M. Brigham wrote:
> >> > The output I get from revAvailableHandlers looks like this:
> >> >
> >> > M mouseleave 14 17 button id 1026 of group id 1021 of card id 1082
> >> > of stack "NCMHC notes" of stack "/Users/pmbrig/Documents/LiveCode/
> >> > NCMHC notes/  NCMHC notes.rev"
> >> > M mousemove 1 12
> >> > M mouseup 19 131
> >> > F countVisits 133 165
> >> >
> >> > It looks as if the first line is the first handler && the long id
> >> > of the target, followed by the other handlers, M for command and
> >> > F for function, with the starting and ending line numbers. Very
> >> > useful, but an odd format. This is on LC 5.5.1. Can others confirm
> >> > that the output is similar with later versions of LC?
> >>
> >> The cool thing about this format is that it distinguishes handler
> >> type.  In a simple list of handler names you may not know that one
> >> of them is a getProp, the other a function, and which ones are
> >> private.  With this format you get that and more.
> >>
> >> The line numbers let you extract handlers instantly if needed, for
> >> example to quickly compare chunks from one version of a script and
> >> another.
> >>
> >> Uncommon indeed, but also uncommonly useful.
> >
> > Yes, it's a terrifically useful format overall. My question was about
> > that curious first line, however -- whether I can safely delete word
> > 5 to -1 of line 1 (I mistakenly said 'word 4 to -1' in my original
> > post) and get a pure list of handlers with their types and
> > lineoffsets. I don't know why the LC team didn't put the long id of
> > the object in line 1 and start the handler list at line 2, and I
> > wanted to make sure that this oddity persists in later versions of
> > the engine.
> 
> Your understanding of the format is consistent with mine, and I use it daily in my message path access tools.
> 
> As for why it's this way, beats me but to hopefully get an explanation I've taken the liberty of CC'ing Ben here so he can check with the implementer.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode