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 Revenge<http://www.mollysrevenge.com> >>>> >>>> >>>> >>>> >>>> On Thu, Aug 11, 2011 at 10:43 PM, Mark Wieder<mwie...@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 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
