Re: Dispatch

[Richard Gaskin via use-livecode]

Sean Cole write:

> I was particularly asking if there was any 'advantage/disadvantage'
> in using
>
>  dispatch myHandler with myVar
>
> over just using
>
>  myHandler


In coding as in life, when in doubt leave it out.

If something isn't needed it's usually simplest to not go out of your 
way to add it.


The message path is fine.

It works reliably, and with as much efficiency as the team can throw at 
it. In most cases it's not only the easiest thing to type and the most 
efficient to execute, its simplicity and predictability also aid 
debugging and maintenance.


For those times when you need an exception to the message path, LC 
provides many.  Send, do, call, dispatch, etc. - each has their own 
unique set of tradeoffs that make it a good fit for the specific 
circumstance where the native message path isn't what you need.


But those are for exceptional circumstances.

The native message path is the norm of this language.

--
 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: Dispatch

[Mark Wieder via use-livecode]

On 8/3/22 09:14, Bob Sneidar wrote:

One correction. If a value is returned by the handler that was called, the 
result will be that value.


Yeah - good catch. I meant to say the "it" value is three-state, not the 
"result".


dispatch someMessage
if it is not "unhandled" then...
or
if it is "passed" then...
or
if it is "handled" then...

and note that you can dispatch functions as well a commands, and the 
return value of the function will be in the result if "it" is not 
"unhandled".



--
 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: Dispatch

[Bob Sneidar via use-livecode]

One correction. If a value is returned by the handler that was called, the 
result will be that value. 

Bob S


> On Aug 3, 2022, at 08:53 , Mark Wieder via use-livecode 
>  wrote:
> 
> One, if I'm calling a handler in a different object that is outside the 
> normal message path then I'll dispatch the handler to that object rather than 
> using send. One caveat: note that the dispatch command returns a three-state 
> value: "handled", "unhandled", and "passed". So on checking the return value 
> I use "if it it not unhandled then...". The advantage is that there's no 
> runtime error if the command isn't caught, at the slight disadvantage of 
> having to check whether it was handled.


___
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: Dispatch

[Mark Wieder via use-livecode]

On 8/3/22 06:36, Sean Cole via use-livecode wrote:

Hi all,
I've been thinking about the command 'dispatch'. Is there any
advantage/disadvantage in using it over just calling your handler?


If you can invoke a command/function directly then for the most part 
there's no real advantage in using dispatch.


I never use send anymore unless I need send a message in time.
I do use dispatch extensively, mostly for two reasons.

One, if I'm calling a handler in a different object that is outside the 
normal message path then I'll dispatch the handler to that object rather 
than using send. One caveat: note that the dispatch command returns a 
three-state value: "handled", "unhandled", and "passed". So on checking 
the return value I use "if it it not unhandled then...". The advantage 
is that there's no runtime error if the command isn't caught, at the 
slight disadvantage of having to check whether it was handled.


The second case where I use dispatch is as a form of publish/subscribe: 
dispatching a command without a receiver object sends the command along 
the message path where it can be handled/passed by any object along the 
way. Or not. Mostly in this paradigm I don't need or want to check the 
return value because it's irrelevant to the sender whether or not the 
message was handled.


The dispatch command can also be useful for feature management. Dispatch 
a command down the message path, and if the given feature is enabled 
then the command will be handled. If not then there's no downside to 
calling the feature because it won't cause a runtime error.



--
 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: Dispatch

[Sean Cole via use-livecode]

Awesome Bob,
Thanks for the info. That is really helpful. I often use 'try' to catch
incidents where things trip over, but this might just be more useful and
perform slightly better going forward.

Are there any other tips for its use?

Sean


On Wed, 3 Aug 2022 at 16:23, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Send allows you to send in time. However the command or function must
> exist or you will throw an error. Dispatch cannot use send in time, but if
> a handler does not exist in the message path of the object you dispatch to,
> no error will be thrown.
>
> This can come in handy. Let's say you have assigned a behavior in all your
> fields, but in a few of your fields you have a special handler called
> Cleanup. You can then, 'dispatch "cleanup" to me' in any handler in the
> behavior. The fields that have the cleanup handler will get the message.
> The ones that don't will not throw an error.
>
> Bob S
>
>
> > On Aug 3, 2022, at 07:30 , Craig Newman via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> >> On Aug 3, 2022, at 9:36 AM, Sean Cole via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> Hi all,
> >> I've been thinking about the command 'dispatch'. Is there any
> >> advantage/disadvantage in using it over just calling your handler?
> >> Thanks
> >> Sean
>
>
> ___
> 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: Dispatch

[Bob Sneidar via use-livecode]

That should read, "Dispatch cannot use 'in time'"

> On Aug 3, 2022, at 08:23 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Dispatch cannot use send in time


___
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: Dispatch

[Sean Cole via use-livecode]

Thanks Craig,
I was particularly asking if there was any 'advantage/disadvantage' in using

dispatch myHandler with myVar

over just using

myHandler

The dictionary defines its advantages for use with behaviours and that it
returns in the 'it' variable if the message was handled or not - useful
even when not used with behaviours in some cases I could imagine.

However, I wondered if anyone else had already done the experimentation as
to the dis/advantages of the above. Just making use of the community :)
Sean

On Wed, 3 Aug 2022 at 15:30, Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi.
>
> “Send” and “Dispatch” do much the same thing, but they do differ in how
> they interact with the message patch. They also each include their own
> personal gadgetry that comes in handy in different scenarios. Read about
> both in the dictionary, and do some experimentation with both.
>
> Craig
>
> > On Aug 3, 2022, at 9:36 AM, Sean Cole via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hi all,
> > I've been thinking about the command 'dispatch'. Is there any
> > advantage/disadvantage in using it over just calling your handler?
> > Thanks
> > Sean
> > ___
> > 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
>
___
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: Dispatch

