Re: Problems with ShutDownRequest

[Ken Ray]

On 5/26/05 1:12 PM, "Howard Bornstein" <[EMAIL PROTECTED]> wrote:

> On 5/25/05, J. Landman Gay <[EMAIL PROTECTED]> wrote:
> 
>> The defaultstack may not be what you think it is, for example, so maybe the
>> message 
>> is being sent somewhere unexpected and the new stack never sees it.
> 
>> 
>> Try putting a button in your test stack that sets the defaultstack to
>> the current test stack before you try to quit. Any luck with that?
> 
> I put :
> on openstack
>   set the defaultstack to me
> end openstack
> 
> in the main stack and
> 
> on openstack
>   set the defaultstack to "Quit Test"
> end openstack
> 
> In the second stack. It didn't help.

No, you have to set the defaultstack just before you try and quit (i.e. the
line just before the quit call); defaultStack reverts to the topMost
non-palette stack at idle so doing it on openstack doesn't do anything.

>> One way to test without having to build an app is to suspend the
>> develpment environment (from the Development menu.) That won't make
>> tracking the problem any easier, but it saves you some trouble
>> rebuilding a lot of standalones.
> 
> Hmmm. I'm not sure I see the advantage.  I'd have to restart Rev each
> time it quit, and that seems to take longer than building standalones.
> :-)


Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Howard Bornstein]

On 5/25/05, J. Landman Gay <[EMAIL PROTECTED]> wrote:

> The defaultstack may not be what you think it is, for example, so maybe the 
> message 
> is being sent somewhere unexpected and the new stack never sees it.

> 
> Try putting a button in your test stack that sets the defaultstack to
> the current test stack before you try to quit. Any luck with that?

I put :
on openstack
  set the defaultstack to me
end openstack

in the main stack and

on openstack
  set the defaultstack to "Quit Test"
end openstack

In the second stack. It didn't help.


> 
> One way to test without having to build an app is to suspend the
> develpment environment (from the Development menu.) That won't make
> tracking the problem any easier, but it saves you some trouble
> rebuilding a lot of standalones.

Hmmm. I'm not sure I see the advantage.  I'd have to restart Rev each
time it quit, and that seems to take longer than building standalones.
:-)

-- 
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Howard Bornstein]

On 5/25/05, Jan Schenkel <[EMAIL PROTECTED]> wrote:

> >
> 
> Hi Howard,
> 
> Have you tried to 'start using' the mainstack of your
> standalone ? When you create a new stack, it is its
> own mainstack -- so when uncaught by the target stack,
> the 'shutdownRequest' message would go straight to the
> engine, bypassing your standalone mainstack.

But each stack had its own shutdownrequest handler. One of them should
have caught it.

> Another method to ensure that it will get caught is by
> putting the 'shutdownRequest' handler in a backscript.
> It seems to work for me in the Quartam Reports layout
> builder.
> 

That's what Brian suggested and it did work. But I still wonder if
I've found a bugzilla-able situation.

-- 
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Howard Bornstein]

On 5/25/05, Brian Yennie <[EMAIL PROTECTED]> wrote:
> Howard,
> 
> Try this:
> 
> 1) create a button "shutdown" with your script in it:
> 
> on ShutDownRequest
>answer "Really, Really Quit?" with "No" or "Quit"
>if it is "Quit" then pass ShutDownRequest
> end ShutDownRequest
> 
> 2) hide the button
> 
> 3) add this to your standalone:
> 
> on startup
>  insert the script of btn "shutdown" into back
> end startup
> 
> This should save you the hassle of trying to clone the script and get
> it in all of the appropriate places - a backscript will sit "behind"
> all of your open stacks and should get called reliably without having
> to set any scripts of cloned stacks.

Thanks Brian! This does work, so I can now get the funtionality I need
with my app. But it still doesn't answer the question (for me at
least) as to why I couldn't get this to work without a back script.

If I've got two (and only two) stacks open and each has the following
ShutDownRequest handler:

