The problems I have are sometimes when editing messages, the screen
goes completely away according to Window-Eyes, before it never did
that. It is a terrible puzzle here, since with WE7 BETA 3 and all
earlier versions of Window-Eyes, this did not happen. All other
aspects are better using 7.0 full release, including the problem
which use to happen with BETA3, where when I would arrow to a new
message down the list or delete a message in the list view, it would
not refresh, would re-read the current "deleted" message as though it
were still there, when it was not. Now, using this xp home sp3 system
with 2 gigs ram, 2.1Ghz processor, plenty of disc space and
defragged, optimized, etc. I cannot write messages using Eudora any
more. I have to use another screen reader to do that. It happens more
often than it does not, though not all the time. Also, while the
current editing job is loading, Window-Eyes and Eloquence STUTTERS
awfully, as though my computer were completely "hour glassed" when
all that is happening is that Window-Eyes cannot efficiently handle
multiple mailboxes open and the more that are open, the less
efficient it is. I've mentioned this many times before, and can
demonstrate to all and sundry exactly how to duplicate this using
Eudora in a manner which is, for me, most efficient, but Window-Eyes
cannot handle it that way. I must use jaws to handle it in that way
since, fortunately or unfortunately, there is no decrease in speed no
matter how many mailboxes are open when I do use jaws. Now, though,
this business of getting all mucked up when I hit backspace in a
message while editing it, that's disaster for me since I'd rather use
Window-Eyes, in fact paid $175 in the hope that someone would at
least look at the issues which were plaguing Window-Eyes and the use
with Eudora and it's sluggishness, but alas, they did not, and this
new problem has reared up. Now while editing this message,
Window-Eyes worked flawlessly, but as I say, it is "not all the
time," but often enough where I have to unload WE, load jfw and do
the editing then. As I say I'd rather use WE, a thousand times over.
Freedom Scientific ignores those who send them beta reports after all
when those at gw-micro at least respond to queries on this list and
their testers. I filled out 3 beta reports with jfw10 beta, no
response though I found serious issues with that bloat ware, still --
no response, though it is touted as the next greatest release since
the advent of sliced bread, when, in fact, it won't even properly
check for updates, it's new "menu and dialog" voice is the default
when it should be PC cursor voice, and on and on. Serious reports
which should be responded too, certainly, but you'd think we're beta
testing it for what reason? Our benefit, not theirs, when it should
be theirs, if someone is willing to "beta" test. I have willingly and
eagerly embraced Window-Eyes from the first, and have been rewarded
with complete attention to issues I've raised using the product, so I
am hoping that this issue with Eudora, though it is suppose to be a
unsupported version V7.1.0.9 which is the real last Eudora, 8.0 is
just another Thunderbird with some Eudora keystrokes, that this issue
with losing the editing screen can be addressed.
I have continued to go on and on and see if WE would lose focus or
whatever it does, but it has not. I wonder if it could have been a
script which had an error? As I say though it never happened before
the 7.0 release so, Q E D? :)
Well, this entire message has not had the error crop up again, but
the sluggishness, I can readily demonstrate.
Anyone who uses Eudora knows that there is a way to have multiple
mailboxes open, and the reasoning is simple: suppose you get a lot of
mail? If you have auto-open mailboxes turned on, the newest mail is
always to the left, and the way to get to it is to hit control-tab.
When you finish reading a current mailbox, hitting control-D, after
each auto-read, when you get to the last message, the current message
is auto closed, deleted, the next mailbox which got the most current
delivery of mail is automatically focused upon, usually at the top or
at the last unread message. So, being efficient I just continue to
read mail, or if I hear a signal from a mailbox which I wish to check
right away, I hit control-tab until my screen reader indicates by
reading the window title that X mailbox has focus. (Remember when I
mentioned how I wish Window-Eyes auto-read window titles when focus
was changed to another window title? That's why, because in Eudora,
if you press control-tab with multiple mailboxes open, it cycles to
the newest mail delivery place which just got mail from where ever
you happen to be focused. Window titles, in this context, are mail
box names, so while hitting control tab, lets say from this message,
I hear, "book share volunteers discuss," I know that is the last
mailbox which got mail.
Now I heard another signal, tapped control tab and focused on my
inbox, so that tells me that a non-filtered message came in. See why
this is cool? I'd rather do that than look for a check box in a menu,
where that check box tells you that a given mail box has unread mail
in it. I have plenty of ram, and in XP using Eudora in this way, 2
gigs should be plenty. At the moment, Eudora is using 108,700K and
Window-Eyes is using 134,680K, so my screen reader is using more than
my mailer is. I loaded jfw, and it uses, after scrolling around a lot
and doing things like edit filters, 19,092K. If I had one mailbox
open at a time, there is no sluggishness at all, but using Eudora in
this way, there is no way I can edit filters using Window-Eyes
because every time an edit control occurs, it takes seven seconds to
do anything after tab is press to change the focus to that edit
control. I wonder what it is in Window-Eyes, (NVDA also which just
cannot be used at all in Eudora), that causes the software to go
bonkers under these conditions? It matters not the machine, guys, so
you can't tell me that Eudora, on another machine would not do this
using Window-Eyes, I've used it now since 2002 continuously, and on 4
computers using everything from a 1.1Ghz P3 processor with 512M of
ram, to this one with gradual increases of ram and disc drive
performance, this issue has always been there with Window-Eyes, but
not jfw, because of a particular way in which jfw sees these
conditions. I wonder, technically, what it is, that's all, you know,
us curious cats and all that I'd love Window-Eyes to handle
everything fabulously, so that is why I mention it at all. If I
didn't care at all I'd be satisfied using the competitors product
since it handles it fine, but I detest what they do and how they do
it, so it is as though I feel as though I am betraying Window-Eyes
confidence when I do it since I don't wish to support jfw in any way,
but when it works, what do you do man? I wish Window-Eyes to be my
all and everything choice, and since I cannot open up my eyes and use
a monitor like normal people do, software to handle software is the
only way we have to do it at the moment. I know it is not my computer
which freezes for those 7 seconds, since if it were, jfw would freeze
as well, but, unfortunately it is a condition of Window-Eyes and
memory reading issues of some kind when multiple mailboxes are open.
I've gone on and on, to really test this "new to me" issue of losing
the screen in an edit control using Window-Eyes, so now must conclude
that is was a singular issue for a six hour period but now seems to
be cleared up, but the other still remains as it has since the
beginning, with multiple mailboxes and Eudora, causing WE to become
extremely sluggish when changing edit controls. E.G. inside this
message, if I go from the message body to the "bcc" field using a
single shift-tab key stroke, then press tab to get back to the
message body, it takes four seconds after a silent press of the tab
key to hear "edit Why does it take jfw no time at all whatsoever,
just why? Hey programmers, you should know, under the same conditions
there should be a logical reason as to why this occurs, and has since
the beginning so this condition is not related to my particular
machine and my particular "what is loaded under neath as TSR programs
as such," since in no significant way, has this altered the behavior
of Window-Eyes and Eudora. Sure, when I had 512Mhz of ram and 1.1Ghz
p3 processor, it would take a longer time to hear "edit" in the above
demonstration, but the delay, then, was more because of conditions I
understood, but then, jfw had no delay whatsoever either, so I asked
then, 6 years ago, why too, and was told they'd look into it but
nothing was done because other priorities were more important. Now, I
know that nothing will be done because this program is moribund as
such so why put in work in a condition which does not occur
elsewhere, or at least that is the idea, if we fix this, it takes
time away from present day issues which have our attention now. I
submit, however, that this delay issue with memory allocation, or
whatever it is that causes jfw to work instantly and Window-Eyes to
take four or five seconds, would resolve other issues long
problematic, so at least a look as to why this takes place and why it
does not using jfw should be at least understood.
Curtis Delzer.
HS
At 01:22 AM 9/20/2008, John G wrote:
You check out other influential factors. I can tell you that Eudora
with v7 is noticeably faster here. Arrowing up and down messages in
mailboxes is now a much lighter and smoother experience. reading
text in the message body (in the message edit field) has improved
too. So, I think it's worth checking what else you have going on
there. Perhaps you could share with the list what other software
you usually have running when you launch Eudora. How about your
machine? How much RAM have you got? That sort of thing. More
information please!
John
rich kurlander here eudora sluggish and not speaking with we7.0what do I do?
If you reply to this message it will be delivered to the original
sender only. If your reply would benefit others on the list and
your message is related to GW Micro, then please consider sending
your message to [email protected] so the entire list will receive it.
All GW-Info messages are archived at http://www.gwmicro.com/gwinfo,
and can be searched through and sorted using the search
form at the bottom of the page.
If you wish to unsubscribe from this list, send a message to
[EMAIL PROTECTED] and include leave gw-info in the body of the message.
If you reply to this message it will be delivered to the original
sender only. If your reply would benefit others on the list and
your message is related to GW Micro, then please consider sending
your message to [email protected] so the entire list will receive it.
All GW-Info messages are archived at http://www.gwmicro.com/gwinfo,
and can be searched through and sorted using the search
form at the bottom of the page.
If you wish to unsubscribe from this list, send a message to
[EMAIL PROTECTED] and include leave gw-info in the body of the message.
If you reply to this message it will be delivered to the original
sender only. If your reply would benefit others on the list and
your message is related to GW Micro, then please consider sending
your message to [email protected] so the entire list will receive it.
All GW-Info messages are archived at http://www.gwmicro.com/gwinfo, and can be
searched through and sorted using the search
form at the bottom of the page.
If you wish to unsubscribe from this list, send a message to
[EMAIL PROTECTED] and include leave gw-info in the body
of the message.