[Bob Sneidar via use-livecode]

Send allows you to send in time. However the command or function must exist or 
you will throw an error. Dispatch cannot use send in time, but if a handler 
does not exist in the message path of the object you dispatch to, no error will 
be thrown. 

This can come in handy. Let's say you have assigned a behavior in all your 
fields, but in a few of your fields you have a special handler called Cleanup. 
You can then, 'dispatch "cleanup" to me' in any handler in the behavior. The 
fields that have the cleanup handler will get the message. The ones that don't 
will not throw an error. 

Bob S


> On Aug 3, 2022, at 07:30 , Craig Newman via use-livecode 
>  wrote:
> 
>> On Aug 3, 2022, at 9:36 AM, Sean Cole via use-livecode 
>>  wrote:
>> 
>> Hi all,
>> I've been thinking about the command 'dispatch'. Is there any
>> advantage/disadvantage in using it over just calling your handler?
>> Thanks
>> Sean


___
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: Dispatch

[Craig Newman via use-livecode]

Hi.

“Send” and “Dispatch” do much the same thing, but they do differ in how they 
interact with the message patch. They also each include their own personal 
gadgetry that comes in handy in different scenarios. Read about both in the 
dictionary, and do some experimentation with both.

Craig

> On Aug 3, 2022, at 9:36 AM, Sean Cole via use-livecode 
>  wrote:
> 
> Hi all,
> I've been thinking about the command 'dispatch'. Is there any
> advantage/disadvantage in using it over just calling your handler?
> Thanks
> Sean
> ___
> 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: Dispatch msg from one top level stack to one behind it without raising the latter

[Sannyasin Brahmanathaswami]

>>If you dispatch a “go next card” to a stack that is not the top stack.. .it 
>>immediately comes to the foreground if the calling stack is not a palette.
>>
>>Is there a way to prevent this?

jac...@hyperactivesw.com> wrote:

>
>You can set the currentCard of the non-topstack. I think that should do it.
>
TKS

Yes, that does it

BR: FYI Dictionary fix:

“currentCard” is not in the dictionary.  “Current Card” is… 

But 

Set the current Card of stack  “categoryPicker" to 2

Fails

While 

Set the currentcard of stack  “categoryPicker" to 2 

Does work.




>
___
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: Dispatch msg from one top level stack to one behind it without raising the latter

[J. Landman Gay]

On 4/24/2016 5:58 PM, Sannyasin Brahmanathaswami wrote:

If you dispatch a “go next card” to a stack that is not the top stack.. .it 
immediately comes to the foreground if the calling stack is not a palette.

Is there a way to prevent this?


You can set the currentCard of the non-topstack. I think that should do it.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Dispatch msg from one top level stack to one behind it without raising the latter

[Peter Bogdanoff]

Even when you lock the screen and go back to the first stack, the focus remains 
on the stack underneath.

Apparently LC won’t do any visual changes to a stack which is not the topStack. 
Possibly there are human interface guidelines in play here.

Peter





On Apr 24, 2016, at 4:03 PM, Mike Kerner  wrote:

> as a workaround, can you lock the screen, do the move, and then send it
> back?
> 
> On Sun, Apr 24, 2016 at 6:58 PM, Sannyasin Brahmanathaswami <
> bra...@hindu.org> wrote:
> 
>> If you dispatch a “go next card” to a stack that is not the top stack..
>> .it immediately comes to the foreground if the calling stack is not a
>> palette.
>> 
>> Is there a way to prevent this?
>> 
>> BR
>> ___
>> 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
> 
> 
> 
> 
> -- 
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> ___
> 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: Dispatch msg from one top level stack to one behind it without raising the latter

[Mark Wieder]

On 04/24/2016 03:58 PM, Sannyasin Brahmanathaswami wrote:

If you dispatch a “go next card” to a stack that is not the top stack.. .it 
immediately comes to the foreground if the calling stack is not a palette.

Is there a way to prevent this?


Off the top of my head, that doesn't sound like a good idea.
What problem are you trying to solve?

--
 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: Dispatch msg from one top level stack to one behind it without raising the latter

[Mike Kerner]

as a workaround, can you lock the screen, do the move, and then send it
back?

On Sun, Apr 24, 2016 at 6:58 PM, Sannyasin Brahmanathaswami <
bra...@hindu.org> wrote:

> If you dispatch a “go next card” to a stack that is not the top stack..
> .it immediately comes to the foreground if the calling stack is not a
> palette.
>
> Is there a way to prevent this?
>
> BR
> ___
> 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




-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: dispatch usage versus send

[Mark Wieder]

Thomas McGrath III mcgrath3@... writes:

 I am using this code now:
 
 on openstack
 loadCustomPropsFromFile
 dispatch loadAllUsers to card Users of this stack
  if it is handled then
   dispatch loadCurrentUser to card Users of this stack
   if it is handled then
dispatch loadCurrentUserForm to card Users of this stack
   end if
  end if
 end openstack

 My question is Is the right usage of dispatch?

Not in terms of what you're trying to accomplish. The handled result says
that there was a handler somewhere in the message path that caught the
message and processed it. It's not an indication that the loadxxx command
was successful. To do that you'd need to return a value in the result or set
a semaphore somewhere or some similar action.

You'd be in the same situation if you used send. Lately I've taken to
using send only when I need to send a message in time, and I'm using
dispatch for all other situations. There are some subtle differences in
context, but otherwise you can treat them the same. And dispatch function
is a lot easier to read, remember, and maintain than the value(... syntax.

-- 
 Mark Wieder
 mwie...@ahsoftware.net




___
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: Dispatch vs Libraries

[Mark Wieder]

Todd-

Sunday, November 27, 2011, 6:42:04 AM, you wrote:

dispatch SaveData to Services[MyContact] with DataArray

!!! You can dispatch a message to an array element? !!!
I had no idea...

-- 
-Mark Wieder
 mwie...@ahsoftware.net


___
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: Dispatch vs Libraries

[J. Landman Gay]

On 11/27/11 12:41 PM, Pete wrote:


Something looks a little strange about the first dispatch statement -
you're sending a message to an array?


I think the array element resolves to a long button ID, so really it 
isn't any different than dispatching to a literal ID stored in any variable.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Dispatch vs Libraries

[Pete]

Ah yes, hadn't thought of that!  ANother new piece of knowledge to store
away.

On Sun, Nov 27, 2011 at 10:53 AM, J. Landman Gay
jac...@hyperactivesw.comwrote:

 On 11/27/11 12:41 PM, Pete wrote:

  Something looks a little strange about the first dispatch statement -
 you're sending a message to an array?


 I think the array element resolves to a long button ID, so really it isn't
 any different than dispatching to a literal ID stored in any variable.

 --
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.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-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode




-- 
Pete
Molly's Revenge http://www.mollysrevenge.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: Dispatch vs Libraries

[Mark Wieder]

Jacque-

Sunday, November 27, 2011, 10:53:38 AM, you wrote:

 I think the array element resolves to a long button ID, so really it
 isn't any different than dispatching to a literal ID stored in any variable.

No, that's huge! The fact that the array element gets resolved to an
object ID before the dispatch message gets executed paves the way for
multiple inheritance, for one thing.

-- 
-Mark Wieder
 mwie...@ahsoftware.net


___
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: Dispatch vs Libraries

[Todd Geist]

Hi Mark,

How does that pave the way for Multiple inheritance?  I was thinking as
Jacque thought that this was the same as using any variable.


On Sun, Nov 27, 2011 at 11:26 AM, Mark Wieder mwie...@ahsoftware.netwrote:


  I think the array element resolves to a long button ID, so really it
  isn't any different than dispatching to a literal ID stored in any
 variable.

 No, that's huge! The fact that the array element gets resolved to an
 object ID before the dispatch message gets executed paves the way for
 multiple inheritance, for one thing.


Todd

-- 
Todd Geist
geist interactive
(805) 419-9382
___
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: Dispatch vs Libraries

[Todd Geist]

On Sun, Nov 27, 2011 at 10:41 AM, Pete p...@mollysrevenge.com wrote:

Something looks a little strange about the first dispatch statement -
 you're sending a message to an array? I thought messages went to
 stacks/cards/controls.  I think you'd also need to use the dispatch
 function syntax to get a result back.


Hi Pete,

It works. You don't need to use the function syntax unless of course it is
a call to a Function that you are dispatching. In the case I cited I am
using a command but the command uses Return to return the result.

When you do it that way,  you get the returned value in the result.  And
it contains handled, unhandled, or passed

And the arrayElement just contains the long id of the control that I am
sending the message to. I set it like this

put the long id of button Contacts into Services[Contacts]


Since Services is Global I can now dispatch a message to that Control from
anywhere like so

dispatch Message to Services[Contact] with param1, param2, param3


This seem very readable to me.


Todd


-- 
Todd Geist
geist interactive
(805) 419-9382
___
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: Dispatch vs Libraries

[Pete]

Hi Todd,
All interesting stuff.  I knew about the it and return values for dispatch
but thought the result only worked with functions, but makes sense that
what you're doing would work too.

On Sun, Nov 27, 2011 at 12:27 PM, Todd Geist t...@geistinteractive.comwrote:

 On Sun, Nov 27, 2011 at 10:41 AM, Pete p...@mollysrevenge.com wrote:

 Something looks a little strange about the first dispatch statement -
  you're sending a message to an array? I thought messages went to
  stacks/cards/controls.  I think you'd also need to use the dispatch
  function syntax to get a result back.


 Hi Pete,

 It works. You don't need to use the function syntax unless of course it is
 a call to a Function that you are dispatching. In the case I cited I am
 using a command but the command uses Return to return the result.

 When you do it that way,  you get the returned value in the result.  And
 it contains handled, unhandled, or passed

 And the arrayElement just contains the long id of the control that I am
 sending the message to. I set it like this

 put the long id of button Contacts into Services[Contacts]


 Since Services is Global I can now dispatch a message to that Control from
 anywhere like so

 dispatch Message to Services[Contact] with param1, param2, param3


 This seem very readable to me.


 Todd


 --
 Todd Geist
 geist interactive
 (805) 419-9382
 ___
 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




-- 
Pete
Molly's Revenge http://www.mollysrevenge.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: Dispatch vs Libraries

[Ken Ray]

On Nov 27, 2011, at 11:43 AM, Mark Wieder wrote:

 Todd-
 
 Sunday, November 27, 2011, 6:42:04 AM, you wrote:
 
   dispatch SaveData to Services[MyContact] with DataArray
 
 !!! You can dispatch a message to an array element? !!!
 I had no idea…

I guess if the array element contains an object descriptor that should work… 

Todd - your choice of using dispatch should actually be faster than using a 
library since dispatch sends directly to a specified object, whereas a library 
would only catch the message after it had gone through the object hierarchy.

Cool stuff, by the way!

Ken Ray
Sons of Thunder Software, Inc.
Email: k...@sonsothunder.com
Web Site: http://www.sonsothunder.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: Dispatch vs Libraries

[Mark Wieder]

Todd-

Sunday, November 27, 2011, 12:17:11 PM, you wrote:

 How does that pave the way for Multiple inheritance?  I was thinking as
 Jacque thought that this was the same as using any variable.

caveat
 I'm normally quite allergic to multiple inheritance, and so if I find
 myself in a situation where I need it I refactor things so that it's
 not necessary. That being the case, the following is probably a Bad
 Example, and should be a Gedankenexperiment only.
/caveat

Given an employee class and a manager class in a company, a manager is
responsible for employees who may themselves be managers. Let's say,
for the sake of the example (or as in LC) that you can't have
subclasses of subclasses - you can have behavior objects but you can't
have behavior parents of behavior objects. Otherwise you'd just have
the manager class as a subclass of the employee class:

ManagerClass -- EmployeeClass -- object instance

What you'd need instead is multiple inheritance, where the object
instance gets two behavior buttons, a ManagerClass button and an
EmployeeClass button:

ManagerClassEmployeeClass
  | |
  | |
  object instance

...so you'd have something like

dispatch tEmployeeID to Parent[GetReview]
put the result into tReviewText
dispatch tEmployeeID to Parent[GetTeamMembers]
put the result into tReviewText

where Parent[GetReview] would probably contain the long id of the
EmployeeClass button and Parent[GetTeamMembers] would contain the
long id of the ManagerClass button.

-- 
-Mark Wieder
 mwie...@ahsoftware.net


___
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: dispatch and the target

[Pete]

I'll check out the executionContexts.

The reason for the architecture is to make it as easy as possible for users
of the utility to start using its library, install its front scripts, get
its behavior scripts recognised and open it's internal files.  With this
architecture, the only statement they need to include in their application
initialisation script is this one dispatch command instead of a start using,
an insert front script, setting the correct stackFiles property, and opening
several files.  I'm quite open to other suggestions as to how else to do
this - so far this is the shortest way I can think of.

Pete
Molly's Revenge http://www.mollysrevenge.com




On Thu, Aug 11, 2011 at 10:43 PM, Mark Wieder mwie...@ahsoftware.netwrote:

 Pete-

 Thursday, August 11, 2011, 9:41:49 PM, you wrote:

  The dispatch methodology works fine but I'm finding that using the
 target
  or me in the external stack's handler resolves to the external library
  stack file not the stack that issued the dispatch command.  I can, of
  course, include the name of the dispatching stack as a parameter to the
  handler but I'm wondering if there is a way to track down the dispatching
  stack's name in these circumstances.

 In short, if you've gotten into this situation then it's time to
 rearchitect your application. You shouldn't have to ask this question.
 You're fighting the message path, and while what you want to do can be
 done, it ain't the right way to do things.

 That said, if you don't want to pass the calling stack as an argument
 you need to look at the executionContexts to get the call stack.

 --
 -Mark Wieder
  mwie...@ahsoftware.net


 ___
 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: dispatch and the target

[Pete]

Hi Mark,
I decided to try a more orthodox method of doing this.  The application now
includes a start using command for my library stack and the library stack
has a libraryStack message handler in it that does all the initialisation I
referred to.

However, the same problem still occurs, Referring to the target or me in
the libraryStack handler resolves to the library stack not the application
stack, which is consistant with how those keywords are defined in the
dictionary.  And because the libraryStack message does not allow for any
parameters, I cannot pass in the application stack's name.  I can use the
executionContexts to get the stack name of course but the dictionary claims
its format may change and it is not recommended to write code that depends
on its current format.

It appears there is no message path in these circumstances so I'm trying to
find a way to do what I need to do, absent the message path, not trying to
fight it.

Pete
Molly's Revenge http://www.mollysrevenge.com




On Thu, Aug 11, 2011 at 10:43 PM, Mark Wieder mwie...@ahsoftware.netwrote:

 Pete-

 Thursday, August 11, 2011, 9:41:49 PM, you wrote:

  The dispatch methodology works fine but I'm finding that using the
 target
  or me in the external stack's handler resolves to the external library
  stack file not the stack that issued the dispatch command.  I can, of
  course, include the name of the dispatching stack as a parameter to the
  handler but I'm wondering if there is a way to track down the dispatching
  stack's name in these circumstances.

 In short, if you've gotten into this situation then it's time to
 rearchitect your application. You shouldn't have to ask this question.
 You're fighting the message path, and while what you want to do can be
 done, it ain't the right way to do things.

 That said, if you don't want to pass the calling stack as an argument
 you need to look at the executionContexts to get the call stack.

 --
 -Mark Wieder
  mwie...@ahsoftware.net


 ___
 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: dispatch and the target

[Phil Davis]

Is there a reason you don't want to use a global variable as the communication 
channel between the app and the lib stack? That would work. Just declare it in 
both places, put data into it before start using, and in the libraryStack 
handler the data will be there. Bob's your uncle, as they say.


Phil Davis


On 8/12/11 9:27 AM, Pete wrote:

Hi Mark,
I decided to try a more orthodox method of doing this.  The application now
includes a start using command for my library stack and the library stack
has a libraryStack message handler in it that does all the initialisation I
referred to.

However, the same problem still occurs, Referring to the target or me in
the libraryStack handler resolves to the library stack not the application
stack, which is consistant with how those keywords are defined in the
dictionary.  And because the libraryStack message does not allow for any
parameters, I cannot pass in the application stack's name.  I can use the
executionContexts to get the stack name of course but the dictionary claims
its format may change and it is not recommended to write code that depends
on its current format.

It appears there is no message path in these circumstances so I'm trying to
find a way to do what I need to do, absent the message path, not trying to
fight it.

Pete
Molly's Revengehttp://www.mollysrevenge.com




On Thu, Aug 11, 2011 at 10:43 PM, Mark Wiedermwie...@ahsoftware.netwrote:


Pete-

Thursday, August 11, 2011, 9:41:49 PM, you wrote:


The dispatch methodology works fine but I'm finding that using the

target

or me in the external stack's handler resolves to the external library
stack file not the stack that issued the dispatch command.  I can, of
course, include the name of the dispatching stack as a parameter to the
handler but I'm wondering if there is a way to track down the dispatching
stack's name in these circumstances.

In short, if you've gotten into this situation then it's time to
rearchitect your application. You shouldn't have to ask this question.
You're fighting the message path, and while what you want to do can be
done, it ain't the right way to do things.

That said, if you don't want to pass the calling stack as an argument
you need to look at the executionContexts to get the call stack.

--
-Mark Wieder
  mwie...@ahsoftware.net


___
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



--
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net


___
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: dispatch and the target

[Bob Sneidar]

You can refer to the current stack using the topStack. A library should be 
capable of working no matter which stack has the focus. I would rewrite  the 
scripts in the library stack to be independent. Also, you should not have to 
dispatch to a library stack. Start Using puts the stack script in the 
backScript, and therefore in the message path. 

This means however, that all your scripts need to be in the stack script and 
not other objects. A library stack is not intended to be a functional entity in 
itself, but rather a repository of commands and functions to be used by other 
applications. 

If it contains functionality where the user can interact with it, then it 
should probably be treated as a plugin, so the user can launch it from the 
Development/Plugins menu. 

Sorry if I am saying things you already knew. 

Bob


On Aug 12, 2011, at 9:47 AM, Phil Davis wrote:

 Is there a reason you don't want to use a global variable as the 
 communication channel between the app and the lib stack? That would work. 
 Just declare it in both places, put data into it before start using, and in 
 the libraryStack handler the data will be there. Bob's your uncle, as they 
 say.
 
 Phil Davis
 
 
 On 8/12/11 9:27 AM, Pete wrote:
 Hi Mark,
 I decided to try a more orthodox method of doing this.  The application now
 includes a start using command for my library stack and the library stack
 has a libraryStack message handler in it that does all the initialisation I
 referred to.
 
 However, the same problem still occurs, Referring to the target or me in
 the libraryStack handler resolves to the library stack not the application
 stack, which is consistant with how those keywords are defined in the
 dictionary.  And because the libraryStack message does not allow for any
 parameters, I cannot pass in the application stack's name.  I can use the
 executionContexts to get the stack name of course but the dictionary claims
 its format may change and it is not recommended to write code that depends
 on its current format.
 
 It appears there is no message path in these circumstances so I'm trying to
 find a way to do what I need to do, absent the message path, not trying to
 fight it.
 
 Pete
 Molly's Revengehttp://www.mollysrevenge.com
 
 
 
 
 On Thu, Aug 11, 2011 at 10:43 PM, Mark Wiedermwie...@ahsoftware.netwrote:
 
 Pete-
 
 Thursday, August 11, 2011, 9:41:49 PM, you wrote:
 
 The dispatch methodology works fine but I'm finding that using the
 target
 or me in the external stack's handler resolves to the external library
 stack file not the stack that issued the dispatch command.  I can, of
 course, include the name of the dispatching stack as a parameter to the
 handler but I'm wondering if there is a way to track down the dispatching
 stack's name in these circumstances.
 In short, if you've gotten into this situation then it's time to
 rearchitect your application. You shouldn't have to ask this question.
 You're fighting the message path, and while what you want to do can be
 done, it ain't the right way to do things.
 
 That said, if you don't want to pass the calling stack as an argument
 you need to look at the executionContexts to get the call stack.
 
 --
 -Mark Wieder
  mwie...@ahsoftware.net
 
 
 ___
 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
 
 
 -- 
 Phil Davis
 
 PDS Labs
 Professional Software Development
 http://pdslabs.net
 
 
 ___
 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: dispatch and the target

[Pete]

No reason other than I never thought of it!  Thanks for the simple solution.
 Also, I'd rather not talk about my Uncle Bob
Pete
Molly's Revenge http://www.mollysrevenge.com




On Fri, Aug 12, 2011 at 9:47 AM, Phil Davis rev...@pdslabs.net wrote:

 Is there a reason you don't want to use a global variable as the
 communication channel between the app and the lib stack? That would work.
 Just declare it in both places, put data into it before start using, and
 in the libraryStack handler the data will be there. Bob's your uncle, as
 they say.

 Phil Davis



 On 8/12/11 9:27 AM, Pete wrote:

 Hi Mark,
 I decided to try a more orthodox method of doing this.  The application
 now
 includes a start using command for my library stack and the library
 stack
 has a libraryStack message handler in it that does all the initialisation
 I
 referred to.

 However, the same problem still occurs, Referring to the target or me
 in
 the libraryStack handler resolves to the library stack not the application
 stack, which is consistant with how those keywords are defined in the
 dictionary.  And because the libraryStack message does not allow for any
 parameters, I cannot pass in the application stack's name.  I can use the
 executionContexts to get the stack name of course but the dictionary
 claims
 its format may change and it is not recommended to write code that depends
 on its current format.

 It appears there is no message path in these circumstances so I'm trying
 to
 find a way to do what I need to do, absent the message path, not trying to
 fight it.

 Pete
 Molly's Revengehttp://www.**mollysrevenge.comhttp://www.mollysrevenge.com
 





 On Thu, Aug 11, 2011 at 10:43 PM, Mark Wiedermwie...@ahsoftware.net**
 wrote:

  Pete-

 Thursday, August 11, 2011, 9:41:49 PM, you wrote:

  The dispatch methodology works fine but I'm finding that using the

 target

 or me in the external stack's handler resolves to the external library
 stack file not the stack that issued the dispatch command.  I can, of
 course, include the name of the dispatching stack as a parameter to the
 handler but I'm wondering if there is a way to track down the
 dispatching
 stack's name in these circumstances.

 In short, if you've gotten into this situation then it's time to
 rearchitect your application. You shouldn't have to ask this question.
 You're fighting the message path, and while what you want to do can be
 done, it ain't the right way to do things.

 That said, if you don't want to pass the calling stack as an argument
 you need to look at the executionContexts to get the call stack.

 --
 -Mark Wieder
  mwie...@ahsoftware.net


 __**_
 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-livecodehttp://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-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode


 --
 Phil Davis

 PDS Labs
 Professional Software Development
 http://pdslabs.net



 __**_
 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-livecodehttp://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: dispatch and the target

[Pete]

Thanks Bob.  I had forgotten about the topstack and it indeed seems to
provide the mechanism I'm looking for.  The utility I'm working on includes
a plugin, as you mentioned, and a runtime library as a separate entity
usable without the plugin.

By the way - are you the Uncle Bob that Phil mentioned?

Pete
Molly's Revenge http://www.mollysrevenge.com




On Fri, Aug 12, 2011 at 10:04 AM, Bob Sneidar b...@twft.com wrote:

 You can refer to the current stack using the topStack. A library should be
 capable of working no matter which stack has the focus. I would rewrite  the
 scripts in the library stack to be independent. Also, you should not have to
 dispatch to a library stack. Start Using puts the stack script in the
 backScript, and therefore in the message path.

 This means however, that all your scripts need to be in the stack script
 and not other objects. A library stack is not intended to be a functional
 entity in itself, but rather a repository of commands and functions to be
 used by other applications.

 If it contains functionality where the user can interact with it, then it
 should probably be treated as a plugin, so the user can launch it from the
 Development/Plugins menu.

 Sorry if I am saying things you already knew.

 Bob


 On Aug 12, 2011, at 9:47 AM, Phil Davis wrote:

  Is there a reason you don't want to use a global variable as the
 communication channel between the app and the lib stack? That would work.
 Just declare it in both places, put data into it before start using, and
 in the libraryStack handler the data will be there. Bob's your uncle, as
 they say.
 
  Phil Davis
 
 
  On 8/12/11 9:27 AM, Pete wrote:
  Hi Mark,
  I decided to try a more orthodox method of doing this.  The application
 now
  includes a start using command for my library stack and the library
 stack
  has a libraryStack message handler in it that does all the
 initialisation I
  referred to.
 
  However, the same problem still occurs, Referring to the target or
 me in
  the libraryStack handler resolves to the library stack not the
 application
  stack, which is consistant with how those keywords are defined in the
  dictionary.  And because the libraryStack message does not allow for any
  parameters, I cannot pass in the application stack's name.  I can use
 the
  executionContexts to get the stack name of course but the dictionary
 claims
  its format may change and it is not recommended to write code that
 depends
  on its current format.
 
  It appears there is no message path in these circumstances so I'm trying
 to
  find a way to do what I need to do, absent the message path, not trying
 to
  fight it.
 
  Pete
  Molly's Revengehttp://www.mollysrevenge.com
 
 
 
 
  On Thu, Aug 11, 2011 at 10:43 PM, Mark Wiedermwie...@ahsoftware.net
 wrote:
 
  Pete-
 
  Thursday, August 11, 2011, 9:41:49 PM, you wrote:
 
  The dispatch methodology works fine but I'm finding that using the
  target
  or me in the external stack's handler resolves to the external
 library
  stack file not the stack that issued the dispatch command.  I can, of
  course, include the name of the dispatching stack as a parameter to
 the
  handler but I'm wondering if there is a way to track down the
 dispatching
  stack's name in these circumstances.
  In short, if you've gotten into this situation then it's time to
  rearchitect your application. You shouldn't have to ask this question.
  You're fighting the message path, and while what you want to do can be
  done, it ain't the right way to do things.
 
  That said, if you don't want to pass the calling stack as an argument
  you need to look at the executionContexts to get the call stack.
 
  --
  -Mark Wieder
   mwie...@ahsoftware.net
 
 
  ___
  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
 
 
  --
  Phil Davis
 
  PDS Labs
  Professional Software Development
  http://pdslabs.net
 
 
  ___
  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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url 

Re: dispatch and the target

[Bob Sneidar]

I was hoping to avoid this conversation, but alas, I am indeed, your uncle. ;-)

