I may be mistaken about this, and if so, hope for clarification.
My understanding is that a .we file is a file in ini format that
specifies metadata related to a WE configuration for an app, which may
include a .set file, script file, or both. A .set file may include
related dictionary or label files.
The .we file metadata includes the nature of the association mechanism
with an application. I think, but am not sure, that the association may
be based on an executable file name, an active window title, or an
active window class name -- or perhaps a combination thereof.
I forget what the default association type is when creating one via the
WE user interface.
When an associated application is noticed by Window-Eyes, it activates
the related set file and/or runs the related script file.
Jamal
On 5/5/2012 5:12 PM, Chip Orange wrote:
Rick,
I too would like to see GW document this (how programs are associated
with .we files, the format of the .we files commands, and how .we
files in turn are related to .set files and scripts files, causing
them to be loaded or launched). If we're starting from scratch to
make a program accessible, and if there isn't a .we file already
existing, then I don't see how we're supposed to be able to create and
turn out a working app without such knowledge.
My guesswork tells me that the .exe file is first used to load any .we
file with the same base name; in the .we file are commands which load
.set files for the .exe based on module names and/or window titles
and/or window class names.
If it happens that VS 2010 has a different .exe file which runs from
that of VS2008, then I'd guess you could create a .we file for 2010
which would just run your app; however if as is usually the case the
.exe file names are the same, then I've never seen any example of
anything which controls which scripts are started based on anything
other than the .exe file name, so I think you are stuck with having to
figure out if your script should not be running, and shutting itself
down. This is something you would have to figure out how to do
anyway, just to be able to respond to the onShutdown event, so it's
not really so bad; it may however confuse you by causing entries shown
by app manager for copies of your app which show a status of "stopped"
(you can see examples of this with the IE enhanced app, which ends up
with the same issue of having to stop some copies from running, and so
you can see the result of this in the app manager). This might cause
you to think your application.exit didn't work. (I am assuming
external apps work the same way in app manager as hosted VBScript apps
when they "stop").
So, when you see your app in the list in app manager, be sure and pay
attention to the status shown.
hth,
Chip
------------------------------------------------------------------------
*From:* RicksPlace [mailto:[email protected]]
*Sent:* Thursday, May 03, 2012 9:58 AM
*To:* [email protected]
*Subject:* What Does WE Use To Associate A External Script with a
Program
Hi;
I build a script in vb.net 2008 express to make vb.net 2010
Express accessible:
I open vb.net 2010 Express and the script works to a point but...
The script is also assigned to vb.net 2008 Express which causes
problems.
So my script is Associated with both VB.net 2010 Express -
correctly but also Associated with VB.net 2008 Express - incorrectly.
Unloading it while VB.net 2008 Express is active will Unload it
for VB.net 2010 Express as well.
What or how does WE associate a Script With an Application?
Can I override it or do anything to associate the vb.net 2010
script soley with the vb.net 2010 Application?
Note that I am not running the vb.net 2008 version while I try and
run the vb.net 2010 version so the executable in the 2008 version
will not be tied up nor will, should, there be a duplicate set of
processes running for both 2008 and 2010.
Rick USA
