J.J.,

I would suggest doing it immediately. By queuing the call it allows Window-Eyes to shut down cleanly all the time. There is a timing issue if the dialog comes up while Window-Eyes is in the process of shutting down. Vic's profile could duplicate this easily although not 100 percet. The updated Window-Eyes will stop the dialog completely from coming up but in the mean time you doing the queue will get rid of the timing issue of shutting down cleanly.

You know, another option is you get the current hotkey for the shutdown (which will be global) and just register your own hotkey with that keystroke. App hotkeys win out if there is a conflict of hotkeys which means you would see the keypress and than just do a Quit from there. This way you don't have to worry about the dialog at all because Window-Eyes itself won't see it as a hotkey.

Doug

On 6/23/2011 5:27 PM, J.J. Meddaugh wrote:
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 <mailto:[email protected]>
    *To:* [email protected] <mailto:[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 <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