Bob


On Aug 12, 2011, at 10:33 AM, Pete wrote:

 Thanks Bob.  I had forgotten about the topstack and it indeed seems to
 provide the mechanism I'm looking for.  The utility I'm working on includes
 a plugin, as you mentioned, and a runtime library as a separate entity
 usable without the plugin.
 
 By the way - are you the Uncle Bob that Phil mentioned?
 
 Pete
 Molly's Revenge http://www.mollysrevenge.com
 
 
 
 
 On Fri, Aug 12, 2011 at 10:04 AM, Bob Sneidar b...@twft.com wrote:
 
 You can refer to the current stack using the topStack. A library should be
 capable of working no matter which stack has the focus. I would rewrite  the
 scripts in the library stack to be independent. Also, you should not have to
 dispatch to a library stack. Start Using puts the stack script in the
 backScript, and therefore in the message path.
 
 This means however, that all your scripts need to be in the stack script
 and not other objects. A library stack is not intended to be a functional
 entity in itself, but rather a repository of commands and functions to be
 used by other applications.
 
 If it contains functionality where the user can interact with it, then it
 should probably be treated as a plugin, so the user can launch it from the
 Development/Plugins menu.
 
 Sorry if I am saying things you already knew.
 
 Bob
 
 
 On Aug 12, 2011, at 9:47 AM, Phil Davis wrote:
 
 Is there a reason you don't want to use a global variable as the
 communication channel between the app and the lib stack? That would work.
 Just declare it in both places, put data into it before start using, and
 in the libraryStack handler the data will be there. Bob's your uncle, as
 they say.
 
 Phil Davis
 
 
 On 8/12/11 9:27 AM, Pete wrote:
 Hi Mark,
 I decided to try a more orthodox method of doing this.  The application
 now
 includes a start using command for my library stack and the library
 stack
 has a libraryStack message handler in it that does all the
 initialisation I
 referred to.
 
 However, the same problem still occurs, Referring to the target or
 me in
 the libraryStack handler resolves to the library stack not the
 application
 stack, which is consistant with how those keywords are defined in the
 dictionary.  And because the libraryStack message does not allow for any
 parameters, I cannot pass in the application stack's name.  I can use
 the
 executionContexts to get the stack name of course but the dictionary
 claims
 its format may change and it is not recommended to write code that
 depends
 on its current format.
 
 It appears there is no message path in these circumstances so I'm trying
 to
 find a way to do what I need to do, absent the message path, not trying
 to
 fight it.
 
 Pete
 Molly's Revengehttp://www.mollysrevenge.com
 
 
 
 
 On Thu, Aug 11, 2011 at 10:43 PM, Mark Wiedermwie...@ahsoftware.net
 wrote:
 
 Pete-
 
 Thursday, August 11, 2011, 9:41:49 PM, you wrote:
 
 The dispatch methodology works fine but I'm finding that using the
 target
 or me in the external stack's handler resolves to the external
 library
 stack file not the stack that issued the dispatch command.  I can, of
 course, include the name of the dispatching stack as a parameter to
 the
 handler but I'm wondering if there is a way to track down the
 dispatching
 stack's name in these circumstances.
 In short, if you've gotten into this situation then it's time to
 rearchitect your application. You shouldn't have to ask this question.
 You're fighting the message path, and while what you want to do can be
 done, it ain't the right way to do things.
 
 That said, if you don't want to pass the calling stack as an argument
 you need to look at the executionContexts to get the call stack.
 
 --
 -Mark Wieder
 mwie...@ahsoftware.net
 
 
 ___
 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
 
 
 --
 Phil Davis
 
 PDS Labs
 Professional Software Development
 http://pdslabs.net
 
 
 ___
 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: dispatch and the target

