OK. I'll release it when the WE that fixes the bug is released.

Best Regards,
J.J. Meddaugh
A T Guys
Your Assistive Technology Experts
(269) 216-4798
http://www.ATGuys.com
  ----- Original Message ----- 
  From: Doug Geoffray 
  To: [email protected] 
  Sent: Thursday, June 23, 2011 4:57 PM
  Subject: Re: Issue with Quick Quit


  J.J.,

  Yes, you are vindicated but I would still change the following two things:

  1) Queue quickQuit instead of calling it directly in your event handler

  2) Make sure you set the default return value to your OnHotkey callback so 
you know what you are returning if your if doesn't happen.

  Doug

  On 6/23/2011 4:40 PM, J.J. Meddaugh wrote: 
    Awesome. Does this mean I'm vindicated, or do I still need to update the 
app? Yes, I'll fix that one thing you were talking about.

    Best Regards,
    J.J. Meddaugh
    A T Guys
    Your Assistive Technology Experts
    (269) 216-4798
    http://www.ATGuys.com
      ----- Original Message ----- 
      From: Vic Beckley 
      To: [email protected] 
      Sent: Thursday, June 23, 2011 4:34 PM
      Subject: RE: Issue with Quick Quit


      Sounds great! Thank you Doug for figuring it out. This has been this way 
for I don't know how long. I haven't been able to use the quickQuit app for 
quite some time now.



      Vic





      From: Doug Geoffray [mailto:[email protected]] 
      Sent: Thursday, June 23, 2011 3:57 PM
      To: [email protected]
      Subject: Re: Issue with Quick Quit



      Vic,

      Thanks for sending your default profile.  I could very easily duplicate 
the problem with your profile.  The problem is the close dialog comes up.  
Other than being annoying it doesn't really matter but it shouldn't have been 
coming up.  I noticed if I left all your apps (and you've got a lot of them 
<smile>) enabled except for Read To Me the problem went away.  Guess what Read 
to Me hooks?  That's right, it also hooks OnHotkey.  It obviously isn't looking 
for the same hotkey but it is hooking the event.  

      Turns out the is a bug in Window-Eyes where it only uses the last return 
value.  The order that apps get called is somewhat random but whatever the last 
one returns is what Window-Eyes will do.  So the Quick Quit app returned first 
with a True indicating it handled the hotkey so don't let Window-Eyes do its 
thing.  But then it sent the event to Read to Me which returned False because 
it doesn't handle the shutdown key.  So Window-Eyes saw False and said I'll 
allow Window-Eyes to do its process.

      Clearly a Window-Eyes bug which is being resolved as I type.  This will 
be out in the next release of Window-Eyes.

      Thanks for helping narrow this down.

      Doug
      P.S. in my last email I see I once again typed "existing" instead of 
"exiting."  Is it 5 yet?

      On 6/23/2011 10:31 AM, Doug Geoffray wrote: 

      Vic,

      Okay, my bad twice <smile>.  I didn't catch he was speaking from 
myStrings.  I just saw speak and in quotes "existing".

      As I was reading through you message I was thinking you needed to zip me 
up your default dir so I was glad to see you offered that at the bottom.  I'm 
hopping I'll be able to duplicate this with your profile and this will lead to 
what is going on.

      Regards,
      Doug

      On 6/23/2011 10:24 AM, Vic Beckley wrote: 

      Doug,



      I have version 1.43. It says there are no updates.



      In QuickQuit.vbs: Speak myStrings("exiting")



      In QuickQuit.xml: <string id="exiting">Window-Eyes Exiting</string>



      I do hear "Window-Eyes exiting" as I would expect. I turned this around 
in my previous message.



      After adding the Queue statement to the app with a sleep of 1000, this is 
what takes place:



      I press the hot key.



      I hear "Window-Eyes Exiting."



      I hear the sound from Windows announcing that the Exit Window-Eyes dialog 
has come up. The WESounds app also fires and I hear its sound announcing that a 
WE dialog has come up. This did not happen before the Queue statement.



      I hear the Window-Eyes Exit dialog spoken. Most of the time it is cut off 
a little prematurely, but I hear most of it. This happens pretty much 
simultaneously with the 2 notification sounds.



      Now WE is gone and I can reload it normally.



      I performed this procedure with the same results as stated above at least 
5 times with WE terminating correctly. This definitely is much better.



      Then I changed Script Status to Manual and started just GW Toolkit and 
QuickQuit. There was no problem now. I have been working most of the morning 
enabling and disabling apps one at a time and can't find any specific app that 
causes the problem. It seems that it must be the number of apps I have running 
at any given time. I have anywhere from 34-37 apps loaded depending what I am 
doing.



      Would it be worth it for me to zip up my Default folder and send it to 
you to see if you can duplicate it on your machine?



      I am running Windows 7 SP1 X64 on an AMD Phenom II X4 3.4ghz processor 
with 4ghz RAM and ATI Radeon HD 3300 graphics. It shouldn't be that slow a 
system.



      Vic





      From: Doug Geoffray [mailto:[email protected]] 
      Sent: Thursday, June 23, 2011 8:34 AM
      To: [email protected]
      Subject: Re: Issue with Quick Quit



      Vic,

      Okay, now it is my bad.  I didn't mean "existing," I meant "exiting".  
However, with this app you definitely shouldn't be hearing "exiting 
Window-Eyes".  If you are hearing that than maybe you have a different version 
of this app running as well?  Assuming you really are hearing "exiting" and not 
"exiting Window-Eyes" than that means this app did intercept the shutdown 
Window-Eyes hotkey.  So assuming all this how about changing the one line:

      quickQuit

      to

      Queue "quickQuit"

      This will cause the quickQuit sub to be queued allowing the OnHotkey 
