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