[J. Landman Gay]

On 8/12/11 12:04 PM, Bob Sneidar wrote:

You can refer to the current stack using the topStack.


Yes, but with caveats. If the stack isn't a toplevel (regular document) 
stack, then it (usually) won't be the topstack. It might be the 
defaultstack though.



A library
should be capable of working no matter which stack has the focus. I
would rewrite  the scripts in the library stack to be independent.
Also, you should not have to dispatch to a library stack. Start Using
puts the stack script in the backScript, and therefore in the message
path.

This means however, that all your scripts need to be in the stack
script and not other objects.


That's true, start using only works with stack scripts. You can use 
the script of any object by doing insert script of object reference 
into back. That gives more flexibility and allows the in-use script to 
be stored anywhere.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: dispatch and the target

[Pete]

Thanks for the additional info.  start using works in my situation as the
scripts are all in the stack it refers to although I probably did that
because it was a requirement for start using.  In any case, it all seems
to work as expected.

I will have to experiment more with situations where the calling stack is
not toplevel.  Maybe I'll have to go back to parsing the executionContexts.

Pete
Molly's Revenge http://www.mollysrevenge.com




On Fri, Aug 12, 2011 at 11:04 AM, J. Landman Gay
jac...@hyperactivesw.comwrote:

 On 8/12/11 12:04 PM, Bob Sneidar wrote:

 You can refer to the current stack using the topStack.


 Yes, but with caveats. If the stack isn't a toplevel (regular document)
 stack, then it (usually) won't be the topstack. It might be the defaultstack
 though.


  A library
 should be capable of working no matter which stack has the focus. I
 would rewrite  the scripts in the library stack to be independent.
 Also, you should not have to dispatch to a library stack. Start Using
 puts the stack script in the backScript, and therefore in the message
 path.

 This means however, that all your scripts need to be in the stack
 script and not other objects.


 That's true, start using only works with stack scripts. You can use the
 script of any object by doing insert script of object reference into
 back. That gives more flexibility and allows the in-use script to be stored
 anywhere.

 --
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.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-livecodehttp://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: dispatch and the target

