PRODUCT : Borland C++ NUMBER : 1154 VERSION : 3.1 OS : WIN DATE : October 19, 1993 PAGE : 1/4 TITLE : Resolving OWL Error codes -5 and -1. Resolving OWL Error codes -5 and -1. Error code -5 is reported by OWL when it cannot create a dialog, or a window. When you create a dialog, you have to tell Windows these following: - The name of the Dialog box - The module which it is in. These are the very items that OWL must pass to Windows when it calls DialogBoxParam or CreateDialog. You tell OWL what these items are when you construct a TDialog. A TDialog constructor looks like the following: TDialog::TDialog( PTWindowsObject parent, LPSTR name, PTModule module = NULL ); The name parameter you specify must be the name of the dialog resource. If in the .RC script there is something like this: HELLO DIALOG 18, 18, 142, 92 etc., Then the name of that resource is HELLO, and you are going to want to construct your TDialog like so, new TDialog( this , "HELLO" ); That is you specify the same name for the constructor that you have in the .rc script. How can this go wrong: (1) The resource is not actually bound to the .EXE file, or it does not have the name you think it does. To check this, run Resource Workshop and open up your .EXE file as a project. Workshop will list the names of all the dialogs that are bound to the EXE. If it is not there, inspect the .RC file that you include in the project file to see if the dialog is there. (2) Their is a mismatch in the names. The .EXE when opened into Workshop lists one name, and the .CPP file passes another to the TDialog constructor. If you are using the TDialog constructor which takes an int for the name, then it is likely that you are not including the correct header file in the .CPP PRODUCT : Borland C++ NUMBER : 1154 VERSION : 3.1 OS : WIN DATE : October 19, 1993 PAGE : 2/4 TITLE : Resolving OWL Error codes -5 and -1. source code which defines the constant, or else the constant is redefined. To check this, hard code the numbered name of the resource when you construct the TDialog. (3) It is also possible that the name you are passing has been corrupted at run time. If I do new TDialog( this , "HELLO" ); What I am really doing is passing the address of a string in the data segment. If that memory in the data segment is corrupted, the call would fail. One way you can check that, is to go into Turbo Debugger for Windows, run to the point where you new the TDialog, do a view | Dump to see the data segment, hit Alt - F10 to bring up the local menu and search for the string HELLO to see if you can find it. (4) The other thing that can go wrong is that you are telling Windows to look in the wrong module for the dialog resource. A module is a EXE or a DLL file, and either could have a dialog bound to it. The way you identify a module for Windows is with an hInst. This is what is passed to WinMain or LibMain for an EXE or DLL respectively. The Windows API functions that create a Dialog take an hInst as a parameter, this is how you tell Windows where the dialog resource is. In OWL, hInst's are encapsulated in TModule objects (and the TApplication objects which are derived from them). When you construct a TModule object, you pass it a hInst. So if you want to create a Dialog box that is in a DLL, you must pass the proper PTModule parameter to the TDialog constructor. If defaults to NULL which will imply the Application object if you are in a EXE. Here is some pseudo code on how to do this: HINSTANCE h = GetModuleHandle( "RESOURCE.DLL"); PTModule pm = new TModule( "", h , "" ); PTDialog pd = new TDialog( this , "HELLO", pm ); Normally, a DLL using OWL will construct a TModule in its LibMain. You could add a function in the DLL to return a pointer to that TModule rather then creating one in the EXE like in the above code. (5) Now let us assume that Windows has found the dialog resource. The next thing it has to do is create the dialog. Dialogs are specialized windows. All Windows are part of a PRODUCT : Borland C++ NUMBER : 1154 VERSION : 3.1 OS : WIN DATE : October 19, 1993 PAGE : 3/4 TITLE : Resolving OWL Error codes -5 and -1. registered class. When Windows finds the dialog resource in the .RC script, a non standard class name may be specified like so: HELLO DIALOG 18, 18, 142, 92 STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU CLASS "BORDLG" This means that the class BORDLG must be registered in order for Windows to create this dialog. Similarly, all the child Windows in the dialog will specify class names, like "LISTBOX", or "BORBTN". Any non standard ones will also have to be registered. The above brings us to the most common cause of error code -5: one is using Borland custom controls, but the BWCC DLL which registers them has not been loaded. Another symptom is the program works while Resource Workshop or Borland C++ for Windows is running, but not when the application runs stand alone. The explanation for that is that the Borland applications load BWCC.DLL, so the classes are registered while they are running. To make sure that your application takes care of loading BWCC.DLL, follow the following steps: (a) In any of your modules (say the one with WinMain) #include (b) call BWCCGetVersion(); anywhere in the code. (c) Link to BWCC.LIB (the import library for BWCC.DLL). If you are sure that the class names which a dialog resource or a window uses are registered, and you are still getting error code -5, be aware that there are options when registering a class, they can be registered to a given module or globally. The WNDCLASS which gets filled when calling RegisterClass has a style field, and one can or in CS_GLOBALCLASS to make the class visible to all modules. (6) Another explanation for the -5 error could be that you do not have a large enough local heap. Some controls, such as Edit controls in dialogs with the DS_LOCALEDIT style, will use memory from the local heap and if initialization of the control PRODUCT : Borland C++ NUMBER : 1154 VERSION : 3.1 OS : WIN DATE : October 19, 1993 PAGE : 4/4 TITLE : Resolving OWL Error codes -5 and -1. fails, the Dialog's creation will also fail, resulting in a -5 from OWL's Dialog interface. OWL error code -1: While -5 indicates a failure to create a window, -1 indicates an invalid child window. Usually it is the result of constructing a child window for a dialog incorrectly. Typically, the constructor used for child controls in a dialog is the one which takes a resoruce ID. If the ID passed to the constructor does not match the ID for the control, there will be an invalid child window message. For example, if there is a Button whose ID is 101 in the dialog, and I do a new TButton( this , 102 ); in the constructor for the dialog box, I will most likely get invalid child window. The other thing which can go wrong is that the Windows class name which your child window object specifies cannot be found. The most likely cause of this is that the class was not registered as a global class, or the child window needs to be constructed with a specific PTModule object to say where the class was registered. DISCLAIMER: You have the right to use this technical information subject to the terms of the No-Nonsense License Statement that you received with the Borland product to which this information pertains.