I am trying to write a script using pywinauto to open a repository in Informatica powercenter workflow manager (v9.6.1)
After the below lines are executed, I get the context menu with the connect option as in the screenshot. Also notice the 'connect' button on the toolbar stays grayed out. If I use the actual mouse and click on the treeview item for the repository I want to connect to, the connect button turns green and enabled. But not when pywinauto sends the right click.
from pywinauto.application import Application
from pywinauto.keyboard import SendKeys
import time
app = Application().Start(cmd_line=r'C:\PowerCenterClient\client\bin\pmwflmgr.exe')
informaticaworkflowmanager = app[u'Informatica::WorkflowManager']
informaticaworkflowmanager.Wait('ready')
time.sleep(2)
systreeview = informaticaworkflowmanager[u'TreeView']
tree_item = systreeview.GetItem([u'Repositories', u'REP'])
tree_item.Select()
tree_item.Click(button='right',double=True,where='icon')
I tried using SendKeys to send 'c' followed by {ENTER} and it just returns without doing anything. Also if I use the actual keyboard on the right click context menu generated after the above pywinauto steps run- it selects the connect menu when i press c , but it just doesn't do anything when I press Enter. I think somehow the connect function is not enabled.
I am clueless if any other input is required by the application to enable it. I also tried using the informaticaworkflowmanager.MenuItem(u'&Repository->&Connect...') option but to no avail- it says it is disabled.
Any pointers to help get pywinauto to open a repository are welcome!
Just summarizing the comments...
First try running the script as Administrator. If it doesn't help, use method click_input(). It runs real click like a user does. Method click() sends WM_CLICK or BM_CLICK which is probably not handled by the app in grayed button state.
If you run the script as Administrator, it should inherit privileges for child process by default. There is no special flag in method start() because some functions may not work if target app process has higher privileges. Anyway elevation usually requires confirmation from user and this Security Confirmation dialog can't be automated by OS design (even click_input() with hard coded coordinates won't work while this dialog was shown, I checked it a while ago).
So when using Qt to build user interfaces, you all know that .ui files (forms) open in Designer mode by default, and that if you manually switch back to the Editor, then this message appears "This file can only be edited in Designer-mode".
Well, for some reason, and at some point, my file now opens BY DEFAULT in the editor, and the message does not show up. Worse, when manually switching to Designer mode, the main editing field is gray and empty and none of my stuff shows up ... Also no scroll bars or anything.
EDIT : actually, it is whichever form was loaded last that appears. And it is editable and all ... only the drop-down menu with the file name clearly indicates that it is MY file that is opened. When I perform an edit, then the edit is performed to this same last-opened form, and is reflected upon compiling. My display remains unchanged to the state that it had the last time that I was able to open it in the Designer.
EDIT : Also, along with the fact that my .ui file now opens by default in the Editor, it is also editable there like any other source file. But edits don't seem to bother, I modified some stuff or added gibberish, and it never showed after compiling nor did the compiler ever complaine ...
What's going on ? What did I do ? I have no crash nor any recent weird events to report ... It just suddenly started happening.
Thanks in advance for any clues,
Charles
My Tk application has a main window, when executing, new window arises to show the running progress. I want all the events (mouse, keyboard, etc) are directed to the progress window, so when program is runned, user cannot interact with the main window, and must wait until execution is done and progress window destroyed.
I tried using grab to handle this.
grab set .progress_window
But it doesn't work. The progress window still disappears when mouse clicked somewhere outside it.
grab set -global .progress_window seems work but it block all the other windows running on my computer.
How to solve this problem?
Thank you so much.
You might need this too to keep it on top:
wm transient .progress_window .
Also, see how Tk itself creates modal dialogs.
There are some hoops to go through to get it fully right, e.g.:
https://github.com/tcltk/tk/blob/master/library/dialog.tcl
I am invoking the "uiimport" command within a program, opening the Import Wizard to display some data. I would like to be able to automatically close the Wizard within a function (equivalent to "close(gcf)" for a figure), as opposed to having to click "Finish" or "Cancel" or whatever. Is there a way to do this, or should I just find a different way to display the data?
TIA for your help.
I would find a better way to show the data. uiimport is modal, so execution is suspended until it closes, so the script that started it cannot close it.
I am using Windows, and I have two monitors.
Some applications will always start on my primary monitor, no matter where they were when I closed them.
Others will always start on the secondary monitor, no matter where they were when I closed them.
Is there a registry setting buried somewhere, which I can manipulate to control which monitor applications launch into by default?
#rp: I have Ultramon, and I agree that it is indispensable, to the point that Microsoft should buy it and incorporate it into their OS. But as you said, it doesn't let you control the default monitor a program launches into.
Here's what I've found. If you want an app to open on your secondary monitor by default do the following:
1. Open the application.
2. Re-size the window so that it is not maximized or minimized.
3. Move the window to the monitor you want it to open on by default.
4. Close the application. Do not re-size prior to closing.
5. Open the application.
It should open on the monitor you just moved it to and closed it on.
6. Maximize the window.
The application will now open on this monitor by default. If you want to change it to another monitor, just follow steps 1-6 again.
Correctly written Windows apps that want to save their location from run to run will save the results of GetWindowPlacement() before shutting down, then use SetWindowPlacement() on startup to restore their position.
Frequently, apps will store the results of GetWindowPlacement() in the registry as a REG_BINARY for easy use.
The WINDOWPLACEMENTroute has many advantages over other methods:
Handles the case where the screen resolution changed since the last run: SetWindowPlacement() will automatically ensure that the window is not entirely offscreen
Saves the state (minimized/maximized) but also saves the restored (normal) size and position
Handles desktop metrics correctly, compensating for the taskbar position, etc. (i.e. uses "workspace coordinates" instead of "screen coordinates" -- techniques that rely on saving screen coordinates may suffer from the "walking windows" problem where a window will always appear a little lower each time if the user has a toolbar at the top of the screen).
Finally, programs that handle window restoration properly will take into account the nCmdShow parameter passed in from the shell. This parameter is set in the shortcut that launches the application (Normal, Minimized, Maximize):
if(nCmdShow != SW_SHOWNORMAL)
placement.showCmd = nCmdShow; //allow shortcut to override
For non-Win32 applications, it's important to be sure that the method you're using to save/restore window position eventually uses the same underlying call, otherwise (like Java Swing's setBounds()/getBounds() problem) you'll end up writing a lot of extra code to re-implement functionality that's already there in the WINDOWPLACEMENT functions.
It's not exactly the answer to this question but I dealt with this problem with the Shift + Win + [left,right] arrow keys shortcut. You can move the currently active window to another monitor with it.
Get UltraMon. Quickly.
http://realtimesoft.com/ultramon/
It doesn't let you specify what monitor an app starts on, but it lets you move an app to the another monitor, and keep its aspect ratio intact, with one mouse click. It is a very handy utility.
Most programs will start where you last left them. So if you have two monitors at work, but only one at home, it's possible to start you laptop at home and not see the apps running on the other monitor (which now isn't there). UltrMon also lets you move those orphan apps back to the main screen quickly and easily.
I'm fairly sure the primary monitor is the default. If the app was coded decently, when it's closed, it'll remember where it was last at and will reopen there, but -- as you've noticed -- it isn't a default behavior.
EDIT: The way I usually do it is to have the location stored in the app's settings. On load, if there is no value for them, it defaults to the center of the screen. On closing of the form, it records its position. That way, whenever it opens, it's where it was last. I don't know of a simple way to tell it to launch onto the second monitor the first time automatically, however.
-- Kevin Fairchild
Important note: If you remember the position of your application and shutdown and then start up again at that position, keep in mind that the user's monitor configuration may have changed while your application was closed.
Laptop users, for example, frequently change their display configuration. When docked there may be a 2nd monitor that disappears when undocked. If the user closes an application that was running on the 2nd monitor and the re-opens the application when the monitor is disconnected, restoring the window to the previous coordinates will leave it completely off-screen.
To figure out how big the display really is, check out GetSystemMetrics.
So I had this issue with Adobe Reader 9.0. Somehow the program forgot to open on my right monitor and was consistently opening on my left monitor. Most programs allow you to drag it over, maximize the screen, and then close it out and it will remember. Well, with Adobe, I had to drag it over and then close it before maximizing it, in order for Windows to remember which screen to open it in next time. Once you set it to the correct monitor, then you can maximize it. I think this is stupid, since almost all windows programs remember it automatically without try to rig a way for XP to remember.
So I agree there are some apps that you can configured to open on one screen by maximizing or right clicking and moving/sizing screen, then close and reopen. However, there are others that will only open on the main screen.
What I've done to resolve: set the monitor you prefer stubborn apps to open on, as monitor 1 and the your other monitor as 2, then change your monitor 2 to be the primary - so your desktop settings and start bar remain. Hope this helps.
Do not hold me to this but I am pretty sure it depends on the application it self. I know many always open on the main monitor, some will reopen to the same monitor they were previously run in, and some you can set. I know for example I have shortcuts to open command windows to particular directories, and each has an option in their properties to the location to open the window in. While Outlook just remembers and opens in the last screen it was open in. Then other apps open in what ever window the current focus is in.
So I am not sure there is a way to tell every program where to open. Hope that helps some.
I've noticed that if I put a shortcut on my desktop on one screen the launched application may appear on that screen (if that app doesn't reposition itself).
This also applies to running things from Windows Explorer - if Explorer is on one screen the launched application will pick that monitor to use.
Again - I think this is when the launching application specifies the default (windows managed) position. Most applications seem to override this default behavior in some way.
A simple window created like so will do this:
hWnd = CreateWindow(windowClass, windowTitle, WS_VISIBLE | WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, SW_SHOW, CW_USEDEFAULT, 0, NULL, NULL, hInst, NULL);
Right click the shortcut and select properties.
Make sure you are on the "Shortcut" Tab.
Select the RUN drop down box and change it to Maximized.
This may assist in launching the program in full screen on the primary monitor.