[Pete]

Update on this.  If the calling stack is a palette, the topstack refers to
one of the IDE's stacks (applicationoverview.rev I think), and the
defaultstack refers to the library stack not the palette stack.  In
addition, the executionContexts contains no reference to the palette stack.

I'm pretty much giving up hope that there is a safe way to get hold of the
calling stack.  I was hoping that a combination of start using and a
libraryStack handler in the library stack would do what I need but doesn't
look like that will work.  Not a big deal, just needs one extra line of code
in the calling stack to call my initialisation routine.

Pete
Molly's Revenge http://www.mollysrevenge.com




On Fri, Aug 12, 2011 at 11:38 AM, Pete p...@mollysrevenge.com wrote:

 Thanks for the additional info.  start using works in my situation as the
 scripts are all in the stack it refers to although I probably did that
 because it was a requirement for start using.  In any case, it all seems
 to work as expected.

 I will have to experiment more with situations where the calling stack is
 not toplevel.  Maybe I'll have to go back to parsing the executionContexts.

 Pete
 Molly's Revenge http://www.mollysrevenge.com




 On Fri, Aug 12, 2011 at 11:04 AM, J. Landman Gay jac...@hyperactivesw.com
  wrote:

 On 8/12/11 12:04 PM, Bob Sneidar wrote:

 You can refer to the current stack using the topStack.


 Yes, but with caveats. If the stack isn't a toplevel (regular document)
 stack, then it (usually) won't be the topstack. It might be the defaultstack
 though.


  A library
 should be capable of working no matter which stack has the focus. I
 would rewrite  the scripts in the library stack to be independent.
 Also, you should not have to dispatch to a library stack. Start Using
 puts the stack script in the backScript, and therefore in the message
 path.

 This means however, that all your scripts need to be in the stack
 script and not other objects.


 That's true, start using only works with stack scripts. You can use the
 script of any object by doing insert script of object reference into
 back. That gives more flexibility and allows the in-use script to be stored
 anywhere.

 --
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.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-livecodehttp://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: dispatch and the target