Stack 1:
on shutdownrequest
  answer "Really, really Quit?" with "No" or "Quit"
  if it is "Quit" then pass shutdownRequest
end shutdownrequest

Stack 2:
on shutdownrequest
  Send "shutdownRequest" to stack 1
end shutdownrequest

shouldn't I always get the shutdownRequest handler in stack 1
activated regardless of which stack is in front?

Thanks to all who offered suggestions.


-- 
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Brian Yennie]

Howard,

Try this:

1) create a button "shutdown" with your script in it:

on ShutDownRequest
  answer "Really, Really Quit?" with "No" or "Quit"
  if it is "Quit" then pass ShutDownRequest
end ShutDownRequest

2) hide the button

3) add this to your standalone:

on startup
insert the script of btn "shutdown" into back
end startup

This should save you the hassle of trying to clone the script and get 
it in all of the appropriate places - a backscript will sit "behind" 
all of your open stacks and should get called reliably without having 
to set any scripts of cloned stacks.


HTH,
Brian


On 5/24/05, Pat Trendler <[EMAIL PROTECTED]> wrote:

I seem to remember having this problem awhile ago.
I used  closestackRequest in the stack being saved as a 
file/document..


I tried this in both the stack script and the card script and neither
worked at all. Sigh.

I think I'm going to have to Bugzilla this if no one else has a
workable solution.


--
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Jan Schenkel]

--- Howard Bornstein <[EMAIL PROTECTED]>
wrote:
> One of my apps is not processing ShutDownRequest
> properly, but it's
> very complex, so I decided to build a simple test
> stack. I'm seeing
> the same thing with it. All my testing is done after
> building a
> standalone from the stack.
> 
> [snip]
> 
> If I can't trap shutDownRequest, my clients will
> lose all their data
> if they choose Quit without saving their document.
> 
> What am I missing?
> 
> -- 
> Regards,
> 
> Howard Bornstein
> 

Hi Howard,

Have you tried to 'start using' the mainstack of your
standalone ? When you create a new stack, it is its
own mainstack -- so when uncaught by the target stack,
the 'shutdownRequest' message would go straight to the
engine, bypassing your standalone mainstack.
Another method to ensure that it will get caught is by
putting the 'shutdownRequest' handler in a backscript.
It seems to work for me in the Quartam Reports layout
builder.

Hope this helped,

Jan Schenkel.

Quartam - Tools for Revolution


=
"As we grow older, we grow both wiser and more foolish at the same time."  (La 
Rochefoucauld)

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[J. Landman Gay]

On 5/24/05 8:50 PM, Howard Bornstein wrote:


On 5/24/05, Pat Trendler <[EMAIL PROTECTED]> wrote:


I seem to remember having this problem awhile ago.
I used  closestackRequest in the stack being saved as a file/document..



I tried this in both the stack script and the card script and neither
worked at all. Sigh.


I think Pat meant that shutdownRequest wasn't working, but substituting 
closestackRequest instead did.




I think I'm going to have to Bugzilla this if no one else has a
workable solution.



It might be a bug, but it feels like it's too early to tell yet. If 
shutdownRequest works in the first stack you create but not the second, 
then I'd be inclined to think something else is wrong. The defaultstack 
may not be what you think it is, for example, so maybe the message is 
being sent somewhere unexpected and the new stack never sees it.


One way to test without having to build an app is to suspend the 
develpment environment (from the Development menu.) That won't make 
tracking the problem any easier, but it saves you some trouble 
rebuilding a lot of standalones.


Try putting a button in your test stack that sets the defaultstack to 
the current test stack before you try to quit. Any luck with that?


Also, the docs say the shutdownRequest message is sent to the stack -- 
not the card -- so I'd be sure that my handler was in the stack script.


Just thinking out loud, no promises.

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Dar Scott]

On May 24, 2005, at 7:44 PM, Howard Bornstein wrote:

A standalone has limits on the new values
of the script.



Hmmm. I don't know what this means.


Sorry.  In my attempts to minimize my contribution to the mail load 
because of recent babbling, I sometimes become cryptic.


