Hi Rick,
Ron explained it in more detail. The process ID still points to the same
window and unless you are monitoring different events, you will get the same
result in both cases. Process ID are kind of like window handles but not the
same entirely.
Ron did a pretty good job in describing it. I use to use all of this when I
wrote a DOS screen reader program, back in the easy days of windows
programming. It worked really great and the Process ID was captured to keep
stacks and such straight forward for calling such things as, Is my screen
reader running?...so it does not get loaded twice into memory.
Windows has just messed up the ease at getting information from the
keyboard and screen mainly because of the layers of children involved...
I wrote the entire screen reader program using the MASM utility and all
done in machine code...
Screen Reader Demo:
http://www.youtube.com/watch?v=W2LyRC99Qx0
Part 2 Of Screen Reader Demo:
http://www.youtube.com/watch?v=uUy8c1jTt9k
Sent: Thursday, April 19, 2012 9:18 AM
Subject: Re: WE And Global Scripts And Thread Safety
Hi Bruce, I dont understand could you flesh out the following?
You wrote:
I think each instance is its own but I may be wrong.
When you talk about instance do you mean thread, script, sub or method within
a script etc...
And do you mean instance in the technical (OOP) sense or as a general term?
The only conflict is the
process ID which I am sure you are concerned with.
OK, I thought each script passed it's ProcessID for the APP it was scripting
but what about a Global Script?
Are you saying all global scripts run under the same process?
If so does each have it's own thread and, in that case, would local variables
not located inside a sub be Cross-Threaded and thus available and modifiable by
all other scripts running at the same time?
Try and see if your instance is
different, unless you are looking at the same events then that would create a
problem.
I dont understand the above.
How can I look at my instance? Do you mean thread? and, if so, how do I do
that or what tool would be good to use?
Your question about events should be handled, I think, by filtering messages
somehow as is done in Chip's class if I remember so I dont think you mean
script.
Also Rick, the Victory Associates software you were going to attempt to
work
with had a virus inside of it. It is a good thing you did not work with it.
Phew!
It wouldn't have mattered unless the virus was in the Corporation's software
since I dont think RDP would have transmitted the virus unless I downloade
software from his machine.
In either case I felt bad I couldn't have helped him.
Rick USA
----- Original Message -----
From: BT
To: [email protected]
Sent: Thursday, April 19, 2012 8:12 AM
Subject: Re: WE And Global Scripts And Thread Safety
Hi Rick,
I think each instance is its own but I may be wrong. The only conflict
is the process ID which I am sure you are concerned with. Try and see if your
instance is different, unless you are looking at the same events then that
would create a problem.
Also Rick, the Victory Associates software you were going to attempt to
work with had a virus inside of it. It is a good thing you did not work with it.
Bruce
Sent: Thursday, April 19, 2012 5:31 AM
Subject: WE And Global Scripts And Thread Safety
Hi Scriptors:
Does a Global Script run in it's own process with independent threads?
We pass the ProcessID to WE and it can be used for filtering Windows and
Messages
so I am wondering about whether shared (static) variable or data objects
in one Global
script could step on shared (static) objects of the same name and
signature in another
script or Client Application if they are not Windows or Messages.
In other words, are Global Scripts thread safe considering shared
(static) variables
and Data items?
I hope this question makes sense.
I have an external script that worked well when associated with a
particular application but had some problems when I made it a Global Script.
I have since pulled out code that used shared items and have made
everything instance objects but haven't had time to test it yet.
My guess was that I was stepping on my own shared objects since I used
the same objects in another application I was looking at and even in other
global test scripts I still had running since they were more or less useful.
I just would like to know if this is a possibility since resolving it is
my responsibility if that is the case, and yours too as scriptors.
If each script runs in it's own process independent of each other and
independent of the targeted application this might not be a consideration but I
dont think that is how it works.
WE needs communication among all facets of a session so I am guessing
this conceptual model needs consideration but would like to know the real deal
so I am not guessing.
Rick USA