unpacking

[Jim Ault]

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