send mouseup to control

Mark Wieder ahsoftware at
Wed May 24 15:14:03 EDT 2017

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
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
  ahsoftware at

More information about the use-livecode mailing list