The only difference between global and application-specific scripts is
the conditions under which they are started and stopped. There is no
other difference.
If you're using an external script, of course it runs in its own process
independent from other scripts. Any Window-Eyes objects it uses are also
independent from other objects, with the obvious exception of things
like the mouse object that represent specific real-world things. That
includes Window objects: if you get a Window object for, say, the active
overlap and change the name of it you should not be surprised if some
other script that gets a Window object for the same overlap gets the new
name. The two Window objects are distinct, but since they refer to the
same window they will interact with each other.
Thread safety is up to you. It's your application. Note, though, that
any objects you get from the Window-Eyes object model are apartment
threaded. That means that you have to call them from the thread you
created them on. Calls from other threads will fail unless you
explicitly marshal them to the other thread yourself (or unless your
language of choice somehow abstracts that distinction away; I'm not sure
what the CLR does with apartment-threaded COM objects.)
You didn't specifically ask about internal scripts, but for the sake of
completeness: each internal script runs in its own thread, with its own
instance of the appropriate interpreter. The only interactions between
scripts are through shared objects or through their effects on the real
world as documented above.
By the way, the reason you pass the process ID to WE when you start up
(using ClientIdentify) has nothing to do with filtering windows or
messages. It's so WE can make the connection between the process it
started and the WindowEyes.Application object that process created.
Without that connection, WE wouldn't know who you are, so it wouldn't
know who to give the OnShutdown event and other ClientInformation
properties to.
On 4/19/2012 5:31 AM, RicksPlace wrote:
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
