Hello Doug,
A good rule of thumb is if the event doesn't pass any data that you can
change on return then when the data is changed no other events are
called on it. For example Speech.OnSpeak is an event that sends the
text about to be sent to the synthesizer. Since the event passes the
starting text which you can modify and return then you are guaranteed
all Apps hooking this event will get the updated string until the last
App gets called and then it goes onto the synth. But events like
Window.OnChildFieldName just pass the window, not the field name text
that would be spoken so once an App sets the text and returns it, all
remaining Apps that hooked this event will not be called.
As to the order they get called, you should assume this is random. It
just depends on the order they are hooked.
We could modify things so although Window-Eyes doesn't give you the
starting string (well, string in this case) we could pass an empty
string or whatever the last Apps created and so on until all Apps get
the event.
But I'm wondering if this is necessary. Typically you are creating an
App to fix a problem and usually that problem is specific to an
application. So I'm not sure I agree with what you said about multiple
desktop window hooks for OnChildField* as common. Yes, you could do
this but it certainly wouldn't be the most efficient unless you truly
plan on fixing every possible Field* string for all appliations. I
think the events should be filtered as best they can to only fire on
windows you potentially are interested in. For example if you are only
fixing Firefox download manager dialog field names then only hook the
events for that dialog, not globally via the desktop. Can you give me a
common case where this isn't optimal or possible?
Regards,
Doug G
On 2/17/2011 9:14 AM, Doug Lee wrote:
Most WE events don't return values, but the OnFieldData/Name/Summary,
and their OnChildField* parallels, return strings or vbNull. My
understanding is that Window-Eyes speaks what these events return.
So say you have three applications loaded, all of which include a
ConnectEvent for OnChildFieldName from the Desktop window. They can
(and absolutely should of course) filter their responses by checking
for process Ids, but they still each have to return something - should
be vbNull.
So the question: How does Window-Eyes decide who to listen to? Does
it just speak the first non-null result it gets back, or does it speak
all non-null results from the different event functions? I assume if
it speaks any one of them, it would not go ahead and speak its own
default response as well.
Btw, I regard this scenario of multiple Desktop window hooks for
OnChildField* events as very likely, because it seems the safest way
to avoid problems if the top-level window of an application is not
constant. This is also very likely in the presence of pop-up dialogs
and such. My question is mostly so I can detect any interferance one
script might cause to another in this area.
