JSS files:
These are the most complicated to explain because of Use statements. For a
script file called MyApp.jss, here's the order of things that happen:
For a script or an event (other than autoStartEvent) that JAWS calls, JAWS runs
the first one of these that exists:
- The one in MyApp.jss.
- The one in the file loaded by the last Use statement in MyApp.jss.
- The one in the next-to-last Use statement in MyApp.jss, and so on up through
the first Use statement.
- The one in default.jss.
- The one in the last Use statement in default.jss, and so on.
- The one built into jfw.exe.
This is why it is important to call an event again from the end of itself when
you override it, in most cases. When you don't, the default JAWS behavior for
that event never happens. This is also often important for script overrides.
JSD files:
For keyboard help, and I believe for things like the function list in the JAWS
Script Manager, JAWS consults the following files in this order, retrieving the
first entry for each script or function found:
- MyApp.jsd.
- The jsd files for Use lines in MyApp.jsd. (I never verified the order for
these.)
- default.jsd.
- The jsd files for Use statements in default.jsd.
- Builtin.jsd.
JKM files:
The order for jkm files is similar, but there are two sections read from these
files: the one for the active keyboard layout (e.g., Desktop or Laptop), and
Common Keys. I have not verified whether JAWS reads all the specific layout
sections and then all the Common Keys sections, or instead, reads specific
layout and Common Keys from the first file, then the second, etc. Be that as it
may, here's the file order - and notice it is shorter:
- MyApp.jkm.
- default.jkm.
That's it! No jkm files corresponding to Use lines anywhere. This is why you
have to park key assignments in MyApp.jkm regardless of whether the script
attached is in MyApp.jss or in something it loads.
Miscellaneous files:
I believe the pattern for jgf, jdf, jff/jfd, etc. files is identical to that
for jkm files, though I have not rigorously proven this.
A complex example:
Imagine MyApp.jss contains these lines (at least):
use "util1.jsb"
use "util2.jsb"
script SayWindowTitle()
sayString("Here comes the title")
performScript sayWindowTitle()
endScript
util1.jss contains this:
script sayWindowTitle()
sayString("Just a moment")
performScript sayWindowTitle()
endScript
and there are no Insert+T or JAWSKey+T entries in MyApp.jkm.
The user types Insert+T. Here's what happens:
- JAWS looks for an entry for Insert+T in MyApp.jkm and does not find one.
- JAWS looks in default.jkm and finds an entry saying that Insert+T should
execute a SayWindowTitle script. The search begins for that script.- JAWS looks
in MyApp.jss and finds a SayWindowTitle script, and runs it. This makes JAWS
say, "Here comes the title."
- JAWS runs the performScript sayWindowTitle() line in the MyApp.jss version of
the SayWindowTitle script. This causes a new search for a SayWindowTitle script
that starts just after the current file.
- JAWS looks in util2.jsb for a SayWindowTitle script but finds none.
- JAWS looks in util1.jsb for a SayWindowTitle script, finds one, and runs it.
JAWS therefore says, "Just a moment."
- JAWS now finds and runs the performScript sayWindowTitle line in the
util1.jss version of SayWindowTitle. This causes yet another search, this time
starting after util1 in the file chain.
- JAWS looks in default.jsb for a SayWindowTitle script, finds it, and runs it.
This causes the normal title announcement to occur.
The rare script command explanation:
Continuing with our MyApp example that loads util1 and util2 jss files, imagine
that util1 contains a function with this signature:
string function getScreenSummary()
Also imagine that util2.jss calls that function thus:
sayMessage(OT_Message, getScreenSummary())
That's legal because MyApp makes sure both util1 and util2 are loaded. However,
when JAWS is compiling util2.jss, it has no way to know to check util1.jsd for
function declarations. Because of this, when it encounters the SayMessage call
containing the getScreenSummary call, JAWS tries to assume getScreenSummary()
returns an int. It then discovers that SayMessage's second parameter must be a
string. This results in a compiler error.
The solution to this situation is to add the line
import "util1.jsd"
to util2.jss. That makes JAWS scan util1.jsd even though it otherwise wouldn't.
This is a compile-time change, not a runtime one; JAWS will already scan
util1.jsd for keyboard help because MyApp.jss loads util1.jsb with a Use
statement.
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
__________�
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
