Re: unpacking
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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <
>> [EMAIL PROTECTED]>
>>> 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 | [EMAIL
Re: unpacking
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <
> [EMAIL PROTECTED]>
> > 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 | [EMAIL PROTECTED]
> >> HyperActive Software | http://www.hyperactivesw.com
> >> ___
> >> use-revolution mailing list
> >> use-revolution@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@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription
> > preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
> ___
Re: unpacking
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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 | [EMAIL PROTECTED]
>> HyperActive Software | http://www.hyperactivesw.com
>> ___
>> use-revolution mailing list
>> use-revolution@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: unpacking
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 <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] > HyperActive Software | http://www.hyperactivesw.com > ___ > use-revolution mailing list > use-revolution@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: unpacking
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 | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: unpacking
Problem solved, but I don't know why. If I pass jDate with the "j" already prepended, it works. -- Paul > > On 3/1/08 9:32 PM, "Paul Foraker" <[EMAIL PROTECTED]> 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 > > put the jDate of this stack into tJournal > > if tJournal is empty then > > delete char 1 of jDate -- j > > convert jDate to long date > > answer "Sorry, there's no journal for" && jDate &"." > > exit to top > > end if > > -- ... > > end unpackTheData > > > > I'm passing the seconds for a date I know exists, and I can execute code > > similar to the above in the Message Box and it works fine. In the > script, > > however, tJournal is always empty. > > > > I thought maybe it was a data-typing error, but this works in the > Message > > Box: > > > > put empty into tJournal > > put "2/29/08" into jdate > > convert jDate to seconds > > put "j" before jDate > > put the jdate of this stack into tJournal > > put tJournal > > > ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: unpacking
Thanks, Jim. Yes, I have confirmed in the inspector that the property exists, and as I mentioned, the correct data is retrieved in the Message Box, but not in the stack script. The variable jDate is composed of the letter "j" and the seconds for the date. I delete the "j" when I want to convert the seconds back to a long date for the dialog. Otherwise, it's not a date and the conversion would fail. -- Paul On Sat, Mar 1, 2008 at 9:54 PM, Jim Ault <[EMAIL PROTECTED]> wrote: > First, use the stack inspector to confirm that your property is indeed the > value you think it is. > > Do this by opening the stack inspector, then choose the "custom > properties" > drop down. Now inspect the values: > > set the jDate of this stack to "99/88/77" > > then > put the jDate of this stack into tJournal > > By the way, why would you be doing > > delete char 1 of jDate -- j > > convert jDate to long date > > answer "Sorry, there's no journal for" && jDate &"." > > since jDate is the name of the custom property and contains no data > itself, > and why would you want to delete char 1 of jDate? > > Hope this helps > > Jim Ault > Las Vegas > > > On 3/1/08 9:32 PM, "Paul Foraker" <[EMAIL PROTECTED]> 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 > > put the jDate of this stack into tJournal > > if tJournal is empty then > > delete char 1 of jDate -- j > > convert jDate to long date > > answer "Sorry, there's no journal for" && jDate &"." > > exit to top > > end if > > -- ... > > end unpackTheData > > > > I'm passing the seconds for a date I know exists, and I can execute code > > similar to the above in the Message Box and it works fine. In the > script, > > however, tJournal is always empty. > > > > I thought maybe it was a data-typing error, but this works in the > Message > > Box: > > > > put empty into tJournal > > put "2/29/08" into jdate > > convert jDate to seconds > > put "j" before jDate > > put the jdate of this stack into tJournal > > put tJournal > > > ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: unpacking
First, use the stack inspector to confirm that your property is indeed the value you think it is. Do this by opening the stack inspector, then choose the "custom properties" drop down. Now inspect the values: set the jDate of this stack to "99/88/77" then put the jDate of this stack into tJournal By the way, why would you be doing > delete char 1 of jDate -- j > convert jDate to long date > answer "Sorry, there's no journal for" && jDate &"." since jDate is the name of the custom property and contains no data itself, and why would you want to delete char 1 of jDate? Hope this helps Jim Ault Las Vegas On 3/1/08 9:32 PM, "Paul Foraker" <[EMAIL PROTECTED]> 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 > put the jDate of this stack into tJournal > if tJournal is empty then > delete char 1 of jDate -- j > convert jDate to long date > answer "Sorry, there's no journal for" && jDate &"." > exit to top > end if > -- ... > end unpackTheData > > I'm passing the seconds for a date I know exists, and I can execute code > similar to the above in the Message Box and it works fine. In the script, > however, tJournal is always empty. > > I thought maybe it was a data-typing error, but this works in the Message > Box: > > put empty into tJournal > put "2/29/08" into jdate > convert jDate to seconds > put "j" before jDate > put the jdate of this stack into tJournal > put tJournal > > Any suggestions? > > Thanks, > > -- Paul > ___ > use-revolution mailing list > use-revolution@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
