RE: Ed-sharp bug report
- From: "Sina Bahram" <sbahram@xxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Sun, 5 Dec 2010 23:48:34 -0500
I haven't run that, but of course that would work; however, why is there a
reason for that unless if the autostart event is
overwritten and doesn't call the parent? If it does, then that line gets
executed from default.jss, or at least it better be, and if
it doesn't, then the solution would be to actually simply call the parent, once
you're done.
Take care,
Sina
-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Littlefield, Tyler
Sent: Sunday, December 05, 2010 5:38 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Ed-sharp bug report
Sina:
Does this solve the problem?
Add:
SayString(GetAppTitle ())
to
the top or bottom of AutoStartEvent?
That's not a jaws issue, that's an edsharp thing. it would read the title as
you alt+tab, but not when you hit alt.
On 12/5/2010 3:10 PM, Jamal Mazrui wrote:
> I meant to also address the Alt+Tab issue. I do recall some .NET
> programs not announcing their title as consistently when Alt+Tab is
> pressed. I just tried with JAWS 10 and Windows Vista, however, and
> found that the EdSharp window title was announced when cycling among
> active windows with this keystroke. I wonder if this is related to
> the combination of JAWS and Windows versions. I invite feedback on
> this from other users of JAWS or different screen readers, in the hope
> that we can identify a pattern.
> Jamal
>
> On 12/5/2010 5:04 PM, Jamal Mazrui wrote:
>> Excellent feedback -- thanks, Sina! I appreciate your taking the time
>> to write with specific observations and ideas. I have saved your
>> message for further review. Let me respond initially as follows.
>>
>> Indeed, the EdSharp installer does not currently ask whether to
>> install a destop shortcut. The choice is only whether to add a
>> system-wide hotkey to that shortcut of Alt+Control+E. Unfortunately,
>> I have not found a way to make that happen on every Windows version,
>> seemingly for security-related reasons. So, even if I accept the
>> default hotkey on Windows Vista, it will not actually be enabled
>> until I press Alt+Enter on the desktop to edit its properties, and
>> instruct the shortcut to run as administrator. The hotkey is not part
>> of the Start Menu shortcut. The reasoning is that it is minimal cost,
>> except for one item in a list, to add the shortcut to the list of
>> desktop or Sart Menu items, but the hotkey should be confirmed so
>> that it does not risk replacing an existing global hotkey. There is
>> no use of the Quick Launch bar by the installer.
>>
>> Neither EdSharp, via the JAWS API, nor the JAWS scripts for EdSharp,
>> intervene in menu processing in ways that could explain the delays
>> you experience, as far as I know. Sorry, but I do not know the cause,
>> other than JAWS processing of .NET menus (which are not Win32 menus).
>> What Windows version are you using? 32 or 64 bit?
>>
>> I will review trigger keys for menu items. In general (with a few
>> exceptions), I find such trigger letters to be of little value to users.
>> In general, I think users either navigate to the menu item of
>> interest and press Enter, or alternatively, learn the direct,
>> accelerator key combination, and press that instead, bypassing the menu
>> system entirely.
>> I am generalizing, and appreciate your points in a systematic
>> analysis for unique trigger letters in menus.
>>
>> I have tried to completely hide Microsoft Word while invoking its
>> spellchecker, alas, without success so far. I have closely studied
>> the COM object documentation. My code sets properties to make Word
>> invisible. I changed calls to VB, which before C# 4.0, considerably
>> worked more harmoniously with COM than C#. If anyone can help me
>> tighten that code, I would appreciate the contribution.
>>
>> I will look at refining speech around the Undo command, and other
>> speech suggestions you mention.
>>
>> Jamal
>>
>> On 12/5/2010 4:41 PM, Sina Bahram wrote:
>>> Jamal,
>>>
>>> I installed ed-sharp, latest version, today, and I ran into the
>>> following issues within the first few minutes of use. I just wanted
>>> to report them in hopes of making this better for other users.
>>>
>>> #1: installer doesn't ask about shortcuts
>>>
>>> The installer didn't let me choose, like most do, whether I want an
>>> icon on my desktop. Can this be added?
>>>
>>> It also concerned me about whether it was putting something in my
>>> quick launch. I hope it's not, as I always uncheck this option from
>>> every installer I come across, but it would be nice to have that
>>> standard installer screen, if possible.
>>>
>>> I simply deleted the icon, after I installed the program, but it
>>> would be nice for it not to get created in the first place.
>>>
>>> #2: control+alt+e keystroke doesn't work, and in fact isn't assigned.
>>>
>>> So I was told that control+alt+E launches ed-sharp by the installer,
>>> but when I pressed it after the install was done, nothing happened.
>>> I tried it several times, and then I actually investigated the
>>> "launch ed-sharp" icon in the start-menu, and found that the launch
>>> keystroke field was empty; thus, that made sense why it didn't work.
>>> After I manually added control+alt+e to that field, it of course
>>> started working.
>>>
>>> #3: the elevate command always updates
>>>
>>> When in ed-sharp, I pressed f11 just to verify I was at the latest
>>> version, but apparently I am not, or the elevate command is broken
>>> because it said comparing to server, and then it offered me a
>>> download of the exact version I just installed. In other words, it
>>> never bothered telling me that the version on my computer and the
>>> server are the same, and it also makes the user think that they
>>> aren't, since it offers a download.
>>>
>>> I would suggest maybe changing the button or message to reinstall or
>>> something like that, if the versions are identical, so that the user
>>> doesn't think they are at an older version?
>>>
>>> #4: delay in file menus when using jaws
>>>
>>> I installed the jaws scripts, as I had no reason not to, using the
>>> last page of the installer, and they compiled correctly; however,
>>> when in ed-sharp, the menu bar is a little laggy. What I mean by
>>> this is that if I hit alt, and then arrow through file, edit,
>>> delete, navigate, etc, etc ... It's a little slow. I'm guessing that
>>> this is possibly because of the JFWAPI being used or something like
>>> that; however, it's kind of irritating, especially if you have your
>>> jaws set to decently fast; for example, I listen to eloquence at 80%
>>> speed, as defined by the jaws verbosity box, and there's about an
>>> extra 300 to 600 millisecond delay, as if jaws is being instructed
>>> to speak, as opposed to doing it itself. My question would be, A.
>>> can this be fixed/sped up? And B. if it's just a file menu, why is
>>> the JFWAPI being used? That it of course assumes that it even is
>>> being used, and the delay isn't caused by something else of course.
>>>
>>> Note, this delay is especially noticeable when hitting keystrokes
>>> like
>>> alt+f or alt+e to bring up menus. Almost to the point where
>>> you think you hit the keystroke wrong or something, and then you
>>> realize that the menu is coming up, but just slowly.
>>>
>>> #5: alt+tabbing to ed-sharp doesn't announce the title
>>>
>>> When you alt+tab to almost any other application, jaws reads the
>>> title of the window for you, letting you know two things. It let's
>>> you know that the alt+tab successfully completed and that focus is
>>> on that window, and by announcing the window title, it gives you
>>> whatever information the application developer wishes to convey in
>>> their title bar.
>>>
>>> This doesn't happen with ed-sharp. When I alt+tab to it, I get
>>> silence ... Jaws doesn't make a peep. This is a bit jarring.
>>>
>>> #6: in the file menu, several characters map to different choices:
>>>
>>> In the file menu, I can hit o to open, open in other format, or open
>>> again.
>>>
>>> Unfortunately, o just activates open, which is the correct behavior
>>> according to the underlying technology being used for the file menu.
>>> Could the other two options be assigned different menu accelerators?
>>> Their menu shortcuts are of course unique, but their accelerators
>>> are the same.
>>>
>>> This is true in other places too, but even in the file menu, you can
>>> see it with set favorite and save both being mapped to s.
>>>
>>> Note: what I've seen adopted as official policy by some UI
>>> developers is that you start with the first letter, then move your
>>> way through the word for subsequent accelerators. Some folks go
>>> further and state that vowels are excluded from this, although I
>>> personally disagree with that approach and think all characters are
>>> fair game; for example, o for open makes perfect sense, although p
>>> for "open again" doesn't because p should map to print, so you have
>>> an exclusion tree whereby the first letter of every menu item is put
>>> into a set, which by definition is a unique list, and then this set
>>> is used as an exclusion list as you step through the characters of
>>> the duplicate menu item.
>>>
>>> One side note, another popular approach, of which I do tend to be a
>>> fan of, is to use the first letter of subsequent words, before going
>>> back for second and third letters of the original word. E.G.
>>> "save as" maps to 'a'.
>>>
>>> The algorithm for this is rather straight forward, with one huge
>>> caveat (discussed below), if you think about it, and goes like this.
>>>
>>> I have the following six menu items.
>>>
>>> New
>>> Save
>>> Save as
>>> Open
>>> Open recent
>>> Exit
>>>
>>> First I take the six characters and put them into a list, which is
>>> technically called a bag:
>>>
>>> bag(n, s, s, o, o, e)
>>>
>>> And then I turn that bag into a set, like this:
>>>
>>> set = unique(bag)
>>>
>>> So I get:
>>>
>>> set(n, s, o, e)
>>>
>>> And then I have a set of characters I've used as accelerators, which
>>> starts out empty:
>>>
>>> accelerators()
>>>
>>> Now, I add characters to that list, for each menu item, being
>>> careful to disallow duplicates, which closure property I get for
>>> free as a result of using a set instead of a bag, like so:
>>>
>>> New gives us n
>>>
>>> So we have:
>>>
>>> accelerators(n)
>>>
>>> Open gives us o
>>>
>>> So we have
>>>
>>> accelerators(n, o)
>>>
>>> Open again gives us o, but wait, o already exists in accellerators,
>>> so we go to the first character of the next word which gives us an
>>> 'a':
>>> // see the cavviot section for why 'a' is a bad choice // the
>>> correct choice here is 'g' because 'g' comes after 'a' in the word
>>> "again"
>>>
>>> accelerators(n, o, g)
>>>
>>> Then we get s for save, and so on
>>>
>>> accelerators(n, o, g, s)
>>>
>>> Then "save as" gives us 'a'
>>>
>>> accelerators(n, o, g, s, a)
>>>
>>> And then, finally, exit gives us 'e'
>>> // again, see the cavviot section for why 'e' is a bad choice //
>>> going with x instead
>>>
>>> accelerators(n, o, g, s, a, x)
>>>
>>> And of course accellerators == unique(accellerators); thus proving
>>> it's in fact a set, and not a bag.
>>>
>>> *** Huge Haunking Caveat Section: ***
>>>
>>> Now, the reason that this algorithm unfortunately can't be
>>> programmed in, and has to really be done by hand, or at least whose
>>> output needs to be revised by hand is that there are idioms users
>>> have come to expect. As is the case with all things in computer
>>> science, humans get in the way of elegant algorithms, almost always.
>>>
>>> So, for example, we assigned 'a' to save again, but this really
>>> isn't what we want. We really want to assign it 'g', because users
>>> have come to expect that 'a' is always save as in a file menu, just
>>> like how s is save, and how o is open.
>>>
>>> Thus, if one is prone to think about things in an algorithmic point
>>> of view, just imagine a 2-ply deep file menu priority tree where the
>>> semantics of these common idioms are stored; such as, under the file
>>> node: 'a' maps to "save as", 'o' maps to "open", and so on. Then use
>>> the same algorithm as above, but use the idiom tree as a higher
>>> priority exclusion list than the accellerators set, indexing into
>>> the idiom tree with the menu item name, of course.
>>>
>>> To be fair, the above is more of a heuristic than an algorithm, but
>>> I do find that it works super well, and takes all the guess work out
>>> of picking accelerators in menus.
>>>
>>> #7: spell check issues
>>>
>>> When I hit f7 for spell check, I get some rather odd behavior. It
>>> initializes Microsoft word, GUI and all, in the background. I
>>> understand why it does this, because, why reimplement/reinvent spell
>>> check, when Microsoft word exists right there on the user's machine;
>>> however, can you just use word as a com object without invoking the
>>> UI, just like that code snippet I sent out a really long time ago
>>> about how to use Visual Studio 2005 without invoking the UI! This
>>> brings up a further question of whether the spell check
>>> functionality is able to be used via com, without actually invoking
>>> the main MSWord object at all. Is that possible?
>>>
>>> Moving on. I perform a spell check, and then I'm never told that
>>> spell check is over. I don't even really know I'm back in my
>>> document in ed-sharp, probably because of the earlier bug where the
>>> title isn't read out, but what's even more frustrating is that
>>> spell-check didn't clean up after itself, and I have this empty
>>> Microsoft word document in the background.
>>>
>>> Also, sometimes, although I can't replicate this particular issue on
>>> demand, so sorry about that, but sometimes, it focuses said empty
>>> Microsoft word document, instead of ed-sharp, after the spell-check
>>> is complete.
>>>
>>> #8: undo doesn't announce selection
>>>
>>> Would it be possible for undo to announce if it's undone action
>>> results in selected text?
>>>
>>> For example, write a sentence, and then highlight that sentence and
>>> hit the delete key. Now hit control+z for undo. It would be nice if
>>> ed-sharp told you that the sentence that was brought back from the
>>> great bit bucket in the sky was highlighted, simply by saying the
>>> word selected before reading the sentence, as it does now.
>>>
>>> There are some other things as well, but the number 8 is a nice
>>> binary number, so I wanted to stop there.
>>>
>>> Thanks much, and happy hacking.
>>>
>>> Take care,
>>> Sina
>>>
>>> __________
>>> View the list's information and change your settings at
>>> //www.freelists.org/list/programmingblind
>>>
>> __________
>> View the list's information and change your settings at
>> //www.freelists.org/list/programmingblind
>>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
>
--
Thanks,
Ty
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
