On 05/24/2017 11:50 AM, Richard Gaskin via use-livecode wrote:
Mark Wieder wrote:
> You could pull the information out of the executionContexts, but you'd
> probably be better off with a bit of refactoring.
I'd go with executionContexts. Are there circumstances where this
wouldn't work?:
function CallerID
-- Line -1 = this function
-- Line -2 = the script that called this function
-- so:
return item 1 of line -3 of the executionContexts
end CallerID
That would work, but (to use the proper terminology) it has a code
smell. It's first of all dependent on the executionContexts format if
you're going to pick out the control ID, and while that format isn't
likely to change even though undocumented, it seems like yet another
level of dependency. There's already a dependence on having to know and
IDs of the calling objects, so the mouseUp handler is dependent on the
controls that might possibly call it. Any design change in the app might
require modifying the mouseUp code.
Refactoring to remove the dependencies could look like:
on mouseUp
-- what actually happens with a real mouse click
doRealMouseStuff
end mouseUp
on handler1
-- make a jazz noise here
end handler1
on handler2
-- this space intentionally left blank
end handler2
-- in some other control...
-- dispatch "mouseUp" to controlWithHandlers -- deprecated
dispatch "handler1" to controlWithHandlers
Now the object with the handlers doesn't have to know a thing about any
other controls that might call its handlers, and the external controls
only need know that there is a "handler1" handler in that object. A
judicious use of revAvailableHandlers() (again undocumented) could also
be useful here.
--
Mark Wieder
ahsoftw...@gmail.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