Check out scriptLimits in the dictionary.  You will find that the 
maximum number of statements that can be compiled at one time in a 
standalone is 10.


My concern was that you were appending the short handler to what was 
already in the script after a clone and what was there had many 
commands.  If you are simply setting the script with the short one you 
mentioned, then this limit is not your problem.


On May 24, 2005, at 7:49 PM, Thomas McGrath III wrote:
What do you mean by this? I am having a small problem with an openCard 
handler not always loading and want to know if it could be related or 
not.


Not unless you are changing scripts.

Dar



___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Howard Bornstein]

On 5/24/05, Pat Trendler <[EMAIL PROTECTED]> wrote:
> I seem to remember having this problem awhile ago.
> I used  closestackRequest in the stack being saved as a file/document..

I tried this in both the stack script and the card script and neither
worked at all. Sigh.

I think I'm going to have to Bugzilla this if no one else has a
workable solution.


-- 
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Thomas McGrath III]

Dar,

What do you mean by this? I am having a small problem with an openCard 
handler not always loading and want to know if it could be related or 
not.


Thanks

tom

On May 24, 2005, at 7:39 PM, Dar Scott wrote:


A standalone has limits on the new values of the script.


Thomas J McGrath III
[EMAIL PROTECTED]

412-831-3094
220 Drake Road
Bethel Park, PA 15102

<*)) >=<
"Life should NOT be a journey to the grave with the intention of 
arriving safely in an attractive and well preserved body, but rather to 
skid in sideways - a Cigar in one hand - a large steak in the other - 
your body thoroughly used up, totally worn out, and screaming - WOO 
HOO! What a Ride!"

___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Howard Bornstein]

On 5/24/05, Dar Scott <[EMAIL PROTECTED]> wrote:
> 
> Is this the only thing in the stack script?  Or are you adding to a
> long script already there?  


Yup, it's the only script. I'm trying to reduce this to its bare essentials.


> A standalone has limits on the new values
> of the script.
> 

Hmmm. I don't know what this means.

-- 
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Pat Trendler]

I seem to remember having this problem awhile ago.
I used  closestackRequest in the stack being saved as a file/document..

HTH

Pat
[EMAIL PROTECTED]

- Original Message - 
From: "Howard Bornstein" <[EMAIL PROTECTED]>

To: "Use Revolution" 
Sent: Wednesday, May 25, 2005 6:26 AM
Subject: Problems with ShutDownRequest


One of my apps is not processing ShutDownRequest properly, but it's
very complex, so I decided to build a simple test stack. I'm seeing
the same thing with it. All my testing is done after building a
standalone from the stack.

I start out with a main stack. The main stack has this handler:

on ShutDownRequest
 answer "Really, Really Quit?" with "No" or "Quit"
 if it is "Quit" then pass ShutDownRequest
end ShutDownRequest

If I run the main stack and choose Quit, I get the answer dialog and
everything works as expected.

Now, I've put a button on the main stack that creates a new stack and
places this handler in its stack script:

on ShutDownRequest
 send "ShutDownRequest" to stack "Quit Test" -- my main stack
end ShutDownRequest

If I click this button, thus creating the new stack, and then choose
Quit, I again get the answer dialog and everything works fine. If that
stack is frontmost, it sends the ShutDownRequest to my other stack
which puts up the dialog.

Here's the problem. If I close the second stack (the one created by
the button) and then create a another one (by clicking the button
again), THIS TIME, if I select Quit, the standalone quits, closing
both stacks without giving me the answer dialog.

For some reason, creating a stack, closing it, and creating a new one
causes the Rev engine to bypass the ShutDownRequest handlers
completely.

Why?

If I can't trap shutDownRequest, my clients will lose all their data
if they choose Quit without saving their document.

What am I missing?

--
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Dar Scott]

On May 24, 2005, at 2:26 PM, Howard Bornstein wrote:


Now, I've put a button on the main stack that creates a new stack and
places this handler in its stack script:

on ShutDownRequest
  send "ShutDownRequest" to stack "Quit Test" -- my main stack
