Great points again, Jamal The FS script editor needs some improvements, but it is much easier than text-editing scripting. I'd like to see an enhanced script editor, such as bookmarks, point-to-point copy/cut/paste, integrated FS SDK when F1 is pressed on a function name, enhanced documentation with examples of function uses, trace functionality to track function execution, and jsb files included with a "use" statement have their functions accessible in the function list when the user hits Control+L to list the functions or inserts a function. Your text editor, TextPal, adapted to the script manager would be a nice start! Thanks, Dennis Brown ----- Original Message ----- From: "Jamal Mazrui" <empower@xxxxxxxxx> To: <jawsscripts@xxxxxxxxxxxxx> Sent: Monday, August 04, 2008 12:17 PM Subject: [jawsscripts] Re: advantages of object oriented over procedural API, plus Gw Fs Scripting methodology question. > Hi Geoff, > The Window-Eyes API is object oriented in the manner of COM, > e.g., like the Microsoft Word, Excel, Outlook, or Internet Explorer object > models. COM is not a complete OO approach, e.g., classes are not > inheritable, but it does make coding easier because related elements are > grouped together such as the properties, methods, and events of an object. > Compared to the OO of COM, I think a procedural API can generally do the > same things by passing a handle to an object as the first parameter of a > method. So, the OO nature of the WE APIis not so much an advantage > technically as with the organization it brings, which helps in > distinguishing concepts, seperating namespaces, and remembering syntax, > since OO consciously uses similar names for similar methods or properties > of different objects (polymorphism). For anyone familiar with the Word or > IE object models, imagine if there was no hierarchy of objects, but just a > long list of methods for the whole API -- it would be more difficult to > work with! > > Regarding advantages of the JAWS API, it does have a type of inheritance > of script and function names, whereby an application can redefine a > routine with the same name, and then choose to call the default version or > not (actually, the next version with the same name that is up a level in > the hierarchy). WinEyes does not have this. JAWS functions can have > optional parameters, which VBScript (the most common WinEyes scripting > language) functions cannot. JAWS offers an integrated development > environment via Script Manager, whereas WinEyes requires an editor that is > not customized to WinEyes scripting. In my opinion, this is the most > significant advantage that JAWS scripting still has over WinEyes > scripting. > > Addressing some points others have raised, VBScript is more of an open > source language than the JAWS scripting language, which is truly > proprietary (only FS uses it). VBScript is freely available and can be > run by various hosts including the Windows Script Host, Internet Explorer, > and Microsoft Outlook. One will find many more free tutorials and > examples on the web that use VBScript compared to JAWS script. Although a > WinEyes script can be encoded, none of the 80 or so currently available on > the GW web site, including ones developed by the company, are encoded. > Its source code is released under a BSD license. It is unclear what > license FS intends for its scripts, but given its propensity to litigate, > I doubt it is the permissive BSD license (freely modify the code as long > as the original source is acknowledged but not used to promote the > modified version). > > The WinEyes scripting engine hosts two languages internally, just like the > Windows Script Host: VBScript and JScript. I think the WinEyes security > model is clearly stronger than the JAWS one. A user can decide not to > permit any script to run that has not ben explicitly allowed in advance. > > Feel free to ask further questions. I welcome other opinions as > well. I do prefer the JAWS keyboard interface, so have developed a > WinEyes script package called Homer Layout to emulate most JAWS keys, > while also incorporating functionality unique to WinEyes. > > Regards, > Jamal > > On Mon, 4 Aug 2008, Geoff Chapman wrote: > >> Date: Mon, 4 Aug 2008 02:44:28 +1000 >> From: Geoff Chapman <gch@xxxxxxxxxxxxxxxx> >> Reply-To: jawsscripts@xxxxxxxxxxxxx >> To: jawsscripts@xxxxxxxxxxxxx >> Subject: [jawsscripts] advantages of object oriented over procedural API, >> plus Gw Fs Scripting methodology question. >> >> Regarding Jamal's post of last week concerning some of the advantages he >> currently saw and listed >> with the current window eyes Scripting implementation over the Fs current >> offering, I have a question from another scripter not onlist to ask here, >> plus one of my own. >> First my friend's question: >> >> Aside from just being yet another way to think about the >> problem at hand, what is the true advantage of object-oriented approaches >> in this environment? In other words, what can you do in an >> object-oriented system, that you can not do procedurally. >> >> And, now for my question: >> >> Jamal, once again thinking of both scripting approaches as you know them, >> and as they stand right now, would you care to comment as to whether, in >> your view, the scripting model that fs has in place with jaws right now, >> holds, any, current pluses/a dvantages at all right now, either of >> tightness of integration or procedurally, >> over the current gw model? >> with all it's caveats? >> Thanks very much. >> >> geoff c. >> >> >> >> __________ >> 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 > > __________ View the list's information and change your settings at //www.freelists.org/list/jawsscripts