Re: Printed dictionary (was Re: send mouseup to control)
On 05/25/2017 07:47 AM, Richard Gaskin via use-livecode wrote: James Hale wrote: > In following them discussion on execution contexts Richard wrote: >> The executionContexts is documented, though in all fairness that >> Dict entry includes a note about not relying on the format of its >> contents. > > ...this morning the printed dictionary arrived! 🎉 > > So I looked up executionContexts > > Where I read... > '' A common use of the executionContexts is to obtain the name of the > object and handler that called the current handler, this information > is available as line -2 of the executionContexts." > > BTW there was no mention of any caveats in using this property. In v6.7 and later (possibly earlier too; I didn't check any version prior to v6.7), the Dictionary entry for the executionContexts includes this note: Important: The value of the executionContexts may be changed in future versions of LiveCode, it is not recommended to write code that depends on its contents. The web version of the Dictionary, though reportedly a few versions behind more recent versions (to the confusion of a few forum readers), also includes that note: https://livecode.com/resources/api/#livecode_script/executioncontexts Interesting. I stand corrected - the executionContexts is documented after all. It *is* a bit out of date, though, as it doesn't reflect the additional parameter(s) for behavior objects. The additional parameter was added in a way that cleverly maintains backward compatibility, although if you need to trace your way through behaviors you need to take it into account. -- 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
Re: Printed dictionary (was Re: send mouseup to control)
James Hale wrote: > In following them discussion on execution contexts Richard wrote: >> The executionContexts is documented, though in all fairness that >> Dict entry includes a note about not relying on the format of its >> contents. > > ...this morning the printed dictionary arrived! 🎉 > > So I looked up executionContexts > > Where I read... > '' A common use of the executionContexts is to obtain the name of the > object and handler that called the current handler, this information > is available as line -2 of the executionContexts." > > BTW there was no mention of any caveats in using this property. In v6.7 and later (possibly earlier too; I didn't check any version prior to v6.7), the Dictionary entry for the executionContexts includes this note: Important: The value of the executionContexts may be changed in future versions of LiveCode, it is not recommended to write code that depends on its contents. The web version of the Dictionary, though reportedly a few versions behind more recent versions (to the confusion of a few forum readers), also includes that note: https://livecode.com/resources/api/#livecode_script/executioncontexts What version was used for the printed Dictionary? All that said, I still feel comfortable using the executionContexts, though sparingly and usually with an easily-searchable flag comment* in case I need to update it later. After all, consider the fate of every Cocoa API call, or what happened to Python users moving from v2 to v3, or so many other things in the programming world. Stuff changes. If this changes too it won't be all that different from anything else we need to contend with. :) LiveCode has a far-better-than-average record for maintaining backward compatibility, and for responsibly managing change. In the rare case when a token is deprecated or its behavior is changed, it's usually called out in bold read type in the Release Notes. So if that ever happens, I'll know about it early on during the DP builds, and can find the few places I use executionContexts easily enough. Where factoring into separate handlers is the best fit for the problem, it's the best fit for the problem; a different solution like executionContexts wouldn't be the best choice in such cases anyway. But if I avoid a working solution solely out of fear of possible future change in an API, in a world where the only constant is change I'd never write any code. :) * FWIW I often flag code with three tags for easy searching, using a pattern Ken Ray and I call "Hmmm, Bang! What?": "Hmmm": --# Something worth drawing attention to for future versions, perhaps for later optimization, or just an unusual construct possibly worth reconsidering down the road. "Bang!": --! Something that MUST be addressed before release! Used for very unusual blocks that should be reviewed for revision before shipping. In the heat of the moment we may need to patch something together in one place in order to finish work in another part of the system; this flag allows finding those so we don't ship with those in place. "What?": --? Something that should be addressed as soon as time or opportunity permits, but not show-stoppers (which would use "--!" as above). Sometimes this may be a workaround for a bug in the engine, and if so I'll usually include the bug number so I can refer to it later. Or it may be a kludgey solution that works well enough for now but may be brittle or have potentially complicating implications elsewhere down the road. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://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
Printed dictionary (was Re: send mouseup to control)
In following them discussion on execution contexts Richard wrote: > The executionContexts is documented, though in all fairness that Dict > entry includes a note about not relying on the format of its contents. Normally I would moan to myself about how I would like to look that up but as I am reading this email (and nearly all others) on my iPad I cannot use the online dictionary as it can't handle a touch interface (the mothership is aware that they do have a non mobile friendly resource for a mobile capable product). But this morning the printed dictionary arrived! 🎉 So I looked up executionContexts Where I read... '' A common use of the executionContexts is to obtain the name of the object and handler that called the current handler, this information is available as line -2 of the executionContexts." BTW there was no mention of any caveats in using this property. James ___ 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
Re: send mouseup to control
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 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. 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 use-case. Your outline above might be ideal if handling a specific number of objects/options. 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 information. > Heh. Couldn't resist adding this: > https://techbeacon.com/35-bad-programming-habits-make-your-code-smell 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 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://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
Re: send mouseup to control
Heh. Couldn't resist adding this: https://techbeacon.com/35-bad-programming-habits-make-your-code-smell -- 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
Re: send mouseup to control
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
Re: send mouseup to control
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 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://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
Re: send mouseup to control
I just send the ID of the sending object as a parameter. Sent from my iPhone On May 24, 2017, at 1:58 PM, hh via use-livecode wrote: >> Alejandro T. wrote: >> Reading LiveCode Dictionary about the target and send, >> could not find an obvious way to get the name of a message >> sender without putting first this name in another container >> (a custom property, a field or a global variable). > > Yet another option could be to use more parameters: > -- b is the button number (obligatory) > -- [b may be also misused for any positive integer] > -- clicking the control with that handler leaves x empty > on mouseUp b,x > switch x >case ... > break >case ... > ... >default -- x is empty > -- the direct-click code, use b > end switch > end mouseUp > > > ___ > 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
Re: send mouseup to control
> Alejandro T. wrote: > Reading LiveCode Dictionary about the target and send, > could not find an obvious way to get the name of a message > sender without putting first this name in another container > (a custom property, a field or a global variable). Yet another option could be to use more parameters: -- b is the button number (obligatory) -- [b may be also misused for any positive integer] -- clicking the control with that handler leaves x empty on mouseUp b,x switch x case ... break case ... ... default -- x is empty -- the direct-click code, use b end switch end mouseUp ___ 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
Re: send mouseup to control
Replied with demo stack on the Forums: http://forums.livecode.com/viewtopic.php?f=9&t=29290 Richmond. On 5/24/17 8:21 pm, Alejandro Tejada via use-livecode wrote: Hi All, Reading LiveCode Dictionary about the target and send, could not find an obvious way to get the name of a message sender without putting first this name in another container (a custom property, a field or a global variable). Why do I need to know which control send a message to another control? Because the handler in the control executes different code depending of which control sends it a mouseup handler. For now, I am using a mouseup button parameter that could be 1 or 2 or 3. If the control receive a mouseup with parameter 1, then executes handler 1. If the mouseup is received with a parameter 2 then control executes handler 2. Which other ways could I use to produce the same result? Al ___ 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
Re: send mouseup to control
On Wed, May 24, 2017 at 10:21 AM, Alejandro Tejada via use-livecode < use-livecode@lists.runrev.com> wrote: > For now, I am using a mouseup button parameter that > could be 1 or 2 or 3. If the control receive a mouseup with > parameter 1, then executes handler 1. If the mouseup is > received with a parameter 2 then control executes > handler 2. > 1) take a look at the values of "me" and "the target" once the handler begins 2) I have plenty of buttons with the script, "dispatch the short name of me" 3) similar would be send doIt && the short name of me to someObject -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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
Re: send mouseup to control
Hi Al, I wonder if the "call" command could simplify things for you. (Probably not but I thought I would mention it.) Otherwise maybe put your mouseUp code in separate handlers outside of "mouseUp" so you can have more parameter options in their execution. Thanks - Phil Davis On 5/24/17 10:21 AM, Alejandro Tejada via use-livecode wrote: Hi All, Reading LiveCode Dictionary about the target and send, could not find an obvious way to get the name of a message sender without putting first this name in another container (a custom property, a field or a global variable). Why do I need to know which control send a message to another control? Because the handler in the control executes different code depending of which control sends it a mouseup handler. For now, I am using a mouseup button parameter that could be 1 or 2 or 3. If the control receive a mouseup with parameter 1, then executes handler 1. If the mouseup is received with a parameter 2 then control executes handler 2. Which other ways could I use to produce the same result? Al ___ 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 -- Phil Davis ___ 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
Re: send mouseup to control
On 05/24/2017 10:21 AM, Alejandro Tejada via use-livecode wrote: Hi All, Reading LiveCode Dictionary about the target and send, could not find an obvious way to get the name of a message sender without putting first this name in another container (a custom property, a field or a global variable). Why do I need to know which control send a message to another control? Because the handler in the control executes different code depending of which control sends it a mouseup handler. For now, I am using a mouseup button parameter that could be 1 or 2 or 3. If the control receive a mouseup with parameter 1, then executes handler 1. If the mouseup is received with a parameter 2 then control executes handler 2. Which other ways could I use to produce the same result? You could pull the information out of the executionContexts, but you'd probably be better off with a bit of refactoring. Instead of sending a mouseUp message, I'd send the handler 1 or handler 2 message directly. -- 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
send mouseup to control
Hi All, Reading LiveCode Dictionary about the target and send, could not find an obvious way to get the name of a message sender without putting first this name in another container (a custom property, a field or a global variable). Why do I need to know which control send a message to another control? Because the handler in the control executes different code depending of which control sends it a mouseup handler. For now, I am using a mouseup button parameter that could be 1 or 2 or 3. If the control receive a mouseup with parameter 1, then executes handler 1. If the mouseup is received with a parameter 2 then control executes handler 2. Which other ways could I use to produce the same result? Al ___ 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