Hi Again Chip: Ya, I have it pretty well down now. I have just finished a final test, at least for now. It demonstrates this fact, identifies the correct process to be used and verifies I am using the correct process. I also moved all logic into the root module to avoid any unforseen problems with the class that was instantiated to create a message pump. "This also matches the basic methodology that the gW sample used. I will post the results of this test in a few minutes. I think I need some help from GW now since I am out of ideas and everything seems correct to my understanding. Perhaps there is something wrong with my understanding but there might also be something wrong with the Windoweyes implementaion itself. I am just not sure. But, take a look through the next post to see what you think. Back in a minute. Rick usa ----- Original Message ----- From: Chip Orange To: gw-scripting@gwmicro.com Sent: Saturday, April 02, 2011 1:36 PM Subject: RE: External Script, ProcessID and Second Test Output Results
Hi Rick, * saving the result of the connectEvent method has no effect on what's going on; it's useful if you want to disconnect event handling later, but it's not required to maintain event handling. * what you pass into clientIdentify can be anything; they just want it to be unique, so they (gw) suggest it be the process id of your process. * as I said in a separate email, you have .applicationProcess which identifies the C# express application, and so should be used for MSAA work since it's the MSAA events related to this program you wish to work with. and you have .scriptProcess which you could pass into clientIdentify because it identified your vb.net app. Chip ------------------------------------------------------------------------------ From: RicksPlace [mailto:ofbgm...@mi.rr.com] Sent: Saturday, April 02, 2011 6:52 AM To: gw-scripting@gwmicro.com Subject: External Script, ProcessID and Second Test Output Results Hi Guys and... OK: so I have tried many, many paths of analysis yesterday but none of them resulted in a resolution to my problem. To review where my analysis now stands let's look at how GW does it in a VBS Script: Dim blockFocusEvent : Set blockFocusEvent = Nothing Above they create a user object variable and initialize it to nothing. As I understand it this is to maintain the state of the object which might change through iterations of the subsequent logic. It also instantiates the object which may, or not, be required for other reasons. Dim myMSAAEventSource : Set myMSAAEventSource = MSAAEventSource Above they create a user variable (MyMSAAEventSource) object and initialize it to the native Windoweyes MSAAEventSource Values. Again, it is likely required for state management and, or, other reasons. myMSAAEventSource.Process = ClientInformation.ApplicationProcess Above they set the user object variable MyMSAAEventSource Process property to whatever process is in the Native Windoweyes ClientInformation.ApplicationProcess. This is for filtering on the Overlap process, CSharp in my case, if I read it correctly. Dim msaaEventObjectFocus : msaaEventObjectFocus = 0 msaaEventObjectFocus = ConnectEvent(myMSAAEventSource, "OnObjectFocus", "OnObjectFocus") Above they create and set a user integer variable to a returned value from the Connect method. This method is monitoring the myMSAAEventSource user object created from the native Windoweyes MSAAEventSource object as with the BlockEvent method. Note that the user variable also might be used to maintain the state of the object somehow throughout iterations. Things to note: 1) In VBS they do not need nor use the ClientIdentify method. Therefore there is no grab of an external process id to put wherever the ClientIdentify method puts it for external scripts. Thus, there is no way to determine if the ClientInformation process is the same as it would be if the ClientIdentify method were used in a vBS Script for analysis. This should not be a problem as discussed below. 2) They assign the result of the ConnectEvent to a user defined variable as they do with the BlockEvent method. This can not be done with the Watch Event in VB.net since the WatchEvent is a sub. I do wonder if this could be a problem since there is the question of whether the WatchEvent would maintain it's state during iterations with no local variable as used in other methods in the VBS version. 3) They pull values directly from the ClientInformation object and not a user object variable in VBS. The use of a User Variable is required in an external script from what I can tell and should make no diference since it's value is assigned the native windoweyes ClientInformation object. Also, this maintains the state of that variable without question if I understand correctly. Just to see if assigning the process used in the ClientIdentify method could be assigned to filter the MyMSAAEventSource rather than the ClientInformation Process, I tried to assign the: System.Diagnostics.Process to the MyMSAAEventSource Process to use in Event Monitoring. I got the message that: Exception Thrown System.InvalidCastException: Unable to cast object of type 'System.Diagnostics.Process' to type 'WindowEyes.Process'. So this method of analysis is also out. That said, since the WatchEvent, the OnShutdown and the BlockEvents all use the ClientInformation version of the Process, I would think they would all work or none of them would work if the diference between the 2 process ids, the ClientIdentify process and the ClientInformation process were being problematic. The OnShutdown and the BlockEvents seem to be working correctly so I'm not sure this is relative to the problem in any event. summarySo Far: The ClientInformation process is suppose to be the Process of the Overlap Application, in our case I believe that should be the CSharp Application. Since the System CurrentProcess is diferent from the Overlap Process that would make sense since the Current Process might likely be the WindowEyes, or my external script, process and not the same as the overlap or the CSharp process. Thus it would seem that having 2 processes show up during analysis at these points in the logic flow would be correct and not likely related to the current problem of the WatchEvent method not working. Again, I can not assign a diferent process to neither the ClientInformation object nor the MyMSAAEventSource object to test and verify or negate the validity of this line of analysis; But, it makes sense that the two processes should exist and be used as they are in my code and as described above. So far the only major diference is that the VBS Connect Event method returns a variable maintained during event processing. The WatchEvent method used in a External script does not return a variable. My next path of analysis will be to restore the external script to it's original status where it worked except for the WatchEvent statement and where everything seemed to work if I opened CSharp under the IMMED window utility. Then I will attempt to monitor the existance of the WatchEvent method during testing somehow - not sure about that since it is a method, sub, and not a variable though. Also, I will try and nail down the processes for the CSharp Application in the earliest stages of the Main Module and Main sub using both the ClientInformation object and the system Process used in the ClientIdentify method. I noted that in the VB.net example GW put forth they did not use a Message Pump via the Context object which may, or not, have any bearing on this situation and my analysis of the Process used from the earliest stages of execution prior to creating the new context object withit's pump might shed some light on whether this might be problematic as well. Well... Later Guys: I'll post up again after the next batch of tests are done. My wife made me stop yesterday - she said my veins were popping out around my temples which is not a good thing for an old fat blind guy of 63! - grin. Rick USA