[Mark Wieder]

Pete-

Friday, August 12, 2011, 12:12:39 PM, you wrote:

 Update on this.  If the calling stack is a palette, the topstack refers to
 one of the IDE's stacks (applicationoverview.rev I think), and the
 defaultstack refers to the library stack not the palette stack.  In
 addition, the executionContexts contains no reference to the palette stack.

 I'm pretty much giving up hope that there is a safe way to get hold of the
 calling stack.  I was hoping that a combination of start using and a
 libraryStack handler in the library stack would do what I need but doesn't
 look like that will work.  Not a big deal, just needs one extra line of code
 in the calling stack to call my initialisation routine.

I don't know what your code looks like in the library stack, but you
might try substituting this stack instead of me to see if that
gives you the reference you're looking for.

-- 
-Mark Wieder
 mwie...@ahsoftware.net


___
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: dispatch and the target

[Mark Wieder]

Bob-

Friday, August 12, 2011, 10:52:35 AM, you wrote:

 I was hoping to avoid this conversation, but

Yeah, I was hoping you'd avoid it, too...

-- 
-Mark Wieder
 mwie...@ahsoftware.net


___
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: dispatch and the target

[Pete]

Nobody avoids Uncle Bob
Pete
Molly's Revenge http://www.mollysrevenge.com




