What we would like is a way of using this dialog box in our applications of course. How could we do that?
One way would be to call it as an independent program. We could use the facilities for calling a program within the windows system, and pass our prompt in the command line parameters. This would work, but the problem of getting the string from the user would be quite complicated to solve. Programs can only return an error code, and in some situations this error code can only be from zero to 255. We can't pass pointers just like that from one program to another; we can't just pass a pointer to a character string as the result of the program.
Why?
Because windows, as other systems like linux, Solaris, and UNIX in general, uses a protected virtual address schema. The machine addresses that the program uses are virtual, as if the program was the only one running in the machine. It is the operating system and the CPU that does the translation of those virtual addresses into real RAM locations in the machine you are using. This means the addresses of each program aren't meaningful for another program. We can pass special 848g69i pointers (shared memory) within windows, but that's too advanced stuff for an introductory text, sorry.
But there are many other ways of solving this problem without costly interface development. What do we want? Let's get that clear first, worrying about implementation details later.
int GetString(char *prompt, char *buffer,int bufferlen);
This routine would return either true or false, depending if the user has pressed OK or cancelled the operation. If the user pressed OK, we would find the string that was entered in the buffer that we pass to GetString. To avoid any overflow problems, we would pass the length of the character string buffer, so that the GetString routine stops input when we reach that limit.
The C language supports code reuse. You can compile code that is useful in many situations and build libraries of routines that can be reused over and over again. The advantages are many:
The code has to be written once and debugged once.
The size of our program stays small, since we call a routine instead of repeating the code all over the place.
Function calls are the mechanism of code reuse since a function can be used in many situations. Libraries are just a collection of routines that are linked either directly or indirectly with the main program.
From the standpoint of the user of the library, not the one who is building it, the usage is quite simple:
You have to include the header file of the library to make the definition available to the compiler.
You use the functions or data
You add the library to the set of files that the linker uses to build your program.
This simplicity of usage makes libraries a good way to reuse and share the code between different applications.
Under windows we have two types of libraries:
Static libraries. These libraries are built in files that normally have the .lib extension and are linked with the program directly, i.e. they are passed to the linker as arguments. The linker takes the code of the needed functions from the library and copies the code into the program.
Dynamic libraries. These aren't copied into the main program, but are resolved at load time by the program loader. When you double-click a program's icon you activate a system program of windows called program loader that goes to the disk, finds the code for the executable you have associated with the icon, and loads it from disk into RAM. When doing this, the loader finds if the program needs any dynamic libraries, that normally have the .DLL extension, and reads their code too, linking it dynamically to the program being loaded.
Which one should we use in this application?
Static or not static? That is the question!
Our program needs a class registration before it can call the DialogBoxParam API. If we use the static library approach, we would have to require that the user of the library calls some initialization routine before, to allow us to register our class with windows.
But this would complicate the interface. We introduce with this requirement yet another thing that can go wrong with the program, yet another thing to remember.
A way out of this dilemma would be to take care of doing the registration automatically. We could setup an integer variable that would start as zero. Before calling our DialogBoxParam procedure we would test the value of this variable.
If it is zero it means that our class wasn't registered. We would register our class and set this variable to one, so that the next call finds a value different than zero and skips the class registration code.
We have to tell the IDE to produce a static library now, instead of a normal executable file. We do this by going into the linker configuration tab, and checking the library radio-button, like this:
|
|
You see the "Static library" radio-button checked. The name of the library is the name of the project with the .lib extension.
Now we are ready to change our WinMain. We change our WinMain function to be the GetString procedure, like this:
static char buffer[1024];
static int classRegistered;
int APIENTRY GetString(char *prompt, char *destbuffer,int bufferlen)
result = DialogBoxParam(hinst,
MAKEINTRESOURCE(IDD_MAINDIALOG),
NULL,
(DLGPROC) DialogFunc,
(int)prompt);
if (result == 1)
return result;
We have several things to explain here.
We move the declaration of our static buffer that was before further down, to the beginning of the file, so that we can use this buffer in the GetString procedure to copy its contents into the destination buffer.
We declare our flag for testing if the class has been registered as a static int, i.e. an integer visible only in this module. We do not need to initialize it to zero, since the C language guarantees that all non-explicitly initialized static variables will be set to zero when the program starts.
We modify the declarations of local variables in the GetString procedure, adding a result integer variable, and a HANDLE that will hold the instance of the current module. Before, we received this as a parameter in the arguments of WinMain, but now we have to get it by some other means. The solution is to call the GetModuleHandle API, to get this. We indicate it that we want the handle of the currently running executable by passing it a NULL parameter.
We test then our global flag classRegistered. If it is zero, we haven't registered the class, and we do it now. Afterwards, we set the variable to one, so that this piece of code will not be executed again.
We call our DialogBox procedure just like we did before, but now we assign its result to an integer variable and we test if the result is one (i.e. the user pressed OK). If that is the case, we copy the string from the temporary buffer to the destination buffer. Note that we use the strncpy function. This standard library function takes an extra parameter, a maximum length to copy. We do not want to overflow the destination buffer under any circumstances, so we only copy a maximum of bufferlen characters minus one, to account for the terminating zero of the string. We ensure afterwards that the string is zero terminated, and we return the result.
The rest of the program remains the same, so it is not shown. It is important to remember to get rid of that MessageBox call however!
We compile the library, and we want to test it, but. we need a test program. A library is not an executable by itself.
Besides this, we need a header file that the user of the library will use to get the prototype of our function. Its contents are very simple:
int GetString(char *prompt, char *destBuffer,int bufferlen);
and that's all.
Now, we have to define a new project that will contain the test code. We do that in the same way as we have created the other projects: we choose the 'Create project' option in the 'Project' menu bar, and we name it appropriately "testdialog".
We do NOT specify a windows application. Since our library should be independent whether it is called from a windows program or a console application, we should test that now.
|
|
Now, when creating the project, we ask the wizard to create a console application. We leave everything by default, but when we arrive at the linker settings dialog, we add our dialog.lib to the libraries entry field, like this:
Another issue to remember, is the following:
We need a resource file. Since in our library there are no resources, we have to add those resources to our test program. This is easy to do in this case: we just add the dialog.rc resource file to the project. The interface for the users of the library however is terrible. All programs that use our library will be forced to include somehow the resource for the dialog box! Including a resource in another resource file is difficult, to say the least.
Wow, this looks like a showstopper actually.
OK. This presents an unexpected and serious trouble for our library project, but we will not leave things at midway. We finish our test program by changing our "main" function, like this:
extern int APIENTRY GetString(char *prompt,char *buf,int len);
int main(void)
else printf("User cancelled!\n");
return 0;
|
|
When we start this program from the command line, we see:
This isn't that bad, for a start. We have a sophisticated line editor, complete with arrow interface to move around in the text, clipboard support built in, delete and backspace keys already taken care of, etc. If we would have to write ourselves an equivalent program, it would cost us probably days of development. To develop the clipboard interface already is quite a challenge.
But we are confronted to the problem of resources. Our static library idea was a dead end. We have to find something else.
The C language supports the concept of code reuse in the form of libraries. The static libraries are combined with the main application at link time (statically). They can't contain resources.
|
