dispatch and the target

Bob Sneidar bobs at twft.com
Fri Aug 12 13:52:35 EDT 2011


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 <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
>> 
>> 
> _______________________________________________
> 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





More information about the use-livecode mailing list