 |
|
 |
i use this to traversal a window handle and generate a tree,i found it was successful in win7,but it was interrupt in xp,i dont know what's the reason,please help me!
|
|
|
|
 |
|
 |
Does the demo app work in XP?
|
|
|
|
 |
|
 |
There are errors in CXMSAALib_WinEventProc: AccessibleObjectFromEvent - "Unspecified Error" when running under SYSTEM account on XP (at 14:12 /interactive c:\test\XMSAALibTest.exe)
|
|
|
|
 |
|
 |
Were you able to determine the cause of these errors?
|
|
|
|
 |
|
 |
This application is working very fine for . Thank you so much for the post. Could you help me for one more case. Since I am new to this technology I don't have a fair idea about this technology
My doubt :
On the event handler functionality
When the application is triggered in call back function " MSAAEventProc " I want to know which parent application is it ? I will make it more clear. After the event handler is initiated and run the internet explorer with home page "google" this is what I am getting as output
Event handler: event=0x8005 hwnd=0xC078A
Name: Google
Description: ?
Location: (10, 149, 1356, 553)
Value: http://www.google.co.in/
But I want know is this event is triggered from Internet explorer. Please let me know how can I get the application name , Is there any method to know the source application name
Regards
Rajmohan
|
|
|
|
 |
|
 |
I'm using your EnumAccessible function to enumerate controls in Explorer and Firefox but the only controls that are shown are those in the menu/controls area on the top of the window and the status bar at the very bottom of the window. The area where the webpage is show is not enumerated. It doesn't seem to traverse down that branch. Have you seen this behavior? You're test app doesn't exhibit this behavior so it might be something weird I am doing. In my function pointer, I always return TRUE to continue the enumeration so I'm not accidentally stopping it somehow. If you have an insight I would appreciate it. This one has me stumped.
|
|
|
|
 |
|
 |
It doesn't seem to walk down the children when the parent is a pane, dialog, client, or document. I get these objects just not the children. This is a mystery.
|
|
|
|
 |
|
 |
Rensy Soft wrote: I get these objects just not the children.
What about AccExplorer? Does this work correctly?
|
|
|
|
 |
|
 |
I've experimented more and it seems that the main difference is whether or not your library get called from my main thread or a spawned thread. If I call it from my main thread (main()), everything is enumerated. If I use the same code in a spawned thread, the enumeration does not work on some branches (role: document, pane, etc). Have you tried your MSAA code in a thread? Did it work as expected?
|
|
|
|
 |
|
 |
Do you call CoInitialize() in your thread?
|
|
|
|
 |
|
|
 |
|
 |
Great work but i have tried to get the url of firefox but it fails, giving message "Failed to find browser adress bar".
Any help in this regard will be highly appreciated.
Thanks
|
|
|
|
 |
|
 |
Why is enumeration so slow? To enumerate IE it can take 5 to 10 seconds? Is this normal?
|
|
|
|
 |
|
|
 |
|
 |
Using the "Tree" menu of AccExplorer to "Expand Entire Hierarchy" shows typically more than 1000 nodes - roughly 1 millisecond per node is not outrageous for COM-calls between processes.
pg--az
modified on Monday, June 29, 2009 12:35 PM
|
|
|
|
 |
|
 |
Pressing "Enum All Browser Objects" in XMSAALib Test takes upwards of 10 seconds on firefox and 5+ on IE for cnn.com. I guess this is normal because AccExplorer is taking roughly the same time. 1 milli second per thousand nodes is not real world. Where are you getting that value?
|
|
|
|
 |
|
 |
Rensy Soft wrote: 1 milli second per thousand nodes is not real world. Where are you getting that value?
A great reference on Win32 concurrency issues is Joe Duffy's "Concurrent Programming on Windows". On page 195 begins the section "Message Waits: GUI and COM Message Pumping". There's a lot under-the-hood mystery sketched-and-hinted-at there, centered about MsgWaitForMultipleObjectsEx(). My assumption is that AccExplorer() as well as XMSAALib( I have not actually inspected the code, I just noticed your remark ), I assume that both of these do Out-of-Process-COM for *EACH* of these very many nodes.
The OPTIMAL scenario is that there is some dedicated thread in there, which is generally in a wait state on MsgWaitForMultipleObjectsEx(), waiting to do your bidding. But, this might easily not be true, offhand is seems more likely that the internal code does various things, and every now and then decides to "Pump Messages".
Sorry I have actually not done any timing study on the minimum-wait-scenario for out-of-process-COM-roundtrips, assuming the dedicated thread devoted to MsgWaitForMultipleObjectsEx(). I *have* over the years casually observed WILDLY varying wait times for COM messages, due to this fact that communication only happens when the other party "decides to pump messages", which routinely does happen in wildly varying ways.
I searched around a little - the Google Query (( COM IReadData HAWAII )) summons up the PDF article "Real-Time Support in COM" by D. Chen. at csdl.computer.org. Skimming down to "Table 2" on page 8, they list typical "connection" times of about 300 milliseconds and typical "Read" times of about 15 milliseconds, in the "Local" column. 15 milliseconds is of course less than 100-per-second, which roughly agrees with what we're seeing here.
pg--az
modified on Thursday, September 10, 2009 4:06 AM
|
|
|
|
 |
|
|
 |
|
 |
great article, which is what I looking for, thank you, I hope I'll also be able to write something to help other people ...
|
|
|
|
 |
|
|
 |
|
 |
Excellent article Hans, thanks a lot!
Dr.Luiji
Trust and you'll be trusted.
Try iPhone UI [ ^] a new fresh face for your Windows Mobile, here on Code Project.
|
|
|
|
 |
|
|
 |