Standalones requiring force-quit (and messages?)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Standalones requiring force-quit (and messages?)

Dr. Hawkins
I've been force-quitting the IDE as my standard so long that I don't give
it any thought . . . the frequency with which it gets lost, beachballs, or
whatever is high enough that I usually don't even try a plain quit.

Anyway, as I'm being advised that the standalones that people are testing
are needing force quits, I recalled that there seems to be something that
frequently stops the quit, even when the IDE is behaving.  I also found
that at least sometimes, turning messages off allows the quit to happen
quickly.

There isn't any code that should be intercepting the quit or shutdown
requests, but I'm wondering if the period handlers could be somehow
blocking this?  e.g., ones like

on doIt
doSomething
send "doIt" to me in 100 milliseconds
end doIt

This means that there are always messages in the queue; is the engine
waiting for that to empty, or do i have something more awkward on my hands?
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Standalones requiring force-quit (and messages?)

Ben Rubinstein
On 27/02/2015 17:56, Dr. Hawkins wrote:
> I've been force-quitting the IDE as my standard so long that I don't give
> it any thought . . . the frequency with which it gets lost, beachballs, or
> whatever is high enough that I usually don't even try a plain quit.

Something isn't right on your set-up then.  I force-quit the IDE maybe once
per month or less.  I don't think that what you're experiencing is normal
behaviour.  Do you have some interesting extensions or add-ons as part of your
standard environment?  What OS are you running on?

Ben



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Standalones requiring force-quit (and messages?)

J. Landman Gay
In reply to this post by Dr. Hawkins
On 2/27/2015 11:56 AM, Dr. Hawkins wrote:

> There isn't any code that should be intercepting the quit or shutdown
> requests, but I'm wondering if the period handlers could be somehow
> blocking this?  e.g., ones like
>
> on doIt
> doSomething
> send "doIt" to me in 100 milliseconds
> end doIt
>
> This means that there are always messages in the queue; is the engine
> waiting for that to empty, or do i have something more awkward on my hands?

Pending messages will always prevent a shutdown. So will open drivers.
You need to close everything and remove all pending messages from the
queue. See the "cancel" command in the dictionary.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Standalones requiring force-quit (and messages?)

Paul G
In reply to this post by Dr. Hawkins
If stack is closed while pending message queue is not empty, stack can remain running in memory.
ie, if looping with something like "send to something in 500 milliseconds" type loop.

I always use something like the following in a standalone...

on closeStack
  repeat until the pendingMessages is empty
  cancel item 1 of line 1 of the pendingMessages
  end repeat
end closeStack

Paul
Reply | Threaded
Open this post in threaded view
|

Re: Standalones requiring force-quit (and messages?)

Bob Sneidar-2
In reply to this post by Dr. Hawkins
Only time I have to force quit is if I made a database call to a stale database connection, and that of course is my fault for not closing the connection when done with it. About the only way to find something like this is to have a logging system that records everything your application does, then look at the last thing it attempted to do. The problem will be in the thing you told it to do AFTER that, since that thing was what crashed the app.

Bob S


> On Feb 27, 2015, at 09:56 , Dr. Hawkins <[hidden email]> wrote:
>
> I've been force-quitting the IDE as my standard so long that I don't give
> it any thought . . . the frequency with which it gets lost, beachballs, or
> whatever is high enough that I usually don't even try a plain quit.
>
> Anyway, as I'm being advised that the standalones that people are testing
> are needing force quits, I recalled that there seems to be something that
> frequently stops the quit, even when the IDE is behaving.  I also found
> that at least sometimes, turning messages off allows the quit to happen
> quickly.
>
> There isn't any code that should be intercepting the quit or shutdown
> requests, but I'm wondering if the period handlers could be somehow
> blocking this?  e.g., ones like
>
> on doIt
> doSomething
> send "doIt" to me in 100 milliseconds
> end doIt
>
> This means that there are always messages in the queue; is the engine
> waiting for that to empty, or do i have something more awkward on my hands?
> --
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode