Comment 1 by ateu on 2014-03-20 16:19
This also occurs when closing an application and backing to a Window Explorer Window, such as a folder or "computer" (where you select a disc).

Comment 2 by nvdakor on 2014-04-21 23:33
Hi,
What I found is that NVDA does recognize that you did open the program, but an invisible MS splash window pops up. To verify this, do:

1. open the program where you know NVDA does not announce when an app is opened (e.g. MS Word 2010).
2. Press the following keys:

• NVDA+End (desktop): speaks the status bar.
• Control+NVDA+F1 (desktop): says the name of the program.
  Notice that what you'll hear would be the information you'd expect to hear when using the program.
  Technical info:
  When the splash window versus regular window for these programs opens, you'll get:
  Example: winword.exe (MS Word):
  Splash window output: obj.name = None, obj.windowClassName = "MsoSplash", foreground.windowClassName = "OpusApp", foreground.name = "Document (X) - Microsoft Word".
  Regular output: obj.name = "Microsoft Word Document", obj.windowClassName = "WWG", foreground.name = above, foreground.windowClassName = above.
  So Compared to this, when a program such as Outlook opens, NVDA does recognize that you have the program open by saying the text on the screen (for Outlook, the contents of the folder). So I'd guess that something's going on with gainFocus or foreground events when the offending programs are started for the first time.
  I have confirmed this in latest next snapshot. Thanks.

Comment 3 by jteh on 2014-05-01 06:26
This is somehow caused by #3831, but I'm not sure how yet.

Comment 4 by jteh on 2014-05-02 08:57
It seems that EVENT_SYSTEM_FOREGROUND is sometimes fired before GetForegroundWindow is updated. I'm not quite sure why this didn't hit us before. In some cases, I think it's because we waste less time processing pointless events.

Comment 6 by James Teh <jamie@... on 2014-06-24 06:34
In [d715c51]:

Fix broken focus when starting certain applications such as Microsoft Word and Excel.

It seems that GetForegroundWindow isn't updated for a short while after the foreground event in these cases as well. Therefore, cache the window from the foreground event and use that instead of calling GetForegroundWindow within a short timeout.
We didn't notice this in the past because we were handling a lot of pointless events that we aren't handling now.
Re #4001.

Comment 7 by James Teh <jamie@... on 2014-06-24 06:34
In [6f0f19f]:

Merge branch 't3831' into next

Incubates #3831. Fixes #4001.

Changes:
State: closed

Comment 8 by leonarddr on 2014-06-27 11:27
This fix doesn't work for me. Actually, the issue started occurring for me between snapshot 10750,b9a7674 and 10762,e8bfeda. I have a shortcut to a PuTTY session on the desktop, which i open. Observe the behavior in the log below:
``
IO - speech.speak (13:24:38):
Speaking 4 of 4'
IO - inputCore.InputManager.executeGesture (13:24:40):
Input: kb(laptop):enter
DEBUGWARNING - RPC process 2208 (putty.exe) (13:24:40):
Thread 1664, build\x86\remote\ia2Support.cpp, installIA2Support, 81:
Error registering class object, code -2147221008

DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (13:24:40):
oleacc.AccessibleObjectFromEvent with window 1115006, objectID -4 and childID 0: -2147467259 Unspecified error
IO - speech.speak (13:24:40):
Speaking - PuTTY terminal'
IO - speech.speak (13:24:40):
Speaking [- speech.speak (13:24:40):
Speaking [u'pane'](u'blank']
IO)
IO - inputCore.InputManager.executeGesture (13:24:46):
Input: kb(laptop):NVDA+t
IO - speech.speak (13:24:46):
Speaking [- inputCore.InputManager.executeGesture (13:24:49):
Input: kb(laptop):control+NVDA+f1
IO - speech.speak (13:24:49):
Speaking [u'Currently running application is explorer.exe and currently loaded module is explorer'](u'leonard@someserver:/home/leonard']
IO)
``

Comment 10 by jteh on 2014-06-27 11:44
I don't think this is the same issue. In the original issue, the correct focus was lost. In this case, PuTTY does seem to get focus correctly, but then an Explorer pane gets focus after. First, are you certain focus is really in PuTTY? For example, if you type, is it caught by PuTTY?

Comment 11 by leonarddr (in reply to comment 10) on 2014-06-27 11:54
Replying to jteh:

I don't think this is the same issue. In the original issue, the correct focus was lost. In this case, PuTTY does seem to get focus correctly, but then an Explorer pane gets focus after. First, are you certain focus is really in PuTTY? For example, if you type, is it caught by PuTTY?

Yes, this is the case. There are also situations where i alt+tab out of PuTTY and back in, in those cases explorer is reported as being the title of the window.
It might be possible for you to build a snapshot without the fix of this ticket in order to test whether this fix creates my issue. I currently have no build environment running myself.

Comment 12 by leonarddr on 2014-06-27 11:57
It might be the same as nvdakor reported in #3831

Comment 13 by jteh on 2014-06-27 12:01
It's possibly related. I'll look into that first. Hopefully, a fix for that will fix your issue, too. I'll probably discuss this in #3831 hereafter, so keep an eye on that ticket for updates.

Comment 14 by James Teh <jamie@... on 2014-08-08 13:04
In [7b6b9d9]:

Revert "Fix broken focus when starting certain applications such as Microsoft Word and Excel."

This was causing focus problems for NVDA windows such as the browse mode Find dialog (#4295) and could cause similar problems in other cases. It also wasn't solving many cases of focus problems when starting applications anyway.
This reverts commit d715c51f52a7a233d1ad02123282b121ef37525d.
Re #4001, #3831. Fixes #4295.

Comment 15 by jteh on 2014-08-08 13:05
Changes:
State: reopened

Comment 16 by vgjh2005 on 2014-10-14 07:44
Hi:
When I navagate the file list in explorer by pressing arror keys, sometimes NVDA cannot read at all. I need use browse cursor to navagate to the object then press NVDA plus shift plus - to set focus property. Other screen reader is normal.
Thanks!

Comment 17 by James Teh <jamie@... on 2015-01-23 07:53
In [6f95a3d]:

IAccessibleHandler: Move shouldAcceptEvent into pumpAll (instead of winEventCallback), as this is more like the way things previously worked and seems to fix some focus issues when starting applications.

Re #4001.

Comment 18 by jteh on 2015-01-29 07:03
This seems to be fixed. Please reopen if the problem persists (but only if it's specific to next).
Changes:
State: closed