From:

 Chip Orange

Subject:

 RE: What's lost on SimulateEvent?

Date:

 Fri, Jan 29, 2010 8:53:02 pm

thanks Doug for this info. I hav vague memories of hitting this same issue
of not being able to set window.type.

Chip


-----Original Message-----
From: Doug Lee [mailto:doug.lee@ssbbartgroup.com]
Sent: Friday, January 29, 2010 2:35 PM
To: Aaron Smith; gw-scripting@gwmicro.com
Subject: Re: What's lost on SimulateEvent?

For 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:

Does the bug you mention apply

Unfortunately, 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, it was done." --Helen Keller