Hi Again David,
Making things global does make things more secure. Ridding the object,
upon destroy, is also a good method to release the memory if the app/program is
still running and not using that call. For WE states the memory is released
when the app stops running...but always be cautious.
Yes, having the error is the best thing for all the hypothetical thrown
out at the moment.
The timer makes another number each time it is called, usually in
sequential order, but that number must be kept to destroy the timer setting it
was associated with. So always check for a number greater than 0 and stop it if
you are starting over again.
Bruce
Sent: Friday, February 20, 2015 8:44 AM
Subject: Re: Inside / Outside Apps, Conflicting?
David,
While a conflict is technically possible, I don't believe this is
necessarily the cause of your app's crash. Specific details on the
nature of the error, and what you might be doing with the string being
spoken, would be of more use.
Steve
On 2/20/2015 12:54 AM, David via Scripting wrote:
I recently was contacted by an end-user, with a rather interesting
situation. Wonder if this may be most for the Tech Department at
AISquared to answer - but of course welcome any feedback and input
from others on the list as well.
If I get things right, all apps running under Window-Eyes, would be
running as part of the one and same process. At least, looking at
TaskManager, there is no separate listing for any of the WE apps
running. And, in this environment the Window-Eyes overlay would
control when and how each app gets its resources. Please, do let me
know if I have misunderstood anything this far.
Now, the user who contacted me, was running a stand-alone script -
outside the Window-Eyes environment - but still hooking on to the WE
Module. This lets the stand-alone script make use of the WE objects,
it seems. OK, I have never done this kind of tweaking, so have to lean
on the information I was provided.
Reason why I bring it up on the board, is because the user gets some
error messages, complaining about parts of my WE app, which definitely
is running inside the WE environment. It seems that both my "inside"
app, and the user's "outside" script, are using the speech object of
the WE Module.
Again, did I get things right, long as two or more apps are running
inside the WE environment, even if they both are calling the same
object (in this case the Speech object), the one will do its job,
prior to the next one getting its hands on the speech string. But what
happens when the one app is running inside the WE process, and the
other speech call comes from an outsider script? Will there be any
chance that they will get in conflict? and if so, is there anything
that either I, or the user, could do to prevent such conflicts? Some
kind of prioritizing, timing or object hooking.
Admitedly, I am a bit surprised there would be an error halting my app
under WE, but according to the user, all the Outside script is doing,
is to hook on to the WE Module, and send some Speak commands. To what
extent this is the real cause for the crashing of my app, we haven't
been able to determine yet, but this is the only user who has reported
this issue. Besides, a bit of communicating back and forth, kind of
have eliminated a handful other possibilities. That is why I bring it
all up on the board, hoping to get some feedback as to whether there
would be any chance that an Outside script can outrange the apps that
are running Inside WE itself. Just trying to trace what causes the
issue the user is experiencing, and had a guess that something like
this could be the bottle-neck. So thought to have some educated
clarification from someone more technical on the matter, than what I
have ever become.
Thanks for your consideration.
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/lab4me%40fltg.net.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/trailerdavid%40hotmail.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
