Thanks Jamal for your quick response. So in terms of getting it resolved, what information please do you think I should pass to freedom scientific in order to get the problem resolved? As I say it is quite important to us so am quite happy to communicate with them. Thank you again. On 22/11/2012, at 4:08 PM, Jamal Mazrui <empower@xxxxxxxxx> wrote: > That explanation makes sense to me. Since it is a method of a Windows > COM server that is actually writing the string to disk, I think the > fault lies in the string that is passed to it as a parameter by JAWS. > > Jamal > > On 11/22/2012 10:53 AM, Andrew Hart wrote: >> Yep. that's a curly one and I am not sure what's going on. glancing at >> the source of StringToFile in homer.jss, everything looks hunky dory. >> >> I initially thought that perhaps the + operator was plonking a space >> char on the end of the string, but a little testing invalidated this >> hypothesis. Plus, I would have thought a bunch of other stuff would >> have already been broken in JAWS if this were the case. >> >> I did a test in V14 (not in 13 yet) along the lines of what you >> suggested and found an extra character at the end of the file, just like >> you reported. Brian, the extra character is not a space (ASCII code 32 >> or 0x20 hex); it is a 0 byte (ASCII 0 or 0x0 hex), which is normally >> used to terminate raw strings in C/C++ code. When I load the test file >> into Notepad, the extra character appears as a space because Notepad >> converts non-printable characters to spaces when it opens files. >> >> Now, in order to pass the string to a COM object, it mus tbe converted >> to a Variant variable type and then to a BSTR object which complies with >> the COM standard for module interoperability. My initial reaction, >> though I could be totally off the mark here, is that JAWS 14 is >> miscalculating the string length and inadvertently including the >> terminator character at some point in the process of passing the string >> to the COM object. >> Some further testing would be required to really confirm this. >> >> Hth, >> Andrew. >> >> On 22/11/2012 11:40 AM, Brian Hartgen wrote: >>> Hi >>> I have a problem which is baffling me at the moment. For various projects >>> available to the community, I use Jamal's Homer Script Library. It is full >>> of useful functions and I've used it for years. >>> >>> However there is one function which is causing a problem. It works fine >>> with many jaws versions up to and including 13, but it does not work >>> correctly in 14 and I do need it to if anyone can please suggest a solution. >>> >>> The function, StringToFile, writes a string to a text file. In jaws 14, >>> this is working fine except that it leaves an extra space character at the >>> end. This can be simulated simply as follows: >>> >>> Assume that homer.jsb is attached via a use statement to your script. >>> >>> Script test700 () >>> >>> saystring ("ok") >>> >>> var >>> >>> string temp >>> >>> let temp = "hello " >>> >>> let temp = temp +"goodbye" >>> >>> StringToFile (temp, "c:\\temp\\test.txt") >>> >>> ã >>> >>> ã >>> >>> EndScript >>> >>> >>> This outputs to a text file "hello goodbye", then a space character, rather >>> than just having a clean file. >>> >>> Does anyone have a suggestion as to how I may erase the space character? >>> >>> Thank you. >>> >>> Brian Hartgen >>> >>> __________ï >>> >>> View the list's information and change your settings at >>> http://www.freelists.org/list/jawsscripts >> >> __________ï >> >> View the list's information and change your settings at >> http://www.freelists.org/list/jawsscripts > > __________ï > > View the list's information and change your settings at > http://www.freelists.org/list/jawsscripts > __________ï View the list's information and change your settings at http://www.freelists.org/list/jawsscripts