App stays in memory after close, CPU usage jumps to 100%
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
App stays in memory after close, CPU usage jumps to 100%
I have made an app that, when I run it then close it on a WinXP 2000 Home Edition, SP2 machine, and on a WinXP Pro pc, it stays in memory as shown in the task manager. And what's worse, its CPU usage jumps to 100%. How can I totally kill the app from memory?
Thanks for any help!
Thanks for any help!
I'm not an expert here on this, but I know there are two properties you
can set that might resolve this.
When you have your stack open in the Rev IDE, there are two properties
on the property inspector > Basic Properties:
*purge stack on close
*purge window on close
Those should hopefully take care of your problem, unless! There is some
code in your stack that is causing this. Such things as a repeat loop that
did not exit it's loop. Quite easy for this to happen as I've had this happen
many times.
Check your repeat loops, put checks on those properties mentioned above
and see if all goes well.
-Garrett
can set that might resolve this.
When you have your stack open in the Rev IDE, there are two properties
on the property inspector > Basic Properties:
*purge stack on close
*purge window on close
Those should hopefully take care of your problem, unless! There is some
code in your stack that is causing this. Such things as a repeat loop that
did not exit it's loop. Quite easy for this to happen as I've had this happen
many times.
Check your repeat loops, put checks on those properties mentioned above
and see if all goes well.
-Garrett
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Contact:
Hi Steve,
Do you have any 'send in time' constructs in your code? The engine won't quit if you close the last window and there are still pendingMessages.
If that doesn't help, make the stack available for download and I'm sure someone will look it over to see what's going on.
Jan Schenkel.
Do you have any 'send in time' constructs in your code? The engine won't quit if you close the last window and there are still pendingMessages.
If that doesn't help, make the stack available for download and I'm sure someone will look it over to see what's going on.
Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
Re: App stays in memory after close, CPU usage jumps to 100%
HI all,
I am trying to prevent additional mouseup messeges being sent while a script is running. We a user accididentally triple clicks a button the mouseup command gets sent 3 times.
I trued using
repeat until the pendingMessages is empty
cancel item 1 of line 1 of the pendingMessages
end repeat
I also tried putting LockDupEvents at the top of the script and unLockDupEvents at the end of the scripts.
on LockDupEvents
if "dev" is in the environment and the optionKey is "down"
then
put empty into sDupEventsFlag
end if
if sDupEventsFlag is true then exit to top
put true into sDupEventsFlag
end LockDupEvents
on UnlockDupEvents
put empty into sDupEventsFlag
end UnlockDupEvents
Nothing seems to work. Any ideas?
I am trying to prevent additional mouseup messeges being sent while a script is running. We a user accididentally triple clicks a button the mouseup command gets sent 3 times.
I trued using
repeat until the pendingMessages is empty
cancel item 1 of line 1 of the pendingMessages
end repeat
I also tried putting LockDupEvents at the top of the script and unLockDupEvents at the end of the scripts.
on LockDupEvents
if "dev" is in the environment and the optionKey is "down"
then
put empty into sDupEventsFlag
end if
if sDupEventsFlag is true then exit to top
put true into sDupEventsFlag
end LockDupEvents
on UnlockDupEvents
put empty into sDupEventsFlag
end UnlockDupEvents
Nothing seems to work. Any ideas?
Re: App stays in memory after close, CPU usage jumps to 100%
Hi Max,
have a look at flushEvents in the dictionary. Seems to be what you are looking for. This clears events that build up during the execution of a handler. If you have events that come "in the future" as via send in time you would still have to clear them as in your first handler.
Kind regards
Bernd
have a look at flushEvents in the dictionary. Seems to be what you are looking for. This clears events that build up during the execution of a handler. If you have events that come "in the future" as via send in time you would still have to clear them as in your first handler.
Kind regards
Bernd