send mouseup to control
ambassador at fourthworld.com
Wed May 24 15:49:01 EDT 2017
Mark Wieder wrote:
> On 05/24/2017 11:50 AM, Richard Gaskin via use-livecode wrote:
>> 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.
True, it relies on data returned from the engine, and that the scripter
using the function understands how to use it.
But those seem modest requirements. I can't think of much in any
language or library not exposed to those two potential weaknesses. :)
The executionContexts is documented, though in all fairness that Dict
entry includes a note about not relying on the format of its contents.
But a LOT of code in the LC universe currently depends on it, and the
role it serves is essential for critical things like debugging. And it
hasn't changed in more than 15 years.
Given all that, for myself I find the trade-offs acceptable. If the
format changes down the road I certainly won't be the only person
changing scripts to keep current.
> 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.
I would be much more hesitant to rely on a function designed for IDE use
like revAvailableHandlers, but even there we don't really have an
alternative other than hand-crafing a slower replacement, so I use that
one too (though in only one place in my dev tools).
As for the refactoring, so much depends on the particulars of the
Your outline above might be ideal if handling a specific number of
But if the handler being called needs to know the caller ID for some
purpose other than simple branching among a small number of options,
factoring could range from tedious to impractical.
Like so much in code, it all depends on "Why" we need a given piece of
> Heh. Couldn't resist adding this:
Fun read, and very relevant: many of the items in that list appear to
contradict others. I don't see that as a bad thing. Coding is a mix of
knowing so-called "best practices", and knowing when to skip 'em. :) As
such, that list is an uncommonly realistic one.
Everything in a finite and imperfect universe involves trade-offs....
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the Use-livecode