This is exactly the same as my example of two Window objects that refer
to the same window. Your two scripts will see each other's changes, but
will not unintentionally tromp on each other.
On 4/20/2012 6:10 AM, RicksPlace wrote:
Hi Again:
One final thought:
There might actually be a senario where scripts could step on each
other, internal or external.
That is if I were to open NotePad and there are 2 scripts, perhaps one
global and one an associated script, accessing that process at the
same time.
While both scripts are in their own threads they are accessing the
same client process and thus objects in that process may be Vulnerable
to unintended consequences.
Is there something in the way WE handles scripts that would make
this impossible or is it up to the scriptors to ensure this does
not happen?
Rick USA
----- Original Message -----
*From:* RicksPlace <mailto:[email protected]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Friday, April 20, 2012 5:54 AM
*Subject:* Re: WE And Global Scripts And Thread Safety
Hi Guys: Thanks for the info.
What process do the VBS scripts run under?
Is it the WindowEyes Assembly or something else?
A process has it's own space and variables and all that jazz
so my external script won't have to worry about stepping on
anything running under the WindowEyes Process.
I am not so sure about the various VBS apps running
concurrently under a single process but that is not relevant
to my external script at hand anyway.
I have found that WE provides a STA model and my script is
running in STA mode by default.
So I am in compliance there.
Marshalling and syncronization are automatically done for com
between the managed process and the OutOfProcess operations.
The only communications between my Process, threads, and any
of the Global Scripts running under the WE Process? would have
to be manually provided by the WE Engine and I dont think it
does that.
So, if my understanding is correct I am good to go with either
a Global or a Associated script without having to worry about
Cross Process or threading except within my own Process
environment.
Does this sound right guys?
Rick USA
----- Original Message -----
*From:* Chip Orange <mailto:[email protected]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Thursday, April 19, 2012 9:34 PM
*Subject:* RE: WE And Global Scripts And Thread Safety
Hi Rick,
As Ron mentioned, there is no difference between running a
script globally or not. It's only about when it's started and
nothing else. An application-specific app gets started when
the program starts; global apps when WE starts.
Everybody gets their own thread at a minimum, and if external,
their own process.
Chip
------------------------------------------------------------------------
*From:* RicksPlace [mailto:[email protected]]
*Sent:* Thursday, April 19, 2012 12:21 PM
*To:* [email protected]
*Subject:* Re: WE And Global Scripts And Thread Safety
Hi BT: Ya, back in the day I wrote a sort of Space
Invaders for the first version of the IBM PC using Assembler.
Back then we used registers and offsets as well as the
basic instruction set available with the IBM assembler for
it's PC.
I have never mucked with machine code after having to do
it a little in school back in the 1960s if I remember.
As I read up on processes, threads and apartments I am
finding out more about the complexity of the Operating
System and how it spins off new processes and the threads
associated with a process, marshalling for cross-threading
and cross-process operations and how these states can be
set within an applications program in vb.net or C#.
Prior to this I had only used some of the high-level tools
to run threads in the background.
Now I am doing a little reading about how sta and mta
and the various Threading Class properties and methods
impact the operations of a vb.net or CSharp program.
It does, however, seem that running a script globally
is a thing which might require a solid understanding
of the above technicals to avoid some nasty unintended
consiquences for end users.
Anyway, I'll continue reading up on this subject, try
some experiments and see how it relates to a COM
server as it were to try and have a solid working
understanding of these critical technicals.
Thanks for the help guys:
Rick USA
----- Original Message -----
*From:* BT <mailto:[email protected]>
*To:* [email protected]
<mailto:[email protected]>
*Sent:* Thursday, April 19, 2012 9:35 AM
*Subject:* Re: WE And Global Scripts And Thread Safety
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 <mailto:[email protected]>
*To:* [email protected]
<mailto:[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
