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
