[jawsscripts] Re: Another public beta of JAWS Script Exchange 2.0

My only concern is that there appears to be a loop hole for data loss, this 
area being for anything below the dummy function. For instance, if the user 
were to add their own Use statement, but instead of adding this at the top 
of the page, they added it to the bottom instead. Also, if the user were to 
add their own function or script to this default.jss file at a later date, 
it too would be broken if this code is not included in the merge.
If there was a way to keep all of the current dummy jss content and add the 
new Use statement without the risk of any data loss, the whole process would 
be continually seamless. Sorry if I wasn't too clear earlier.

----- Original Message ----- 
From: "Jamal Mazrui" <empower@xxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Monday, February 23, 2009 9:48 AM
Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange 2.0


> Are you talking about a container type of .jss file?  By this, I mean
> one with no significant code of its own -- basically, a list of Use
> statements followed by a dummy function.  If JSX finds a dummy function
> with the conventional name, it does recognize references to the .jsb
> that is about to be merged, and does not duplicate such a reference.
>
> I want to better understand what you are hoping to achieve.  Is the a
> problem with organizing a .jss so that it follows the JSX conventions for
> a container.jss file?
>
> Jamal
> On Mon, 23 Feb 2009, Bryan Garaventa wrote:
>
>> Date: Mon, 23 Feb 2009 09:38:06 -0800
>> From: Bryan Garaventa <bgaraventa11@xxxxxxxxxxxxxx>
>> Reply-To: jawsscripts@xxxxxxxxxxxxx
>> To: jawsscripts@xxxxxxxxxxxxx
>> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange 
>> 2.0
>>
>> No problem,
>>
>> Is it possible to use a Find String command to see if the currently 
>> merged
>> Use statement is already present in the default.jss file?
>>
>> If Void Function _Filler() was not detected at this time, then the new
>> default.jss file could be generated as it currently is.
>>
>> If the Void Function _Filler() is found though, but the new Use statement 
>> is
>> not, then the new Use statement could be prepended to the top of the
>> complete default.jss file and compiled.
>>
>> If it were done in such a way, you would never have to be concerned about
>> any data loss, even if the user wrote their own functions and added these 
>> to
>> the new default.jss file. It would just keep on working regardless, no
>> matter how many times the same installer, or different installers for
>> different scripts were used.
>>
>> Do you think this might be possible?
>>
>>
>> ----- Original Message -----
>> From: "Jamal Mazrui" <empower@xxxxxxxxx>
>> To: <jawsscripts@xxxxxxxxxxxxx>
>> Sent: Monday, February 23, 2009 7:23 AM
>> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange 
>> 2.0
>>
>>
>> > Thanks for your feedback, Bryan, as I want to finalize this version of
>> > JSX.  It should treat default.jss as you intend if it contains a dummy
>> > function with a particular naming convention for this purpose, which I
>> > recall adoptingg from Doug Lee.  If JSX finds the following line in a 
>> > .jss
>> > merge target:
>> >
>> > Void Function _Filler()
>> >
>> > it assumes the .jss is a container file with Use statements above that
>> > dummy function, and nothing significant afterward.  If that does not 
>> > work,
>> > let me know.
>> >
>> > Jamal
>> > On Sat, 21 Feb 2009, Bryan Garaventa wrote:
>> >
>> >> Date: Sat, 21 Feb 2009 21:35:14 -0800
>> >> From: Bryan Garaventa <bgaraventa11@xxxxxxxxxxxxxx>
>> >> Reply-To: jawsscripts@xxxxxxxxxxxxx
>> >> To: jawsscripts@xxxxxxxxxxxxx
>> >> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange
>> >> 2.0
>> >>
>> >> Hi Jamal, I was finally able to try out the new version, and it's 
>> >> working
>> >> much better than it used to. Excellent!
>> >>
>> >> Only one thing though, is there any way to make the string parser 
>> >> detect
>> >> pre-existing use statements within the default.jss file as well? For
>> >> instance, I use a lot of internal use statements for projects I 
>> >> develop
>> >> at
>> >> different times, and I always use the use statement to reference these
>> >> script sets during development. Plus some of my scripts depend on the
>> >> addition of the use statement, such as the online chat page scripts at
>> >> http://gutterstar.net/dynamic_live_chat.php
>> >> So the static use of specific use statements within the installer 
>> >> can't
>> >> always be relied upon to keep these custom use statements as well.
>> >>
>> >> I'm unfamiliar with the programming language used for this purpose 
>> >> within
>> >> the installer, but would it be possible to parse the string content 
>> >> line
>> >> by
>> >> line for default.jss, and save or copy all of the statements beginning
>> >> with
>> >> Use for inclusion within the new Default.jss output file? Please 
>> >> forgive
>> >> my
>> >> ignorance if this is more complicated than I understand. This really 
>> >> is a
>> >> great product, and you've done a great job.
>> >>
>> >>  Best wishes,
>> >>
>> >> Bryan
>> >>
>> >> ----- Original Message -----
>> >> From: "Jamal Mazrui" <empower@xxxxxxxxx>
>> >> To: <jawsscripts@xxxxxxxxxxxxx>
>> >> Sent: Monday, February 16, 2009 8:23 AM
>> >> Subject: [jawsscripts] Another public beta of JAWS Script Exchange 2.0
>> >>
>> >>
>> >> > http://EmpowermentZone.com/jsxsetup.exe
>> >> >
>> >> > This version enhances merge support, and bundles optional script 
>> >> > sets.
>> >> > The JSX installer engine now recognizes an existing container.jss 
>> >> > file
>> >> > that it previously created, a script file containing a set of Use
>> >> > statements followed by a dummy function to satisfy the JAWS script
>> >> > compiler.  A merge operation incorporates the components referenced 
>> >> > in
>> >> > such a file.
>> >> >
>> >> > At the end of the installation process for the complete JSX 
>> >> > application
>> >> > (using the above URL), three script sets are offerred.  These 
>> >> > options
>> >> > are
>> >> > unchecked by default.  You can check one ore more of them to install
>> >> > their
>> >> > zip archives with JSX.. i.e.,
>> >> >
>> >> > BX, the Jaws toolbox by Doug Lee (BSD license)
>> >> >
>> >> > HomerKit, the Homer script library and editor interface by Jamal 
>> >> > Mazrui
>> >> > (LGPL license)
>> >> >
>> >> > Visual Studio scripts by contributors from the blind programming
>> >> > community
>> >> > (public domain)
>> >> >
>> >> > Jamal
>> >> >
>> >> > __________
>> >> > Visit and contribute to The JAWS Script Repository
>> >> > http://jawsscripts.com
>> >> >
>> >> > View the list's information and change your settings at
>> >> > http://www.freelists.org/list/jawsscripts
>> >> >
>> >> >
>> >> > _______________________________________
>> >> > No viruses found in this incoming message
>> >> > Scanned by iolo AntiVirus 1.5.6.3
>> >> > http://www.iolo.com
>> >> >
>> >>
>> >> __________
>> >> Visit and contribute to The JAWS Script Repository 
>> >> http://jawsscripts.com
>> >>
>> >> View the list's information and change your settings at
>> >> http://www.freelists.org/list/jawsscripts
>> >>
>> > __________
>> > Visit and contribute to The JAWS Script Repository 
>> > http://jawsscripts.com
>> >
>> > View the list's information and change your settings at
>> > http://www.freelists.org/list/jawsscripts
>> >
>>
>> __________
>> Visit and contribute to The JAWS Script Repository http://jawsscripts.com
>>
>> View the list's information and change your settings at
>> http://www.freelists.org/list/jawsscripts
>>
> __________
> Visit and contribute to The JAWS Script Repository http://jawsscripts.com
>
> View the list's information and change your settings at
> http://www.freelists.org/list/jawsscripts
> 

__________ 
Visit and contribute to The JAWS Script Repository http://jawsscripts.com

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

Other related posts: