I would like to know is there a way to drive an existing windows application? I want to execute operations in an application like filling out text fields in a form, hitting next and submit buttons, etc. Basically what a user would do, I wanted to automate those operations. What would be the best way to achieve this?
Thanks
Mukul
It is possible (with limitations and quirks), if that particular Windows application uses native windows (so-called) controls (UI elements). Qt, for example, paints UI elements "by hand", while MFC applications uses Win API UI native (and expanded) elements. So, it depends.
You can explore application and it's UI elements using Spy++ tool inside Visual Studio (there are free alternatives available). Using these tools, you can look up target window class name, ID and other attributes that would help you to find and identify elements of interest using Windows API functions.
One can use EnumDesktopWindows, FindWindowEx, FindWindow, and others, to find window and it's inner control of your interest. Then, using SendMessage you can send various messages to set focus, emulate mouse clicks, set text for Edit control, simulate button clicks, etc, etc.
You can write such a program using UI Automation, which allows a program to discover and use the GUI of another application. It's how accessibility tools like screen readers interact with your applications.
Related
Our agency has a Java web application that uses a third party Java applet as a TIFF viewer. In this application javascript spawns a separate window (and yes, it must be a separate window). We are currently using an in-house ActiveX control so that the HTML window can have the window state, window size and position, and screen device presisted and restored via localStorage. Our agency is IE11 only so for now using it is not a problem. It's embedded in the page and operates on the "containing window".
This control was made many years ago in VB6. It appears that Visual Studio doesn't support the creation of ActiveX controls, and I don't personally have the knowledge or skill to create one another way.
Please do not suggest the HTML DOM window and screen objects! Most answers I've searched for just refer to these! They can't get the entire browser window size (viewport + chrome + toolbars + titlebar), nor does javascript have any idea about Windows-specific things like window state and screen device (it's always the OS primary screen). I understand the HTML DOM can't be tied to anything OS-specific in order for it to be implementable on multiple platforms.
Up until now this control has worked pretty well - you can, for example, maximize on a given screen and restore the window to the same screen. But I realize that ActiveX won't be supported forever and it's IE only...It seems to me, though, that the need for such functionality can't be totally uncommon. I'm guessing that some may suggest that the application UI should be changed so that this is less of a problem - but being able to put the viewer on a different monitor from the application, and having that window be restored exactly to it's last position is important to us. I do understand that if you reuse that window the user only has to position it once, but we'd rather not require this of the user.
Question: are there any alternatives to interacting with the win32 API other than COM/ActiveX ? Are there any other methods of accurate window persistence that can know about screens other than the OS primary, and maximized/minimized/normal windows) that use something other than the Win32 API?
I need to create a Win32 application. I am using visual studio. I really like designing my application in Windows Form, which allows graphically designing my window.
However, I cannot use Windows Form (only). I have to use Win32 applicaition. Now, when I create Win32 application, I cannot figure to graphically design my window.
Is there a way to incorporate Windows Form in Win32 application? Or graphically design Win32 window?
(If there is a way to design Win32 applications GUI graphically and it's just me who could not figure it, I would appreciate resources or methods to do so.)
In a Win32 application, you can include a dialog resource that contains controls and layout information for a particular window. Visual Studio includes a graphical dialog resource editor, as do many other Win32 resource editing applications. This will be somewhat similar to what you're used to with the WinForms designer, albeit with a few limitations. Win32 is a much older technology than WinForms and wasn't really designed with RAD (rapid application development) principles in mind.
When you create a new Win32 project based on the template in Visual Studio, you already get one dialog resource created for you: the About box. If you double-click on your "ProjectName.rc" file in the Solution Explorer, then expand the "Dialog" resources folder, you'll see it. Double-clicking on it will bring up the Dialog Editor for this dialog window. You can add controls using the familiar Toolbox window, and customize them using the familiar Properties window.
You will still need to write code that displays the dialog window, of course. There are two basic methods of doing so:
The DialogBox function will display the dialog modally, which means that the user has to close the dialog before they can interact with the rest of your application. Inconvenient for the user, but rather convenient for the programmer because Windows runs the dialog's message loop for you.
The CreateDialog function will display a normal (non-modal) dialog, but requires that you write your own message loop for the dialog window, just as you would for a normal non-dialog window.
You could conceivably design all of the windows for your application this way, by adding separate dialog resources for each of them, but it is not necessarily a good idea. Part of learning a new UI framework is learning how to use that framework the way it is meant to be used. Creating controls and setting their properties through code at runtime is not really that difficult, and it is a lot more powerful than limiting yourself to a fixed layout. (In fact, even when you have a dialog resource with a fixed layout, you'll often want to write similar code to allow customizing those controls at runtime.)
I need to make minor modifications to a legacy Win32 application, but have no access to the original developer or source code. The application was not designed to be extended by third parties. What are my options for doing this?
The changes required are not extensive: I need to launch an external application when a specific text label is clicked.
Is it possible to access and modify the controls in the target application from an outside application?
What you are asking for can be accomplished by either using a SetWindowsHookEx() hook, or subclassing the label directly, to detect when the label is clicked. Your hook/subclass can then launch the external process.
If you need to react when a text is clicked, you could try to use the Microsoft UI Automation technology, and in this case, UI Automation Events.
Note that depending on how the application is written, it may or may not work.
You can try the cool Inspect and Accessible Event Watcher tools at least to check if its seems feasible.
I want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.
I'm currently working on a Win32 program which requires a main window containing many child window controls - buttons, listviews and so on. I believe the standard way to build such a window is to first call CreateWindow for the main window, then again for each of the controls.
As an easier option, I'm considering designing the main window using the resource editor's dialog box designer, then using CreateDialog to build the main window in one go.
By using a CLASS statement in the dialog box template, I should be able to get the main window to use a custom window class (and hence a custom window procedure) and thus avoid the window having any dialog-like behaviour. An example of this technique can be found in Charles Petzold's "Programming Windows": the HEXCALC program in chapter 11.
Are there any downsides to creating my main window in this way? If so, what are they? If not, why is this approach rarely used?
You don't get control of your main window message loop - the dialog manager handles it for you. On the other hand, the dialog manager handles keyboard accelerators, tab ordering and a number of other effects.
You'd be surprised what you can do with a standard dialog box - the windows volume control is implemented with about four different dialog boxes - it has a frame dialog box which in turn host hosts a tray window which in turn holds volume control dialog boxes, one for each app volume.
The only downside of CreateDialog I know of (as compared to repeated CreateWindow, not talking about some heavyweight framework, just Win32 vs Win32) is that dialog resources position child windows using dialog units. So the layout is dependent not only on DPI, but also on the user's theme settings (choice and size of font).
If any of your controls need to have fixed sizes in terms of pixels, you won't be happy with the dialog-provided positioning and will need to go through and move all the child windows after the fact.
So yes, you can use CreateDialog as a shortcut for creating a bunch of windows with specified classes and styles. But no, you can't do your layout in the dialog editor.
OTOH, you could store the DLU <-> pixel conversion used on your design machine, and then learn enough about parsing the DIALOG resource internal format to pull out the positioning information, then convert to pixels and correct the positioning in more automated fashion.
You will be able to have the full control over your window, even if it was created with CreateDialog.
Normally, when you create your own window (of your class), the window procedure used is the one that you registered with the class. OTOH windows created via CreateDialog will have the dialog standard window procedure (DefDlgProc), which will mostly invoke your supplied "dialog handler".
If you want to have full control of all the messages you may replace the window proc of the newly created window right after its creation. Just call SetWindowLongPtr with GWLP_WNDPROC parameter. Still, you may do the auto processing of some dialog-specific things by calling IsDialogMessage within your procedure.
There is no downside whatsoever.
Why is it rarely used? Because:
People normally use DialogBox instead, since that is easier for simpler cases.
For more complex cases, people use things like MFC or ATL (or some external library like GTk or Qt), and don't bother with native Win32 graphics.
There are no downsides using the Windows SDK, internally libraries like MFC use the Windows SDK .
People tend to use libraries like MFC over Windows SDK, as libaries have the readymade stuff. However Windows SDK calls are faster than library calls, so in some situations developers call Windows SDK directly .
CButton btnOk ;
btnOK.Create(_T("Press Me"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,CRect(100,100,300,300), pParentWnd, 1);
is similar to the following code ,
HWND hWnd = CreateWindow("BUTTON","Press Me",WS_CHILD|WS_POPUP|BS_DEFPUSHBUTTON,100,100,300,300,NULL,NULL,GetModuleHandle(NULL),NULL);
ShowWindow(hWnd,SW_SHOW);