Pythonic control of VMware -- ctypes does not provide access to 'menu' gui-control.
zapazap at yahoo.com
Tue Mar 2 05:07:43 CET 2004
"Michael Geary" <Mike at DeleteThis.Geary.com> wrote in message news:<10470sbrjkdh1b2 at corp.supernews.com>...
> If you are trying to close an application, I wouldn't access its menu at
> all. The normal way to close a Windows app is to send or post a WM_CLOSE
> message to its main window.
Noted, and my intent is to bypass the menu as much as possible when
driving the app. But without documentation of the app's API, I have
no obvious (to me) recourse but using the menu. In the unittest, I
closed the app with the menu in order to exercise the menu. The app
closing is just a convenient side effect :-)
> If you need to find out more about how an application is structured,
> Winspector Spy may be useful: http://www.windows-spy.com/
And this may be just the thing I am looking for, maybe even to
bypass the menu altogether. You are keeping my hope alive, thanks!
> Won't the user still be able to press Ctrl+Alt (or whatever you set the
> hotkey to) to break out of full screen mode and get back to the host system?
Probably. My concern is less over determined crakers than over teachers
freaking out when the VM leaves full screen mode -every time- the host
does something to it. (I have hopes of deploying this in a school setting,
with teachers modifying and snapshoting the students' VM, without the
teacher having to know that it is a VM at all.) Disabling the Ctrl+Alt
would indeed be nice, but bulletproofing is not a priority at this stage.
Indeed, at this stage, I want this to be automated for my own purposes,
because I am both lazy and careless in routine tasks on my own machine!
Here I do not mind the VM leaving full screen mode. I am disciplined
enough to "sit on my hands" while it does it's thing. Students may not
> Don't use os.system to run a program in Windows....
> You can use os.startfile to run a program using the ShellExecute function...
> Or use win32api.ShellExecute...
> If you were coding in C, I would recommend using ShellExecuteEx instead of
> ShellExecute. ShellExecuteEx gives you the process and thread handles to the
> application, so you can use the WaitForInputIdle() function instead of an
> unreliable time delay.
> I don't see a wrapper for ShellExecuteEx in win32api, but you could probably
> do it with ctypes.
That is new to me, and does sound interesting.
> The difference between PostMessage and SendMessage is that SendMessage waits
> until the target window function returns, so you wouldn't need the delay.
> > def get_hwnds(text):
> > """
> > Return list of all top level hwnds with specified
> > text in the title.
> > """
> > fn = win32gui.GetWindowText
> > list = 
> > win32gui.EnumWindows( (lambda hwnd,acc: acc.append(hwnd)), list)
> > return [ hwnd for hwnd in list if text in fn(hwnd) ]
> This doesn't seem like a good idea. Some unrelated window could have the
> same text in its title.
> Instead of GetWindowText, I'd use win32gui.GetClassName and look for the
> window class name you want. You can use Winspector Spy to find the class
> name for any window.
> There's no guarantee that class names will be unique either, but it's a lot
> better than using window titles. You could check both.
> A general comment about closing applications: As you know, many apps will
> put up a confirmation dialog box when you close them. In your Notepad test,
> what if the user had edited the text? Notepad would put up a "do you want to
> save" dialog and your code would take the assert. VMware always puts up a
> confirmation message box if the VM is running. SendMessage(WM_CLOSE) would
> avoid this problem by waiting for the WM_CLOSE message to return.
Yup, I agree - for my project, but not this particular unittest. Which
is also why I do not bother to deal with closing dialog boxes. My test
should never cause a dialog to appear, and I wanted to trim it to the
bare minimum that shows the problem. (Perhaps I need not have had the
test exercise both Notepad and Freecell? One working example may have
I will check windows-spy and hope that I do not face too steep a learning
curve regarding windows innards (which the menu route would have avoided!)
Thank you Mike. Your comments are appreciated, and
More information about the Python-list