[jawsscripts] Re: The order of file scanning in JAWS scripting

  • From: Doug Lee <doug.lee@xxxxxxxxxxxxxxxx>
  • To: <jawsscripts@xxxxxxxxxxxxx>
  • Date: Sat, 27 Feb 2016 07:23:28 -0500

My use of "park" just meant"place." :)

And yes, JAWS looks in the shared folder's Outlook.jkm for key assignments not 
found in the user folder one.
So if you type Ctrl+Shift+I, JAWS will look in the user jkm, then if it finds 
no ctrl+shift+i entry there, in
the shared jkm.

On Sat, Feb 27, 2016 at 09:05:22PM +1100, Paul Magill wrote:
Hi Doug,

I'm not understanding your  explanation about the .JKM files.

I have added a few scripts to Outlook 2010 in my Outlook 2010.jss in the
user folder.   I use the use "Outlook 2010.JSB" statement to maintain access
to the normal FS Outlook 2010 scripts.

There are only a few scripts in my Outlook 2010.JSS, and in my Outlook
2010.JKM file in the user folder, there are only the keystrokes for these
few scripts.

I can use all the normal FS scripts, such as reading an email's headers.

Therefore, with my limited understanding, JAWS must be calling up the "use"
list to the FS Outlook 2010.JKM in the shared folder, to invoke the FS
scripts.

Would you mind explaining  what I have missed please.

Also, what does park mean in:
This is why you have to park key assignments in MyApp.jkm...

Thank you for such a full coverage of this topic!

Regards,
Paul from Australia

-----Original Message-----
From: jawsscripts-bounce@xxxxxxxxxxxxx
[mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Doug Lee

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 __________o?=

View the list's information and change your settings at
//www.freelists.org/list/jawsscripts

__________???

View the list's information and change your settings at 
//www.freelists.org/list/jawsscripts

-- 
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

Other related posts: