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
>>
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
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
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
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
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?:
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 =
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
> 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
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
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
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
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
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
14 matches
Mail list logo