There was another way of informing the user that text must be entered: a MessageBox call, telling him/her precisely what is wrong. This alternative, making something explicit with a message, or implicit, like the solution we implemented above appears very often in windows programming, and it is v 636i82g ery difficult to give a general solution to it. It depends a lot of course, upon the application and its general style. But personally, I prefer explicit error messages rather than implicit ones. When you receive an error message, you know exactly what is wrong and you can take easily steps to correct it. When you see a menu item disabled, it is surely NOT evident what the hell is happening and why the software is disabling those options.
But there are other user-interface considerations in our dialog box to take into account too.
One of them is more or less evident when you see how small the letters in the edit field are. Dialog boxes use a default font that shows very thin and small characters. It would be much better if we would change that font to a bigger one.
In the initialization procedure, we set the font of the edit field to a predefined font. Windows comes with several predefined items, ready for you to use without much work. One of them is the System font that comes in two flavors: monospaced, and proportional. We use the monospaced one. Our initialization procedure then, looks now like this:
static int InitializeApp(HWND hDlg,WPARAM wParam, LPARAM lParam)
A HFONT is a font "handle", i.e. an integer that represents a font for windows. We get that integer using the GetStockObject API. This function receives an integer code indicating which object we are interested in and returns it. There are several types of object we can get from it: fonts, brushes, pens, etc.
Yet another point missing in our dialog box is a correct title, or prompt. The title of our dialog is now just "dialog". This tells the user nothing at all. A friendlier interface would tell the user what data the software is expecting from him/her. We could change the title of the dialog to a more meaningful string.
The program calling our dialog procedure could give this string as a parameter to the dialog box. Dialog boxes can receive parameters, as any other procedure. They receive them in the parameters passed to the WM_INITDIALOG message.
A closer look to the documentation of the WM_INITDIALOG message tell us that the lParam message parameter contains for the WM_INITDIALOG 32 bits of data passed in the last parameter of an API called DialogBoxParam.
We have to modify our calling sequence to the dialog, and instead of using DialogBox we use the DialogBoxParam API. Looking into our program, we see that the DialogBox API was called in our WinMain function (see above). We should modify this call then, but a new problem appears: where does WinMain know which string to pass to the DialogBoxParam API?
Well, we could decide that this string would be the parameters passed to WinMain in the lpCmdLine argument. This is the most flexible way. We modify then the call to DialogBox like follows:
return DialogBoxParam (hinst,
MAKEINTRESOURCE(IDD_MAINDIALOG),
NULL, (DLGPROC) DialogFunc,
(int)lpCmdLine);
Since our dialog box is now constructed with DialogBoxParam, we receive in the lParam message parameter the same pointer that we gave to the DialogBoxParam API. Now, we have just to set that text in the caption of our dialog box and it's done. We do that (again) in our initialization procedure by adding:
SetWindowText(hDlg, (char *)lParam);
The SetWindowText API sets the caption text of a window, if that window has a caption bar of course. To test this, we have to tell Wedit to pass a command line argument to the program when it calls the debugger or executes the program with Ctrl+F5. We do this by selecting the "debugger" tab in the configuration of wedit:
The debugger tab is in the upper left corner. When we select it, we arrive at the following tab:
|
|
Note the first line "Command line arguments to pass to program". There, we write the string that we want shown in the dialog box.
When now we press Ctrl+F5, we see our dialog box like this:
|
|
Nice, we can pass our dialog box a "prompt" string. This makes our dialog box more useful as a general input routine. Remember that the objective of this series of sections was to introduce you a general routine to input a character string from the user. We are getting nearer.
Still, there is one more consideration that we haven't solved yet. We have a buffer of a limited length, i.e. 1024 characters. We would like to limit the text that the user can enter in the dialog box so that we avoid overflowing our buffer. We can do this with the message EM_SETLIMITTEXT. We have to send this message to the control when we start the dialog box, so that the limit will be effective before the user has an occasion of overflowing it. We add then
SendDlgItemMessage(hDlg,IDENTRYFIELD,
EM_SETLIMITTEXT,512,0);
|
