Re: Dispatch

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 t

Re: Dispatch

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 "pas

Re: Dispatch

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 dispatc

Re: Dispatch

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 di

Re: Dispatch

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-liveco

Re: Dispatch

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,

Re: Dispatch

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 ev

Re: Dispatch

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 assig

Re: Dispatch

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

Re: Dispatch msg from one top level stack to one behind it without raising the latter

>>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 shoul

Re: Dispatch msg from one top level stack to one behind it without raising the latter

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 thi

Re: Dispatch msg from one top level stack to one behind it without raising the latter

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 Kerne

Re: Dispatch msg from one top level stack to one behind it without raising the latter

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 go

Re: Dispatch msg from one top level stack to one behind it without raising the latter

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 s

Re: dispatch usage versus send

Thomas McGrath III 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 >

Re: Dispatch vs Libraries

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. I'm normally quite allergic to multiple inheritance, and so if I find myself in a situation where I

Re: Dispatch vs Libraries

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

Re: Dispatch vs Libraries

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 wrote: > On Sun, Nov 27, 2011 at 10:41 AM, Pete wrote: > > So

Re: Dispatch vs Libraries

On Sun, Nov 27, 2011 at 10:41 AM, Pete 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.

Re: Dispatch vs Libraries

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 wrote: > > > I think the array element resolves to a long button ID, so really it > > isn't any different t

Re: Dispatch vs Libraries

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 t

Re: Dispatch vs Libraries

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 wrote: > 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 t

Re: Dispatch vs Libraries

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. --

Re: Dispatch vs Libraries

One thing you might want to consider is whether you plan to use this logic in more than one application - that's when libraries come into their own, a central depository for reusable handlers. Something looks a little strange about the first dispatch statement - you're sending a message to an arra

Re: Dispatch vs Libraries

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-liveco

Re: dispatch and the target

Nobody avoids Uncle Bob Pete Molly's Revenge On Fri, Aug 12, 2011 at 5:37 PM, Mark Wieder 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... > >

Re: dispatch and the target

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 Pleas

Re: dispatch and the target

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 executionC

Re: dispatch and the target

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 m

Re: dispatch and the target

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 th

Re: dispatch and the target

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

Re: dispatch and the target

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

Re: dispatch and the target

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 mentione

Re: dispatch and the target

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 On Fri, Aug 12, 2011 at 9:47 AM, Phil Davis wrote: > Is there a reason you don't want to use a global variable as

Re: dispatch and the target

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 t

Re: dispatch and the target

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.

Re: dispatch and the target

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, Referrin

Re: dispatch and the target

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

Re: dispatch and the target

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, includ

Re: Dispatch and send

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

Re: Dispatch and send

Seems right to me. Dispatch looks for a handler in the script you are dispatching to. You would have to have a handler called ON BEEP which would be illegal and wouldn't compile because BEEP is a reserved word. Try using send instead. Bob On Dec 22, 2010, at 9:56 AM, Richard Gaskin wrote: >

Re: Dispatch and send

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 ...y

Re: Dispatch and send

I'd say it's a bug? On 22 December 2010 17:56, 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: >

Re: Dispatch and send

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 t

Re: Dispatch and send

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