A lot of applications on Windows show plain message boxes just with "Yes"/"No" or "OK"/"Cancel" buttons. Often it gets worse on non-English Windows' that the text is in English, but the buttons are labeled in the Windows' language.
Is there no simple API to show a message box with own button labels, e.g. "Delete" or "Keep"?
There is indeed such a Win32 function. It is TaskDialogIndirect. Note that it was introduced in Vista and so if you are still attempting to support XP, then you would need to provide a fall back option for that platform.
Like DavidHeffernan said, you should use TaskDialogIndirect(), as it natively supports custom buttons. It is only available on Vista and later, though.
On XP and earlier, you can customize the button captions on a standard MessageBox() (or really, any customization you want) by using SetWindowsHookEx() to install a thread-local WH_CBT hook, or use SetWinEventHook(), to obtain the dialog's HWND when it is created, then you can manipulate the dialog however you want. You can use GetDlgItem() to get the HWND of the individual buttons (and can thus use standard API functions/messages with them), and/or use GetDlgItemText() to change their captions. The CtrlID of each button is the same value that MessageBox() returns when that button is clicked.
This Projct on Codeproject provides a pretty good drop in replacement for MessageBox, that allows to replace buttons labels among other features.
It is basically a rewritten MessageBox function that is a superset of the standard Windows MessageBox function. Full source code is provided so you can adapt is easily to your needs if needed.
And it's pure Win32, no MFC is involved here.
Related
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.
Is it usual to use a Dialog as main Windows? So without registering any user class via RegisterClassEx? Can I do everything I do via CreateWindow()? Why should I create controls such as buttons,editboxes etc via CreateWindow() instead of just making a Dialog and use it as main Window?
I'd also like to know main difference between a dialog and a windows and why use one the first instead of the second.
Thanks
Is it usual to use a Dialog as main Windows?
Yes, it is quite common.
So without registering any user class via RegisterClassEx?
A dialog is usually a predefined window class, so there usually no need for registering.
I'd also like to know main difference between a dialog and a windows and why use one the first instead of the second.
Well, two big differences would be that you cannot resize a dialog box and it has no minimize or maximize buttons (by default, but there are workarounds for this). Keep in mind the name, dialog box. In other words they are used for having a dialog with the user (receive input and displays messages to user). In a sense they are just like any other window, underneath CreateWindowxx, etc. is called, etc. However, they are somewhat predefined windows which can be made quickly and there are limitations to what you can do with them.
Also, a dialog uses a dialog procedure rather than a window procedure, which does some default processing for you, such as initializing some controls, etc.
Yes, an application can be dialog-based. There's even a Wizard for that if your'e using VisualStudio and MFC.
In VS2010, Create New Project > MFC Application. In "Application Type" select Dialog Based. Click through the rest of the Wizard, and you're off to the races.
Dialog-based applications are much simpler, architectually, than other designs such as Document/View. As such, simple things are much easier to "bang out" quickly, but the limitations of the design become apparent when you try to do more complex things. You could end up replicating much of the Doc/View architecture in your dialog-based app in order to build a production-quality Dialog-based application. In that case, did you really save yourself anything?
A dialog is a kind of window just as all of the various controls like buttons are really just windows. You can think of a dialog as being a kind of window with a lot of extra functionality to support the kinds of things that dialogs are used for.
There are two types of dialogs, modal which display and expect you to use them and then dismiss them, and non-modal which display but which do not capture and keep the input focus until they are dismissed. You can see these two types used in applications where a modal dialog is used to display an error or require the user to make some setting and a non-modal acts as a kind of tool box that stays displayed and when you need it, you click on it to do something and other times you are using some other window in the application.
Normally a dialog would not have a menu bar but would instead have all of its controls visible or easily accessible via tabs or some other type of presentation. Visual Studio and other IDEs have dialog designers to allow the placement of various controls along with wizards to allow the controls to be tied to classes and class members.
Which brings up a major difference between a dialog and a window. A window is kind of an empty page and to do things with the page requires more work. A dialog has tools that make the design easy however you are also constrained in large part by the toolbox.
If you have an application that is focused on basically allowing a user to specify certain settings and then do some task, a dialog works fairly well. If you have something that requires more complicated user interaction, an application window as the base from which all of your other dialogs and controls will be managed and manipulated will be more necessary.
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);
Is it possible to develop win32 UI application for Pocket PC with multiple dialogs
we need to display each dialog based on user input and hide previous dialog when current dialog is displayed on window.
Thanks in advance
Sure, that sounds a lot like standard application behavior, which is supported. The only thing not supported is MDI. Programmatically it's going to work just like on the desktop, so examples using calls to CreateWindow or CreateDialog will be applicable.