Programmers Notes on the File Search Program

An easy way to read this file is to open it up in Notepad and turn on word wrap.

This file contains some quick notes on the File Search program and its development. I hope this example and these notes prove to be helpful to programmers starting out with the BC++ 4.0 product.

File Search was written entirely using the AppExpert and ClassExpert features of Borland C++ 4.0.  This is actually the second version of this program. The first was written with BC++ 3.1 and OWL 1.

Generation of this program was pleasantly quick and easy.  I decided to use AppExpert to generate the framework for the program instead of converting the original using OWLCVT. The reason for this was that I wanted to substantially change the presentation of the program. I changed from a single window using a listbox to show data to an MDI application.  I also added the status bar at the end of the window and help file support.

Generation of the framework was painless and quick.  Within 10 minutes of starting I had the basic MDI framework with status bar and help file support in place. (Generating the acutal help file was, of course, another matter entirely :-> )  Another half hour or so and I had customized the menu and status bars to what I wanted. This was VERY NICE.

The generation of the remainder of the program (except the help file) consisted of using the ClassExpert to add handlers for the menu items. I then simply cut and pasted the code for the menu handlers from the original application to the new one.  In all, it probably took me less than 5 hours to completely convert the original application to the new format and get it working. A delightful experience.

Now for some of the things that I got temporarily hung up on as I went:

If BWCC style controls is selected, the AppExpert, in generating the about box dialog template, uses a new class called bordlg_gray.  This class is defined in the BWCC.DLL provided with BC++ 4.0, but is not supported in previous versions of BWCC.DLL.  If you want your application to be compatible with the older BWCC.DLL, the easiest way is to manually change the class of the about box template back to BorDlg.

Probably the biggest hangup I had was with the MDI child client windows.  Given selections for an MDI application and a TWindow as the Child window client class, AppExpert generates the following code for the constructor of the TMDIChild class: (Note that TMDIChild is actually derived from TFrameWindow, and therefore needs a client window where all the work is done)

testMDIChild::testMDIChild (TMDIClient &parent, const char far *title, TWindow *clientWnd,
      BOOL shrinkToClient, TModule *module)
    : TMDIChild (parent, title, clientWnd == 0 ? new TWindow(0, "") : clientWnd,
      shrinkToClient, module)
{
}

AppExpert also generates a routine in the MDI client class called OpenWindow. This routine called the testMDIChild constructor with NULL for the clientWnd parameter. The result was therefore a TWindow as the client window of the testMDIChild class.

Given this configuration, the child window shows up, but it is essentially non-functional. You can not draw on it, nor can you receive input from it (mouse messages, etc.)

It took me a while to figure out what was supposed to be done here.  The intent is that you create your own class for the child's client window.  This derived class then handles all painting and other events you want handled in the MDI child window. You can then handle this in a couple of ways.

1) Modify OpenWindow to create an instance of your specific derived class. OpenWindow would then pass this instance as the clientWnd parameter of the MDIchild window constructor, thereby preventing the creation of the default TWindow parameter.

2) Modify the MDIchild constructor to create an instance of your derived class instead of a TWindow.

I chose to use the second method. There were a couple of factors in this decision:

1) All of the child's client windows in the File Search application would be of the same class. There was therefore no need to be able to pass differenct classes to the MDIchild class for the client window.

2) I needed to add a parameter to the MDIchild class constructor which would be passed on to the constructor of the client windows class. Since I needed to modify the MDIchild class constructor anyways, this seemed like the easiest way to resolve the above problem. I therefore ended up with the following MDIChild class constructor:

filesrchMDIChild::filesrchMDIChild (TMDIClient &parent, const char far *title,
		TLines *lines, TWindow *clientWnd, BOOL shrinkToClient, TModule *module)
	 : TMDIChild (parent, title,
		 (clientWnd == 0) ? (TWindow *) new filesrchMDIChildClient(0, lines)
		 : clientWnd, shrinkToClient, module)

As you can see from this, filesrchMDIChildClient was the class I derived from TWindow to serve as my MDI child client window.

These are the only things I can think of right off which bear discussion here.  Again, I hope this example helps you understand the generation of programs using the AppExpert and ClassExpert. Please direct any questions to section 11 of the BCPPWIN forum, where I will gladly assist in understanding this sample.

Happy Programming!

Earl Bennett (TeamB)
71333,2656
71333.2656@compuserve.com
