Hi Kate,
It is OK to do and some times a pain trying to find .vbs examples but they
still are there depending on how it is approached.
I have noted the other examples are there and the issue at the moment is to
get the UI up to date with the rest.
For it is constantly changing and the fear is to do things so earlier in
this Microsoft thing that you might get burnt on it.
Keep doing what you are doing but be very cautious in UI stuff. Python is a
good thing to use along with the others. But everything is constantly changing
and even Python has limitations, depending on what you are using and the
compile date version of it, for errors are always there, along with some stuff
not running because of the compile date.
Bruce
Sent: Wednesday, April 11, 2012 7:12 PM
Subject: RE: WE And Microsoft Development Environments
That's annoying considering PowerShell and C# are more common nowadays than
are VBScript and WSH. In fact, for scripting, how many sites have I seen now
that recommend PS over VBS? Many. It'd be so unreasonable to count them. In
fact, you have to look beyond microsoft now to get VBS resources, and to be
honest, I find it more worth my time to focus on newer cutting-edge
technologies rather than putting all of my efforts into older ones because
companies won't move on. One of the main reasons for my buying WE in the first
place was for it's scripting model so that when I become fluent in C#.net and
Python (Pywin32 can make Python compatible with WSH) , I can handle my own
accessibility needs on the job instead of having to have people come out and
take care of it. I mean, what's so wrong with relying more on .NET and it's
framework? .NET is a fine wrapper around COM, so why are there so many issues
connecting to it using WE's model?
From: RicksPlace [mailto:[email protected]]
Sent: Wednesday, April 11, 2012 6:22 PM
To: [email protected]
Subject: Re: WE And Microsoft Development Environments
Hi Kate: I played with trying to create a script in vb.net some time ago.
I was able to do a few things and get some things wired up and working. I
never got MSAA working properly and had some other problems which I couldn't
resolve.
I ran out of time and had to give up on the project.
I was hoping someone had created a full-blown app in one of the .net
languages using MSAA and many of the other COM tools available in the WE model
but havent heard of one yet.
Rick USA
----- Original Message -----
From: Katherine Moss
To: [email protected]
Sent: Wednesday, April 11, 2012 4:06 PM
Subject: RE: WE And Microsoft Development Environments
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
To: [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
To: [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
