The GW-Scripting list is a discussion list for information regarding the development and use of Window-Eyes scripts. Any subscriber of the GW-Scripting list has the ability to post on-topic messages.
From:
Doug LeeSubject:
Re: What's lost on SimulateEvent?Date:
Fri, Jan 29, 2010 2:34:32 pmFor the benefit of this list: The issue I've been working with,
though it looked like an MSAA event issue for a long time, turned out
to be a totally different issue. It turns out that setting
Window.Type on some windows in this app causes problems, and I
happened to be doing that from inside an MSAA OnObjectFocus event sub.
I'm working this one out off list, partly because of the amount of
traffic it's generating. In case anyone else hits this issue though,
here are its indicators, by example:
I spot a window with type wtCustomControl (11). I figure out that
it's really a button, so I say Window.Type = wtButton (1). When it
works, Window.Type is 1 from then on. When it doesn't, though, the
following apply:
- Window.Type becomes wtUnknown (0).
- Attempting to set Window.Type again changes nothing.
- It is thus impossible even to set Window.Type back to wtCustom (11).
- No code error is thrown, and code does not stall; subsequent lines run.
- Many WE commands, like Ctrl-Shift-T, Alt-Shift-S, etc., just say letters but don't work.
- WE commands again work if you manage to focus a control unaffected by this problem.
On Wed, Jan 27, 2010 at 02:28:59PM -0500, Doug Lee wrote:
I'll try, but I suspect I'll have issues because the Login screen has
a different top-level window than the rest of the app... so this
filter might need some tweaking as the user progresses
On Wed, Jan 27, 2010 at 02:25:06PM -0500, Aaron Smith wrote:
On 1/27/2010 2:19 PM, Doug Lee wrote:
myMSAAEventSource.Process = ClientInformation.ApplicationProcess, try
myMSAAEventSource.Window = ClientInformation.Overlap. I'm trying to
remember what we found out before we fixed it, and I think we found out
that the window filter includes all the children, which makes it a
viable work-around for process. Let me know if you find otherwise.
Aaron
--
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
Aaron Smith
GW Micro
Phone: 260/489-3671
Fax: 260/489-2608
WWW: http://www.gwmicro.com
FTP: ftp://ftp.gwmicro.com
Technical Support & Web Development
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@ssbbartgroup.com http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@ssbbartgroup.com http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
though it looked like an MSAA event issue for a long time, turned out
to be a totally different issue. It turns out that setting
Window.Type on some windows in this app causes problems, and I
happened to be doing that from inside an MSAA OnObjectFocus event sub.
I'm working this one out off list, partly because of the amount of
traffic it's generating. In case anyone else hits this issue though,
here are its indicators, by example:
I spot a window with type wtCustomControl (11). I figure out that
it's really a button, so I say Window.Type = wtButton (1). When it
works, Window.Type is 1 from then on. When it doesn't, though, the
following apply:
- Window.Type becomes wtUnknown (0).
- Attempting to set Window.Type again changes nothing.
- It is thus impossible even to set Window.Type back to wtCustom (11).
- No code error is thrown, and code does not stall; subsequent lines run.
- Many WE commands, like Ctrl-Shift-T, Alt-Shift-S, etc., just say letters but don't work.
- WE commands again work if you manage to focus a control unaffected by this problem.
On Wed, Jan 27, 2010 at 02:28:59PM -0500, Doug Lee wrote:
I'll try, but I suspect I'll have issues because the Login screen has
a different top-level window than the rest of the app... so this
filter might need some tweaking as the user progresses
On Wed, Jan 27, 2010 at 02:25:06PM -0500, Aaron Smith wrote:
On 1/27/2010 2:19 PM, Doug Lee wrote:
Does the bug you mention applyUnfortunately, I believe it does.
is there a workaround?Fortunately, I believe there is. Instead of doing
myMSAAEventSource.Process = ClientInformation.ApplicationProcess, try
myMSAAEventSource.Window = ClientInformation.Overlap. I'm trying to
remember what we found out before we fixed it, and I think we found out
that the window filter includes all the children, which makes it a
viable work-around for process. Let me know if you find otherwise.
Aaron
--
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
Aaron Smith
GW Micro
Phone: 260/489-3671
Fax: 260/489-2608
WWW: http://www.gwmicro.com
FTP: ftp://ftp.gwmicro.com
Technical Support & Web Development
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@ssbbartgroup.com http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@ssbbartgroup.com http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