function to return immediately that it handled the hotkey so Window-Eyes won't 
bring up the dialog.  I don't really know why this would be needed but at this 
point I'm trying anything...but I really do want to verify exactly what you are 
hearing when you press the shutdown hotkey.

      Doug


      On 6/22/2011 7:32 PM, Vic Beckley wrote: 

      Doug,



      Duh. My bad. I thought you changed the code. It looked like you changed 
the sleep statement from 1000 to 10000. Anyway, it should have worked as well.



      I was able to start NVDA when I was in the state of WE not exiting. I 
found that the Exit Window-Eyes dialog was still up on the screen. If I pressed 
the OK button, then WE would exit and comeback up fine. Here is what the 
sequence of things are for me:



      I press the Control-Insert-F4 hot key.

      I here "Exiting Window-Eyes." Is this what you mean when you ask me if I 
hear "Existing?" I do not hear "existing" at any time.

      Speech is lost totally from this point.

      I hear the sound that tells me that the Exit Window-Eyes dialog has come 
up. No speech is elicited.

      I have now determined that focus is on the OK button because if I press 
the spacebar at this point WE will exit and come back up fine.



      I have loaded NVDA several times to confirm this chain of events and it 
is consistent. This happens most of the time for me. I would say that it might 
work as expected in 1 out of 10 tries at best.



      Any ideas why this might be happening?



      Vic





      From: Doug Geoffray [mailto:[email protected]] 
      Sent: Wednesday, June 22, 2011 5:27 PM
      To: [email protected]
      Subject: Re: Issue with Quick Quit



      Vic,

      I'm not following when you say you replaced it with my code.  The code I 
showed is the original code.  I didn't write that I just copied it out of the 
latest version of the Quick Quit script.

      Also, when you say the first time you pressed the hotkey to remove WE, it 
worked just fine...so I assume you mean that Window-Eyes unloaded and you 
restarted it and than on the press of the hotkey this time it didn't work?  Did 
you hear it speak "Existing"?  My system is also Windows 7 64-bit and I'm not 
seeing this.

      Doug

      On 6/22/2011 4:54 PM, Vic Beckley wrote: 

      Doug,



      I replaced the code in the QuickQuit.vbs file with your code. The first 
time I press the hot key to remove WE, it works just fine. On the second 
attempt, the exit dialog comes up. It does not speak and WE seems to be exited. 
When I reload WE, however, I get the sound that WE is already running and it 
will not load. I have reproduced this several times. This has been happening 
for me for quite a while now, although it did work quite well when it was first 
written and a while afterwards. Any idea what could be going on? This is on 
Windows 7 X64 SP1 running WE 7.5.1.0.



      Vic





      From: Doug Geoffray [mailto:[email protected]] 
      Sent: Wednesday, June 22, 2011 3:36 PM
      To: [email protected]
      Subject: Re: Issue with Quick Quit



      J.J.,

      I took a quick look because I knew this would be a simple app.  The only 
thing I can come up with is you aren't hooking the OnHotkey.  Let me start by 
saying I've never seen this fail...but if I change your OnHotkey to always 
return False (meaning I just changed your OnHotkey = True to OnHotkey = False) 
it still always works.  So the Quit will shut down Window-Eyes even if the 
shutdown dialog comes up.  So Quit can't be called when it fails.

      Do we know when it fails if it says"existing"?  My guess is that it is 
not saying this because your quickQuit never gets called in the case it doesn't 
work.  So either your script isn't running properly or they tried to shut down 
before it was fully running or somebody else is eating the hotkey...

      For those playing at home here is the code that does the work.  It is 
very simple.  Oh, by the way, I don't like that your OnHotkey function doesn't 
set the return value explicitly to False if the hotkey isn't the shutdown 
hotkey and isBeforeAction is true.  VSScript is letting you get away with this 
by defaulting the return value to 0 which is false.  Consider yourself flogged.


      ConnectEvent Application, "OnHotkey", "OnHotkey"

      Function OnHotkey(hotkeyId, isBeforeAction, defaultActionAborted)
      if hotkeyId = hkShutdownWindowEyes and isBeforeAction then
      quickQuit
      OnHotkey = True
      end if
      end function

      sub quickQuit()
      Speak myStrings("exiting")
      sleep 10000
      Quit
      end sub


      Doug

      On 6/22/2011 2:10 PM, J.J. Meddaugh wrote: 

      Hello.  This is currently a known issue which has been reported, but I'm 
not able to reliably figure out exactly what is going wrong. Work take another 
look at this soon, and of course, anyone else is welcome to look at the code 
too.





      Best Regards,
      J.J. Meddaugh
      A T Guys
      Your Assistive Technology Experts
      (269) 216-4798
      http://www.ATGuys.com

        ----- Original Message ----- 

        From: Jeff Weiss 

        To: [email protected] 

        Sent: Wednesday, June 22, 2011 11:07 AM

        Subject: RE: Issue with Quick Quit



        After installing WE 7.5.1, I had that same issue.

        Just restarting the Quick Quit app, or restarting Window-Eyes took care 
of the problem for me.





        From: Sean Farrow [mailto:[email protected]] 
        Sent: Wednesday, June 22, 2011 9:42 AM
        To: [email protected]
        Subject: Issue with Quick Quit
        Importance: High



        Hi: 

        I'm using the latest version of window-eyes, v7.5.1.

        When using the quick quit app, latest version I think given that I've 
just installed the upgrade to quickly change screen access technologies, I 
still sometimes get the quit window-Eyes Dialog appearing. Has anyone else 
observed this?

        If yes, does anyone know of a fix?

        Cheers

        Sean.

Reply via email to