unpacking

[Jim Ault]

According to the docs, the stack should not be purged until the handler(s)
finish, so the variable should remain available to be passed.  If you tried
to open another stack with the same name, Rev should complain.

I do know that complex send systems can create 'folds' in the message path
that no longer make sense and this will cause failures, but it does not seem
like you would be using those in   ' unpackTheData jDate ' so there should
be no conflict or loss of data.

For the moment, you have an answer that works.

Jim Ault
Las Vegas


On 3/2/08 12:51 AM, "Paul Foraker" <paul at whitefeather.com> wrote:

> Hi Jim,
> 
> The Variable Watcher indicates that the value of the incoming variable is
> correct, and remains so throughout the execution (or the VW is not updating
> properly). Nevertheless, the 'close stack' kills the utility of the
> variable.
> 
> -- Paul
> 
> On Sat, Mar 1, 2008 at 11:58 PM, Jim Ault <JimAultWins at yahoo.com> wrote:
> 
>> I am not sure I am on the right track here, but it seems the 'close stack'
>> is working as I would expect in your example.
>> 
>> When you start a script using a handler in a stack, you should not be able
>> to close that stack before finishing the handler, including all of the
>> function and handler calls.  It is not logical to say 'start running this
>> handler, but before it is done, purge it from memory'
>> 
>> In this particular case, I would probably use
>> 
>> on mouseUp -- button on a card of sub stack "Days"
>> --
>> --
>>    unpackTheData jDate
>>  send ("close stack " & the short name of this stack ) to me in 10
>> milliseconds
>> end mouseUp
>> 
>> If you were to use the Variable Watcher window, you might see that the
>> definition of the variable 'jDate' becomes empty when you close the stack
>> that started the process.
>> 
>> You might test this:
>>>   close stack "Days" -- back on main stack "Journal"
>>>   unpackTheData jDate
>>       put ">|" & jDate & "|<" into msg  --to see if it still has the date
>>> end mouseUp
>> 
>> 
>> Be careful when using the Message Box, since it tries to interpret the
>> command line, but does not always work the same way as running a handler,
>> especially when trying to test the 'do' command.
>> 
>> Jim Ault
>> Las Vegas
>> 
>> On 3/1/08 10:57 PM, "Paul Foraker" <paul at whitefeather.com> wrote:
>> 
>>> Turns out the problem was in the calling handler, but this is a little
>>> weird. When I reported just now that I'd fixed it by passing "j" already
>>> prepended to the seconds, I had only tried that from the Message Box.
>> Back
>>> inside the calling script, it didn't work. Here's the calling script in
>> a
>>> button on a substack's card (faux dialog):
>>> 
>>> on mouseUp -- button on a card of sub stack "Days"
>>>   get the selectedText of fld "DaysList"
>>>   convert it to seconds
>>>   put "j" & it into jDate
>>>   close stack "Days" -- back on main stack "Journal"
>>>   unpackTheData jDate
>>> end mouseUp
>>> 
>>> That doesn't work. Even though jDate arrives at the main stack script
>> with
>>> the correct value, that value cannot be used to access the main stack's
>>> custom property.
>>> 
>>> The unpackTheData handler does work, however, from the Message Box. That
>> is,
>>> I can pass "j"-something to the stack script and it will work.
>>> 
>>> So, it had to be the "close stack" command in the calling script. Sure
>>> enough, this works:
>>> 
>>> on mouseUp -- in a button on sub stack "Days" of main stack "Journal"
>>>   get the selectedText of fld "DaysList"
>>>   convert it to seconds
>>>   put "j" & it into jDate
>>>   go stack "Journal" -- main stack
>>>   unpackTheData jDate
>>>   close stack "Days" -- substack cannot be closed prior to execution
>>>     -- of a handler in the main stack
>>> end mouseUp
>>> 
>>> I would call that a bug.
>>> 
>>> -- Paul
>>> 
>>> On Sat, Mar 1, 2008 at 10:44 PM, J. Landman Gay <
>> jacque at hyperactivesw.com>
>>> wrote:
>>> 
>>>> Paul Foraker wrote:
>>>>> I'm building a stack that is a data entry app for a daily journal.
>> Once
>>>> the
>>>>> day's entries have been posted (emailed to myself), I want to store
>> them
>>>> in
>>>>> the stack. I came up with a scheme of prepending "j" to the seconds
>>>>> representing the day and using that as the name of a custom property.
>> No
>>>>> problem storing that. When I retrieve it in a script, however, it's
>>>> always
>>>>> empty.
>>>>> 
>>>>> on unpackTheData jDate -- in seconds
>>>>>   put "j" before jDate
>>>>>   put empty into tJournal
>>>>>   put the jDate of this stack into tJournal
>>>>>   -- do "put the" && jDate && "of this stack into" && tJournal --
>> didn't
>>>>> work
>>>> 
>>>> I think you do need to use the "do" statement to force evaluation. But
>>>> the tJournal variable should be part of the "do" statement itself; Rev
>>>> will recognize it correctly as a variable. So, something like this
>>>> should work:
>>>> 
>>>> do "put the" && jDate && "of this stack into tJournal"
>>>> 
>>>> --
>>>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>>>> HyperActive Software           |     http://www.hyperactivesw.com
>>>> _______________________________________________
>>>> use-revolution mailing list
>>>> use-revolution at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>> 
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription
>>> preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
>> 
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution