dispatch and the target

[Pete]

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 <bobs at 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<mwieder at 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
> >>>  mwieder at ahsoftware.net
> >>>
> >>>
> >>> _______________________________________________
> >>> use-livecode mailing list
> >>> use-livecode at 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 at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>