For me the issue is simpler, and the choice easier. I have helped develop, and continue to maintain thousands of lines of Jaws scripts for myself and others where I work. While these contain some Object Oriented features, it is nearly all ordinary scripting. The reason for this, is that I fall short of the skill, knowledge or whatever it takes to fully grasp the object oriented approach. The object oriented features that I have used, I borrowed directly from what Jamal, Doug and others have released on this list, or published on web sites. For their generosity in releasing that source code, and so much other useful information, I am ever grateful, as it is clear that much can be achieved with objects, even if I cant come up with the design & code myself. Because of this, even if the WE approach were perfect , I would continue with Jaws scripting, as I am able to understand & use enough of it to remain competitive at work. From what I have read, the WE approach has some appeal for programmers, but I think there may be others on this list, who, like me, are able to write reasonably useful Jaws scripts, but are definetly not programmers. If FS is considering moving toward a more object oriented approach, I implore them to also continue with the current methods, for the benefit of the non programmers amongst us. Regards, Paul from Aust. ----- Original Message ----- From: "Doug Lee" <doug.lee@xxxxxxxxxxxxxxxx> I agree with Victor that the lack of standard data structure support in JAWS scripting is a hassle. I don't understand the comment about VBScript not promoting open source access to assistive technology though. Not only are the VBScript scripts so far written presented in source form, but VBScript is only one choice of several at the disposal of scripters for Window-Eyes. This openness may eventually present its own problems, at least in some highly security-conscious environments; but I don't see how that language support decision is at all source-restrictive. As for why object-orientedness could be an advantage to scripters: A huge problem I've always seen in JAWS scripting is the lack of isolation of code for one problem from code for another. Build up a set of scripts to address 15 issues without containing the code for each unto itself, and you end up with a mess that's hard to maintain. This is largely why I started writing code in jsl files, though I'm sure not all souls out there appreciate the number of files for one scripting solution this causes me to produce occasionally. Some of my jsl files really are sort of like objects though. In an object-oriented language, I would not have had to create my own means of isolating things--special namespace prefixes, rules on variable and function names, irregularly polymorphic use of function parameters, etc. Besides this though, the jsl method remains quite limited compared to real objects because it is much harder to extend a jsl without rewriting it than to extend a class, at least in a better language than VBScript (and *that* is one of my biggest issues with VBScript, that you can't properly inherit from a class!). In JAWS, you can actually implement even more object-orientation simulation by using jsb files and Use commands than by using jsl files and Include commands, but I mostly avoid that to avoid the runtime performance hit of loading a fleet of jsb files on every Alt+Tab. And finally, what the JAWS language might have over the GW offering: For security-conscious people, such as on-site IT personnel at various sites I've visited, I think the fact that the JAWS scripts run within JAWS itself is a comfort. JAWS scripts don't look and act like application programs nearly as much as I expect GW scripts will do in their eyes. Whether this is actually a substantive advantage remains to be seen. I can't be sure what other pros JAWS' approach may offer over the GW approach because I know the JAWS environment better than the GW environment. __________ View the list's information and change your settings at //www.freelists.org/list/jawsscripts