Just so I understand, are you guys saying that .NET is not a good framework for scripting with WE right now? It should be, because then why else would there be samples in C# provided?
From: BT [mailto:[email protected]] Sent: Wednesday, April 11, 2012 2:28 PM To: [email protected] Subject: Re: WE And Microsoft Development Environments Hi Rick, Yes, I had corrected myself, but reading things out of order results in this. The messaging was actually posting inside the windows message which I believe is down in the Windows object itself. Doug said that the new approach was not going to be standard according to what Doug had said. I just typed to quickly and my brain took the easy statement and not the correct one, but I had corrected it as I am sure you read after sending this one. I have not used a windows message yet, so I could not comment any further on this. But, having said that, I may look into it to fix my issue on the WMI event for OnObjectReady not being captured inside of WE but I could do it outside of WE through an outside app. Who knows, I may actually be experimenting on this soon. Too many pressing issues at the moment. Bruce Sent: Wednesday, April 11, 2012 4:50 AM Subject: Re: WE And Microsoft Development Environments Thanks for the reminder Bruce. I do remember him talking about message processing and a problem I think I was having with a message box but that is not what I am looking for in this post. I am talking about a message switching problem related to using an external script and a problem with outside messages hitting the process if I remember that situation correctly. Anyway, that should not be a problem if someone has used an external script to do some processing against the .net environment outside the few objects available to scripts like VBS. Perhaps something using a .net application as a script or even the newer Power Scripting tools. I would like to use some of the more advanced programming features of a full-blown language including forms, databases etc... which are doable in VBS, Chip has demonstrated them, but in VBS there is a very limited access to the .net platform. Rick USA ----- Original Message ----- From: BT<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Sent: Tuesday, April 10, 2012 1:05 PM Subject: Re: WE And Microsoft Development Environments Hi Rick, Yes, I think all you would have to do is download that session he was talking in and you will find out that he specifically mentions the Windows Messaging, message Box, issue. Microsoft had strayed away once again on standards... Bruce Sent: Tuesday, April 10, 2012 12:57 PM Subject: Re: WE And Microsoft Development Environments Thanks Bruce: I think it may have been something else but then again, I dont know and that's why I'm asking: 1) The state of Native UIA handling and Operations within WE and within the Scripting Environment; 2) The state of any production External Scripts accessing what would have been MSAA objects and properties and methods within the .net Framework; And 3) how far along they are with handling WPF in WE. If I remember Doug had mentioned that WPF was a high priority item on the list of things to be done along with UIA support and the new Internet standards. But, I dont remember him addressing conflicts in message processing as related to external scripts but I may have just forgotten it if he did and still would like to know if anyone has an external .net script working handling MSAA or UIA operations in place these several months later. Thanks for the heads up though Bruce. Rick uSA ----- Original Message ----- From: BT<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Sent: Tuesday, April 10, 2012 10:41 AM Subject: Re: WE And Microsoft Development Environments Hi Rick, I think Doug himself had set during Chip's scripting class that the UI messaging had been changed by Microsoft and was not working as expected. I do know that changes were going to happen, but when is anyone's guess. This could be your problem with the messaging... Bruce Sent: Tuesday, April 10, 2012 7:03 AM Subject: WE And Microsoft Development Environments Hi: It has been some time now since I mucked about with scripting. A discussion about VS 2010 has come up on the Blind Programming list and gave me reason to check in on this subject asking 3 questions. First: Has WE developed full support for WPF yet, it has been a couple of years now I have heard you have been working on it but haven't heard if you have full support in WE and nothing about scripting; Second: Has anyone built a fully functioning external script accessing the .net FrameWork Objects, not just the handful available to VBS. I tried some time ago but ran into problems with message processing and never did get it to work properly when attempting to work with MSAA Objects, Properties and Methods, finally having to give up due to time constraints. Note that PowerShell and all the .net languages have full access to the .net FrameWork objects, properties and methods if I remember correctly. Other languages may be an option as well but I am most familiar with the above development environment. Finally: There is the ongoing question about Native UIA support. Aaron said some of it is being folded into the MSAA Object; But, I would like to know when actual support will be available if possible since everything Microsoft is putting out is now using UIA, WPF and, of course, the .net FrameWork. Anyway, I wanted to respond in a more accurate manner to the thread on the Blind Programming list about using the WindowEyes Scripting Platform and scripting of Visual Studio 2010 and all the other Microsoft DeskTop, Mobile, Web, DataBase and Project Management Development packages that are now using WPF, UIA and the .net FrameWork. Thanks: Rick USA
