Hi Dave,
That could very well be an issue with the keystrokes consistently failing
and even locking up WE.
Most likely there is in fact an object not being destroyed as prescribed by
all programmers to do in any app.
This also resides inside the creation of a class. It is a must to have the
destroy of an object inside the class to insure no memory usage happens.
Granted there are advantages to not destroying g values such as cursor
positions and such, but objects can eventually do damage especially if your app
is running for hours at a time.
I also wonder if the Audible mouse is using Python for sound effects, if
so, memory usage can run high when not destroying those objects for it.
Sincerely
Bruce
Sent: Friday, May 17, 2013 6:21 PM
Subject: Possible bug in the Audible Mouse app?
I was playing around with my taskmanager this evening. I realized, that my WE
kept creeping slowly upward, all the time, when comes to memory usage. I see
this, both in the normal memory usage column, as well as in the Peak usage
column.
I then decided to go through the hazzle of some testing. First, I turned off
all apps, then restarted WE. The memory usage now landed on 62276K in the peak
column. It stayed steady there, even when I moved around, and switched back and
forth between some windows.
Next, I turned back on, the different installed apps, one by one, to see if I
could get hold of the memory-eating app. Everything went well, all till I
turned on the Audible Mouse app.
Immediately, the mouse app did display no trouble. But after moving the mouse
back and forth a number of times, the peak memory usage column started to creep
upward. If I placed the mouse on the line of the taskmanager, showing WinEyes,
I used Insert-4 and -6, to move back and forth on the columns. For each time I
moved, the number went up with something like 30 or 40.
I now thought, I had found the "sinner". So, back to the app manager, and
turned off the Audible Mouse app. Then back to the taskmanager. And, move your
mouse around between the columns in the WinEyes line.
Funny thing is, that now, still the memory keeps creeping slowly upward.
Puzzles me, but I wonder if there is an object or something - either in the
Audible Mouse, or in the GWAudiokit which it relies on - that does not get
cleared properly, or something similar.
You could argue, that the memory expanding usage, could have been caused by
something else. But I really played around with the stuff a while for each app
I turned on. That means, several minutes prior to turning on the Audible Mouse
app. And, although the memory usage increased slightly for each app loaded,
once the individual app had loaded, the new usage number would stay steady, way
up till I loaded next app.
Ok, so I decided to perform one more test. In the new state, with the Audible
Mouse again disabled, the memory kept creeping up. So, I thought, it could have
to do with my moving the mouse around. As I said, when moving the mouse back
and forth between the columns quickly, each move increased the memory with 30
or a little more. Now, I thought, what happens if I simply leave the keyboard
for a couple of seconds, between the moves. Guess what, now the increase was
somehow higher. for each move of the mouse, I now would see 50, 60 or more in
increase - all depending on how long I waited between each move.
Hope all this explanation made sense. I thought to ask, if anyone else on the
list can reproduce these steps. Whether this all is directly connected to the
Audible Mouse app, I am uncertain. It seems to me, that something gets started
when you activate that app, but does not turn off, even when you stop the app
itself. Maybe some indirect effect. Really don't know, but I hate to see WE
eating more and more memory. And, I wonder if this kind of memory leak could
even cause some of the instability that all the sudden happnes to halt my WE
altogether.
Running WinXP Pro, WE7.5.4 - at the moment.
