Back at it here with attempst to make "generic" behaviors as text only stacks
that can serve as slaves "all over the place"
So this is all about the calling context/target.
I wonder If I am working too hard here, may be useful to have the calling
context ready for a dispatch, to parse the long owner?
So this little array that could be stored as a local and then used later in
the script to "do something different" based on the calling context.
local sOwnerHierarchy
on mouseup
put the short name of the target into pTarget
put the long owner of the target into sOwnerHierarchy
split sOwnerHierarchy with " of "
------ ## test ## --------
put the number of lines of the keys of tOwner into tLevels
repeat with x = 1 to tLevels
put tOwner[x] & cr after tHierarchy
end repeat
put tHierarchy
------ ## end test ## --------
switch pTarget
case "search"
if fld "searchString" is empty then
answer "Please enter a search string" with "OK"
exit to top
else
runsearch pClass, pContent
end if
break
end switch
end mouseup
command runSearch pClass, pContent
# do different things based on calling context.
-------------
I'm not sure I follow the underlying reasoning here - why not just use
'the long id of the target'?*
The message path means that the message will hit the group/card/stack if
not handled in the control (which it won't be, from what you are
saying).
_______________________________________________
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
