Re: Printed dictionary (was Re: send mouseup to control)

[Mark Wieder via use-livecode]

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)

[Richard Gaskin via use-livecode]

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)

[James Hale via use-livecode]

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

[Richard Gaskin via use-livecode]

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

[Mark Wieder via use-livecode]

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

[Mark Wieder via use-livecode]

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

[Richard Gaskin via use-livecode]

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

[Jonathan Lynch via use-livecode]

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

[hh via use-livecode]

> 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

[Richmond Mathewson via use-livecode]

Replied with demo stack on the Forums: 
http://forums.livecode.com/viewtopic.php?f=9=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

[Dr. Hawkins via use-livecode]

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

[Phil Davis via use-livecode]

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

[Mark Wieder via use-livecode]

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

[Alejandro Tejada via use-livecode]

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