This and the previous message from you confuse me a bit. The "<" was from a diff program. It was not meant to be part of my code at all. On Thu, Nov 21, 2013 at 12:25:22PM -0700, John Martyn wrote: I just figured it out. The < sign is much like the period in PHP when you want a carriage return but don't want to break functionality. What is the > sign for then? John -----Original Message----- From: jawsscripts-bounce@xxxxxxxxxxxxx [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Doug Lee Sent: Thursday, November 21, 2013 9:28 AM To: jawsscripts@xxxxxxxxxxxxx Subject: [jawsscripts] One of my wilder debugging discoveries This just seems worth writing down for its oddity... I was debugging a 23,000-line script this morning. Recently I started getting really strange behavior when trying to assign collections to variables in part of the code: I started getting the integer 1 in place of a collection, with no obvious reason. I tried myriad solutions and debugging tricks, sayString/sayInteger lines, etc. Then I added a sayInteger at a particular point in the code, and presto, the thing started working! "How strange," I thought, "that shouldn't affect anything, it's not making an assignment..." So I took the new line out, and the odd wrong behavior resumed. On reading more carefully, I found that the next line after the sayInteger I had put in began with a spurious less-than sign (<). Apparently I had mistakenly copied that line out of a diff output file, in which less-than signs indicate removed lines and greater-than signs indicate added ones. I should mention here two things: I read with punctuation off, and in my actual code files, which are sometimes something like templates, I use a double less-than to indicate a translatable symbol; so I am accustomed to ignoreing less-than signs as I read anyway. The previous line in the file was an assignment like cLocation = locations[index] in other words, an assignment from an array to a collection variable. The line after that was a plain old function call, we'll say MyFunc(). So the code before my sayInteger was added looked like cLocation = locations[index] < myFunc() The JAWS script compiler treats end-of-line no different than a space most of the time, so it read the above two lines like cLocation = locations[index] < myFunc() which actually means, assign to cLocations the integer (boolean) value of the question, is locations[index] less than the return value of myFunc()? It so happens that myFunc() returns True, which as an integer is 1. I guess the integer value of the collection at locations[index] was 0, so the above question's result was True, which is also a 1 when taken as an integer. This is how cLocation was getting set to 1 instead of a collection. Now, when I put the sayInteger call in, why did I get a different result? The code would then look like cLocation = locations[index] sayInteger(...) < myFunc() Now the spurious less-than sign doesn't affect the assignment. JAWS will actually make the comparison sayInteger(...) < myFunc() but then discard it because it's not being assigned to anything. This had the net effect of making my cLocation assignment work again. And they wonder why it is said we'll spend 90% of our time debugging. :-) -- 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 http://www.freelists.org/list/jawsscripts __________??? View the list's information and change your settings at http://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 http://www.freelists.org/list/jawsscripts