dispatch and the target

[Pete]

No reason other than I never thought of it!  Thanks for the simple solution.
 Also, I'd rather not talk about my Uncle Bob....
Pete
Molly's Revenge <http://www.mollysrevenge.com>




On Fri, Aug 12, 2011 at 9:47 AM, Phil Davis <revdev at pdslabs.net> 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<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<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<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<http://lists.runrev.com/mailman/listinfo/use-livecode>
>
>