On Fri, Aug 12, 2011 at 5:37 PM, Mark Wieder mwie...@ahsoftware.net wrote:

 Bob-

 Friday, August 12, 2011, 10:52:35 AM, you wrote:

  I was hoping to avoid this conversation, but

 Yeah, I was hoping you'd avoid it, too...

 --
 -Mark Wieder
  mwie...@ahsoftware.net


 ___
 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: dispatch and the target

[Mark Wieder]

Pete-

Thursday, August 11, 2011, 9:41:49 PM, you wrote:

 The dispatch methodology works fine but I'm finding that using the target
 or me in the external stack's handler resolves to the external library
 stack file not the stack that issued the dispatch command.  I can, of
 course, include the name of the dispatching stack as a parameter to the
 handler but I'm wondering if there is a way to track down the dispatching
 stack's name in these circumstances.

In short, if you've gotten into this situation then it's time to
rearchitect your application. You shouldn't have to ask this question.
You're fighting the message path, and while what you want to do can be
done, it ain't the right way to do things.

That said, if you don't want to pass the calling stack as an argument
you need to look at the executionContexts to get the call stack.

-- 
-Mark Wieder
 mwie...@ahsoftware.net


___
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: Dispatch and send

[Bob Sneidar]

Let me put it differently: Send generates a system message. Any system message. 
Dispatch calls a handler optionally with parameters. Make sense?

Bob


On Dec 22, 2010, at 9:40 AM, David Bovill wrote:

 Anyone got a reason for this being Appropriate behavior?
 
 dispatch beep to this cd -- no beep
 send beep to this cd -- a beep
 
 ___
 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: Dispatch and send

[Richard Gaskin]

David Bovill wrote:


Anyone got a reason for this being Appropriate behavior?

dispatch beep to this cd -- no beep

send beep to this cd -- a beep


Interestingly, running this in the Message Box:

  dispatch beep to this cd; put it

...yields unhandled

You get the same with any build-in command, e.g.:

  dispatch go next to this cd; put it

Whether this is a weakness in the engine or the documentation is a 
question of intention:


Is dispatch designed to handle only custom handlers? It appears to be, 
and if that's what's intended it's working fine and all that's needed is 
a note in the docs clarifying that.


But if the intention was that it could be used for built-in commands too 
then there appears to be a bug in the engine.


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

___
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: Dispatch and send

[stephen barncard]

I've noticed that the message box world has been little strange for some
commands.

In the past,   answer  Prompt  in the msg box   would
*not*show the dialog
but   answer Prompt; put it   *
does* show the answer dialog

 I  have not checked this since 4.0

sqb

On 22 December 2010 11:56, Richard Gaskin ambassa...@fourthworld.comwrote:

 David Bovill wrote:

  Anyone got a reason for this being Appropriate behavior?

 dispatch beep to this cd -- no beep

 send beep to this cd -- a beep


 Interestingly, running this in the Message Box:

  dispatch beep to this cd; put it

 ...yields unhandled

 You get the same with any build-in command, e.g.:

  dispatch go next to this cd; put it

 Whether this is a weakness in the engine or the documentation is a question
 of intention:

 Is dispatch designed to handle only custom handlers? It appears to be,
 and if that's what's intended it's working fine and all that's needed is a
 note in the docs clarifying that.

 But if the intention was that it could be used for built-in commands too
 then there appears to be a bug in the engine.

 --
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv


 ___
 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




-- 



Stephen Barncard
San Francisco Ca. USA

more about sqb  http://www.google.com/profiles/sbarncar
___
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: Dispatch and send

[Peter Brigham MD]

On Dec 22, 2010, at 12:56 PM, Richard Gaskin wrote:


David Bovill wrote:


Anyone got a reason for this being Appropriate behavior?

dispatch beep to this cd -- no beep

send beep to this cd -- a beep


Interestingly, running this in the Message Box:

 dispatch beep to this cd; put it

...yields unhandled

You get the same with any build-in command, e.g.:

 dispatch go next to this cd; put it

Whether this is a weakness in the engine or the documentation is a  
question of intention:


Is dispatch designed to handle only custom handlers? It appears to  
be, and if that's what's intended it's working fine and all that's  
needed is a note in the docs clarifying that.


Note to this effect submitted to the Dictionary entry on dispatch.

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig




___
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