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 pmb...@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 > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
