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
