Hi Rick,
I just researched this further and found that Application.Exit does not
exit a .NET program unless it is based on a main Windows Form, e.g., as
explained in the excerpt below my name.
I read that the following code should work:
Application.Current.Shutdown()
BTW, another approach, which is admittedly a hack, might be to rename
the VS2008 executable, e.g., to msenv2008.exe. Of course, one might
then need to adjust the file name reference accordingly in a desktop
shortcut that launches VS2008.
Jamal
From the web page
http://msdn.microsoft.com/en-us/library/ms157894(v=vs.80).aspx
"The Exit method stops all running message loops on all threads and
closes all windows of the application. This method does not necessarily
force the application to exit. The Exit method is typically called from
within a message loop, and forces Run to return. To exit a message loop
for the current thread only, call ExitThread.
On 5/5/2012 3:37 PM, RicksPlace wrote:
Hi Jamal:
I have a script i developed in vb.net 2008 express.
It actually scripts vb.net 2010 Express so vb.net 2010 Express will
speak better.
When I associate the script with VB.net 2010 Express via WindowEyes it
also gets associated with vb.net 2008 Express since they use the same
module name.
When I want to work on the script in vb.net 2008 the script is started
which is not what I want. So, I thought I would put some code in the
script to check which version of vb.net was running and stop the
script if it was not vb.net 2010.
This has opened a whole can of worms.
Let me list a few of the current situations:
I tried using Application.exit but although it was executed the script
remained running.
Next I thought of killing the process but that is the executable
created by vb.net 2008 and may have spun off child processes which
would not be killed if only the main process is killed.
DTE offered a solution but it is not available to the Express modules
as you mentioned.
I tried the WindowEyes script status rotor hot key (insert-7) , thanks
to an idea from your ReLoad script but it stopped all scripts.
So I am sort of stuck for the moment.
As for DTE and the DOM, you are right.
The UIA Objects are there but since there is no EnvDTE available to
the express versions there is no access to the underlying DOM controls
- at least using that method.
Also, from what I've gathered so far the Automation Patterns available
do not allow for getting at the properties and methods of the
underlying controls either.
I want to be able to read the properties for a underlying control like
the TabNumber but have not yet figured out how, or if, this is going
to be possible.
I have VBNet2010Script working using UIA to read the UIA information
about any control I drop on the Forms Designer by moving the mouse
over it and hitting a windoweyes hot key I registered for that purpose.
But I wanted to put all the controls into an array and read them in
their proper TabNumber sequence.
Also I wanted to allow for clicking any of the controls in the array
and pass the keyboard input to the IDE to perform normal functions on
the selected control in the array.
I am getting some things to read better but that is about as far as I
have gotten so far and the EnvDTE situation has put a crimp in my
thought process.
so that's the story.
The EnvDTE is how I have seen samples access the underlying DOM so I
am looking for another method if one exists but I dont think so.
Later and let me know if you have any ideas.
Rick USA
----- Original Message -----
*From:* Jamal Mazrui <mailto:[email protected]>
*To:* [email protected] <mailto:[email protected]>
*Cc:* RicksPlace <mailto:[email protected]>
*Sent:* Saturday, May 05, 2012 8:36 AM
*Subject:* Re: Visual Studio Express Accessibility
Hi Rick,
I think the DTE object you mention is part of the VS DOM, which is
only available to commercial versions of Visual Studio. UIA,
however, is independent of the DOM, so works on the Express
versions as well. I think the DOM and UIA are independent of each
other. UIA (and MSAA) does include the ability to click, or
perform the default action, on an automation object, such as a button.
I'm not understanding the need to shut down processes other than
your VB.NET app. Doesn't the .NET Application.Exit() method work
to shut down the app?
If a user launches VS, wouldn't the user be the one to close that
application? Why would a Window-Eyes app be launching VS? I
thought the app just gets loaded once Window-Eyes notices that VS
(msenv.exe) has been launched.
Jamal
On 5/5/2012 8:06 AM, RicksPlace wrote:
Actually the Kill process I was thinking of was for an External
Script, not the IDE itself but it may pose the same problems if
any processes are started due to any context or content required
by the OS or compiler unknown to me.
Jamal has a couple of VBS scripts that work with App Manager
which may offer a conceptual solution to stop my script
programatically if I can understand the technicals.
The Reload Script would seem to interact with ScriptManager
so it may provide the underlying technicals to click the Stop
Button programatically or using a global WE Hot Key.
If you know of another script that pushes a button in the
ScriptManager let me know for additional research.
Jamal, if you are out there, is this feasible?
Rick USA
----- Original Message -----
*From:* RicksPlace <mailto:[email protected]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Saturday, May 05, 2012 6:43 AM
*Subject:* Visual Studio Express Accessibility
Hi:
I was looking into shutting down a Process from within VB.net
Express.
To ensure all Child-processes are shut down it appears folks
usually use something called the EnvDTE object.
This object also gives access to the running Process so you
can do things like click a button or change text in a TextBox
from another Process like a WindowEyes Script.
According to a member of the Microsoft Staff, a posting in a
Blog, the Express Versions do not expose the EnvDTE Object to
third party applications like a WindowEyes script.
This was a quote Business decission on the part of Microsoft.
This hampers using UIA, MSAA or any other method I know of to
make the Express versions of Visual Studio much more
accessible than they are already.
It also has thrown a monkey wrench into my plan to Kill the
running Process since Visual Studio, and I assume the Express
versions, spawn other processes that may be left hanging and
running if the Main Process is Killed without due process to
the child processes if I read it correctly.
I can still make some things much more readable with UIA,
MSAA and the WE Object Model but not do much, if anything,
that requires information from the Underlying Visual Studio
controls or any interaction with them via a script.
At least that is my understanding of the problem so far.
Since Application.Exit doesnt work, it handles clean up and
shut down messages while kill doesn't,perhaps the shut down
of a dummy form will work as Aaron used in his original example.
I either have to find a way to work around a focus problem
using a dummy window if I can, figure out why
Application.Exit doesn't work or find another method of
shutting the script down ensuring no objects or processes are
left hanging.
I hope Microsoft knows this decission sucks for blind users
of their free Express Versions of Visual Studio that work
extremely well for sighted users.
Later and I will be able to do a few things even without this
missing feature in the Visual Studio Express versions.
Rick USA
