Hi Joseph, Many thanks to you and Alex for trying to help me solve this problem. I've been doing a few experiments and I'll report the results below, as I'd love to know if this problem is with my Apex, my brain, or a lethal combination of both! I'm posting this on list in case Alex or any other techies can chime in, but I apologize to other list members and hope the "delete" key doesn't prove too elusive. Here goes:
When I tested the dot assignment process yesterday, I received the exception command immediately after pressing space with D, the keystroke that initiates the dot assignment procedure. When you told me that your test had been successful, I thought this may have something to do with the computer Braille table that I was using at the time. I was using one called Czech USA, which I had renamed from Custom USA some time ago. I tried switching to the "Custom USA" table, with the same lack of success. I then moved the Custom USA table out of the Dictionaries folder on the flash disk and selected the "USA" table, in order to generate a new Custom USA table once the first dot combination had been assigned. I then opened a Word document and repeated the test with the "o stroke" character. This time, when I pressed space with D, I received the standard message that I would have expected: "O stroke displays as nothing. Option?" I pressed "A" to assign a combination, then I followed your example and typed dots 1-3-5-8 on the Braille keyboard. The cursor simply moved one space to the right, and the speech said, "character 149". I then tried another dot combination, dots 2-4-6-8. Again, the cursor moved one space to the right without anything being displayed, and this time the speech said, "superscript A". I can repeat the process using other unicode characters and other dot combinations, but the results are the same, except that the speech names a different character with each new dot combination. I then tried to assign a key combination to our friend O stroke, by pressing space with K, followed by "A" for "assign". I was able to assign the key combination successfully using space with U, followed by dots 1-3-5-8. I was subsequently able to enter the character in my Word file, and this operation also generated a new "custom USA" Braille table. When I was still in the Word file, I then repeated the dot combination assignment for O stroke, using space with D, then "A", then dots 1-3-5-8. This time, once the Custom USA table had been created as described previously, I received the same behaviour as I did yesterday when I was using the Czech USA computer table, i.e. I got the exception command immediately after pressing space with D. There is just one more anomaly that I should mention, and this hasn't been rectified in Keysoft 9.1 either: If I'm using any Braille table other than just plain USA or Uk, text is only displayed in 8 dot computer Braille, regardless of whether I have it set to 6 or 8 dot, either from within Braille options or by using the "Next and Advanced thumb-key" shortcut. As for resets, before writing to the list yesterday I tried a resets using both a short and a long press of the button, but to no avail. If you are unable to emulate any of this behaviour and the problem is with my own Apex, are there any other resets that I should try? Thanks so much for your time and patience, and I apologize if all this is user error on my part. On the Classic and mPower I was able to rename computer Braille tables and continue to assign dot and key combinations with no problem, so I have a fair amount of experience with the process. Fortunately I still have the Classic, so I can copy the table into the Dictionaries folder, edit it as necessary and use it to replace the version of that table in the Apex. Nicky ----- Original Message ----- From: "Joseph Lee" <[email protected]> To: "Nicola Sanders (Telenet)" <[email protected]>; <[email protected]> Sent: Monday, February 14, 2011 8:23 PM Subject: re: [Braillenote] Unicode characters: Assigning dot combinations stillbroken in Keysoft 9.1 > Hi Nicola, > An interesting behavior. For testing, I was able to assign o > stroke to DOTS 1-3-5-8 - with no problems. I'm using 8 dot > computer braille. > The "exception" message sounds like a memory confusion on behalf > of Apex. The phrase "access violation reading 0" means that > KeySoft was trying to read from so-called "NULL" pointer/value - > an undefined location on memory. As Alex suggested, try > reassigning the key combinations after reset. > Cheers, > Joseph > > ----- Original Message ----- > From: "Nicola Sanders \(Telenet\)" <[email protected] > To: "Braillenote List" <[email protected] > Date sent: Mon, 14 Feb 2011 17:49:56 +0100 > Subject: [Braillenote] Unicode characters: Assigning dot > combinations stillbroken in Keysoft 9.1 > > Hi all, > > Despite what Humanware claims in the release notes for Keysoft > 9.1, there are still problems with the assignment of dot > combinations to certain unicode characters on the Apex BT. For > example, when I tried assigning a dot combination to the > character "o stroke", I received the following error message: > "Exception command: 404 at 3595. Access violation reading 0" > > I sent a detailed message to Humanware about this problem after > the release of the Apex, and I was unable to trade in my Classic > because of it, since as a linguist I just can't afford to > relinquish this option. I was optimistic that it might have been > resolved by now, but alas, 'tis not to be, and my Classic lives > to fight another day!! I haven't had time for detailed tests, > but there may well be problems with key assignments as well as > dot assignments in some circumstances. I don't mean to sound > arrogant, but I can't help wishing that Humanware would have > these so-called "fixes" tested by users who have plenty of > experience with the bugs in question and may just conceivably > know what they're talking about, before releasing an upgrade > which turns out not to have solved the problems. > > OK, rant over! If anyone can shed any light on the meaning of > the error message, I'd appreciate it. > > Best, > > Nicky > > > __________ Information from ESET Smart Security, version of virus > signature database 5873 (20110214) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > > ___ > Replies to this message will go directly to the sender. > If your reply would be useful to the list, please send a > copy to the list as well. > > To leave the BrailleNote list, send a blank message to > [email protected] > To view the list archives or change your preferences, visit > http://list.humanware.com/mailman/listinfo/braillenote > > > __________ Information from ESET Smart Security, version of virus signature > database 5874 (20110214) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > __________ Information from ESET Smart Security, version of virus signature database 5875 (20110215) __________ The message was checked by ESET Smart Security. http://www.eset.com ___ Replies to this message will go directly to the sender. If your reply would be useful to the list, please send a copy to the list as well. To leave the BrailleNote list, send a blank message to [email protected] To view the list archives or change your preferences, visit http://list.humanware.com/mailman/listinfo/braillenote
