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 <mailto:[email protected]>
    *To:* [email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 <mailto:[email protected]>

        *To:*[email protected] <mailto:[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] <mailto:[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