end ShutDownRequest


Is this the only thing in the stack script?  Or are you adding to a 
long script already there?  A standalone has limits on the new values 
of the script.


Dar


___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Howard Bornstein]

On 5/24/05, Robert Brenstein <[EMAIL PROTECTED]> wrote:
> 
> I bet that if you copy the shutdownrequest script from your main
> stack to the one created on the fly (and thus do not send), the
> problem will go away. Shutdownrequest seems to be context specific
> and I think that your sending it from one stack to another confuses
> Rev.
> 
> Robert

Tried that. Didn't work. Same exact results. I also tried completely
trapping the ShutDownRequest in the new stack. For some reason,
ShutDownRequest is getting completely ignored.

Anybody have any ideas how I can further test this? Unfortunately, I
can't test it in the IDE because it interferes with the Quit command.

-- 
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problems with ShutDownRequest

[Robert Brenstein]

One of my apps is not processing ShutDownRequest properly, but it's
very complex, so I decided to build a simple test stack. I'm seeing
the same thing with it. All my testing is done after building a
standalone from the stack.

I start out with a main stack. The main stack has this handler:

on ShutDownRequest
  answer "Really, Really Quit?" with "No" or "Quit"
  if it is "Quit" then pass ShutDownRequest
end ShutDownRequest

If I run the main stack and choose Quit, I get the answer dialog and
everything works as expected.

Now, I've put a button on the main stack that creates a new stack and
places this handler in its stack script:

on ShutDownRequest
  send "ShutDownRequest" to stack "Quit Test" -- my main stack
end ShutDownRequest

If I click this button, thus creating the new stack, and then choose
Quit, I again get the answer dialog and everything works fine. If that
stack is frontmost, it sends the ShutDownRequest to my other stack
which puts up the dialog.

Here's the problem. If I close the second stack (the one created by
the button) and then create a another one (by clicking the button
again), THIS TIME, if I select Quit, the standalone quits, closing
both stacks without giving me the answer dialog.

For some reason, creating a stack, closing it, and creating a new one
causes the Rev engine to bypass the ShutDownRequest handlers
completely.

Why?

If I can't trap shutDownRequest, my clients will lose all their data
if they choose Quit without saving their document.

What am I missing?

--
Regards,

Howard Bornstein


I bet that if you copy the shutdownrequest script from your main 
stack to the one created on the fly (and thus do not send), the 
problem will go away. Shutdownrequest seems to be context specific 
and I think that your sending it from one stack to another confuses 
Rev.


Robert
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Problems with ShutDownRequest

[Howard Bornstein]

One of my apps is not processing ShutDownRequest properly, but it's
very complex, so I decided to build a simple test stack. I'm seeing
the same thing with it. All my testing is done after building a
standalone from the stack.

I start out with a main stack. The main stack has this handler:

on ShutDownRequest
  answer "Really, Really Quit?" with "No" or "Quit"
  if it is "Quit" then pass ShutDownRequest
end ShutDownRequest

If I run the main stack and choose Quit, I get the answer dialog and
everything works as expected.

Now, I've put a button on the main stack that creates a new stack and
places this handler in its stack script:

on ShutDownRequest
  send "ShutDownRequest" to stack "Quit Test" -- my main stack
end ShutDownRequest

If I click this button, thus creating the new stack, and then choose
Quit, I again get the answer dialog and everything works fine. If that
stack is frontmost, it sends the ShutDownRequest to my other stack
which puts up the dialog.

Here's the problem. If I close the second stack (the one created by
the button) and then create a another one (by clicking the button
again), THIS TIME, if I select Quit, the standalone quits, closing
both stacks without giving me the answer dialog.

For some reason, creating a stack, closing it, and creating a new one
causes the Rev engine to bypass the ShutDownRequest handlers
completely.

Why?

If I can't trap shutDownRequest, my clients will lose all their data
if they choose Quit without saving their document.

What am I missing?

-- 
Regards,

Howard Bornstein
---
www.designeq.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution