Help System
Use OpenHelp in 5.01 to Configure
Your Help System
OpenHelp (OPENHELP.EXE) is back in 5.01. You can use it to configure
your help system the way you want. Do this:
- Run OpenHelp.exe. You'll have to run it from Explorer or Program Manager since there is no icon for it in your BC++ 5.01 group.
- Click on the "Create" button to create a new Search Range.
- Type in the name of your new Search Range ("My Default Setup" or whatever).
- Click OK.
- In the listbox marked "Available Help Files" choose any help files that you want to be searched when you hit the F1 key. Remember that the Win95 help system has a limit to the amount of info the index can handle so don't choose more help files than you really need.
- Click the right arrow button (">") to add the help files to the list for this Search Range.
- If you want to add help files not listed in the listbox then click the "Add" button.
- When you are done you must highlight your new Search Range and press the "Select" button to make certain that your range is set as the current Search Range.
- Click OK twice and that's it!
 | Choose the help files you want to add from the File Open dialog. |
| Find the new help files in the list (they'll be at the bottom since the list isn't sorted). |
| Add them with the ">" button. |
You can choose one of the pre-defined Search Ranges but to really customize the BC5 help system you will likely want to create your own Search Range.
Empty Help Message Box
Sometimes you will get an empty help message box. The message box has
a red circle with an X in it and a Cancel button, but no text. In order
to get rid of the blank message box you can either place a dummy file called
owl.hlp in your \bc5\help directory or by editing WINHELP.INI and commenting
out (with a semi-colon) any lines that refer to help files no longer on
your hard drive (particularly those that refer to \bc45 if you have removed
4.5x from your system).
Incorrect Help Topics
for Buildtime Messages
Download the help file patch.
How do I modify OpenHelp
to include other help files?
You can add your own help files (or 3rd party library help files) by
editing \BC5\HELP\OPENHELP.CNT. In Win95 if you double click this file
in Explorer you will get the Help Contents Editor which is not as easy
to use as just editing the file using Notepad. Open the file in any text
editor and add the name of any help files you want included.
5.01 RW Crashes With TASM 5.0
Installed
If you have installed TASM 5.0 to the \BC5 directory you may find that
RW will not run. The is because TASM 5 will overwrite the Resource Workshop
files that ship with 5.01. This is detailed in the README.TXT accompanying
TASM 5. Copy any RW files (RW32CORE.DLL in particular) from the
CD to your \BC5\BIN directory and RW will again function. To download a
text file containing the complete list of files affected by installing
TASM 5 in the BC5\BIN directory click here.
Adding OWL Tab Controls
(TTabControl/TNoteTab) to Dialogs in RW
Adding a tab control to a dialog in Resource Workshop is easy if you are
doing 32-bit programs using TTabControl. Just choose the tab control from
the control palette and drop it on the dialog. When doing 16-bit programs,
though, it's not as easy.
First, edit the dialog you want the tab control to go on. Then from the menu choose Dialog | Insert New Control. When the New Control dialog comes up type in the name of the class you are adding. The following values can be used.
TTabControl (16-bit only), "SysTabControl"
TNoteTab, "OWL_Notetab"
Note that the dialog editor will place the control names in the resource definition exactly as they appear above--with the quotes around them. If you use the exact class name then that will work. A more portable method, however, would be to use the OWL #defines for these two classes:
TTabControl (16-bit only), WC_TABCONTROL
TNoteTab, OWL_NOTETAB
Then you could use the same .rc file for both 16 and 32-bit builds. In the case of TNoteTab OWL_NOTETAB is defined as "OWL_Notetab" in either a 16-bit or a 32-bit build. With TTabControl WC_TABCONTROL is #defined as "SysTabControl" in 16-bits and "SysTabControl32" in 32-bits.
If you use the #defined constants rather than the actual class name then you will have to perform two additional steps in order to make it work.
0. Edit the .rc file as text.
1. #include <commctrl.h> for TTabControl and <owl\notetab.h> for
TNoteTab.
2. Remove the quotes from the tab control's class
name in the resource definition for the dialog.
After you get the .rc file set up the way you want it you can then subclass the controls just as you would any other OWL control on a dialog.
"Set Creation Order"
Doesn't Seem To Work in the Dialog Editor
If you have tried to set the creation order of controls on a dialog
you may have found that it doesn't work. There's a trick: After you have
set the creation order you need to choose "End Mode" from
the speed menu to put the changes into effect.
Controls on Dialogs not Painting
Properly in RW
While editing dialogs you may see controls containing bleed-through
from items behind the control. This is only apparent with BWCC controls
or BWCC dialogs and usually involving group boxes. The workaround is to
change the creation order so that your groupboxes are created first. Choose
"Set Creation Order" from the speed menu. Set the creation
order by clicking on your controls in the order that you want them to be
created. Finally, from the speed menu choose "End Mode." The
dialog should paint properly now. This problem is being addressed and should
be fixed in BC++ 5.01.
Why can't I use custom controll
DLL's in RW?
This support should be added shortly. The RW team had other pressing
issues that needed to be resolved first. Hopefully we will see DLL custom
control support added soon.
My resource identifiers go
into my project's .rc file. Why?
For some reason the default is to add the identifiers to the .rc file.
We have complained about this and hopefully it will be changed so that
the default is the .rh file. In the mean time you will have to tell RW
to put the identifiers in the .rh file. If this is a new project then first
create an empty .rh file in your project's directory. When you create a
new resource notice the combo box that says, "New identifiers to be
placed in:" By default the .rc file is listed. Choose your .rh file
from the list and the ID will go in the .rh file. For existing resources
you can right click on the resource in the resource window and choose "Resource
Attributes" from the speed menu. You will see two combo boxes
at the top of the page. The first (on the left) is for the resource itself
and the second (the one on the right) is for the resource identifier.
Change that one to point to your .rh file.
More Info: You can also do one of the following:
1. Enter the include statement into the resulting .rc file, right click to bring up the speed menu, select Open source (it will open a new file), then cut and paste the defines from the .rc to the .rh file.
2. Select File | New | Resource Project..., then select Options. This will bring up the Add Header File dialog; simply type in a name for your .rh file. The definitions will be placed in that file when you save your .rc file.
3. If you've already created the .rc file then open your .rc file as text and add an #include to your .rh file before adding any resources. The identifiers will now go directly to the .rh file.
Where is the string
table editor?
Look for this feature to return in later versions of BC++ 5.0.
This feature was pushed to the back burner because more pressing problems
were being addressed in the RW.
I can't place an icon or
bitmap on my dialog in RW (Picture Control).
Two things are at work here. First, the 'Test Dialog' feature is not
complete at this time and won't show any icons or bitmap controls put on
the dialog. You will have to actually run the program in order to see the
graphic on the dialog. The second thing is that you will need to edit your
.rc file as text and remove the quotes from the resource name for the control
line that represents the bitmap or icon. For example the line for an icon
might read...
CONTROL "ID_PICTURE", -1, "static", SS_ICON // etc.
Change it to:
CONTROL ID_PICTURE, -1, "static", SS_ICON // etc.
Now compile and run the program and the icon should show up on the dialog. Finally, the bitmap control (SS_BITMAP) is not supported under 16 bit - only the SS_ICON style is Win16 compatible.
Java Debugger Gone in 5.01
Due to some compatibility problems the Java Debugger was removed from
the 5.01 version of BC++. In my opinion Java development with BC++ is
a novel thing and not something anyone would attempt to make a living doing.
Open JBuilder (code named
Latte) is due out early next year (just guessing) so that would be
the tool of choice for serious Java development.
I've got other Java products installed.
I get errors trying to use the Java addon in BC5.
Sounds like other JDK's are being found before the JDK that shipped
with BC5 .Apply Patch 2. This patch permits
the Java add on to work with the JDK shipped with it. It will not get interference
from other JDKs.
Error: Unable to Find JAVACOMP.DLL
You've got a standard release of BC5 that doesn't have the Java Just
In Time Compiler included. The error message is informational, and isn't
harmful.
When I start the debugger, I
get a message that it can't find the .class file. I know it's there.
Chances are that you don't have a TCP/IP stack. Sun's debug kernal
that the Java debugger relies on utilizes TCP/IP to communicate with the
Java virtual machine. If you open the message window, you'll probably see
a reference to java.net.UnknownHostException. Click
here for the full text on setting up a TCP/IP stack.
Problem with bcwjava.dll
when loading the IDE after applying Patch 2.
Be sure you apply the patch from the \bc5 directory only. That way
all the proper subdirectories get the patches applied.
I keep getting Sun's
license agreement when I attempt to run an applet (Win95).
There are two buttons at the bottom of the license agreement window.
The buttons are labeled 'Accept' and 'Reject'. The problem is that the
buttons are obscured by the Win95 task bar. Move the license window and
click on the 'Accept' button and the applet viewer will run.
Using STL With BC++ 5.0
To use STL in a Borland C++ application, it is very important, when
including the STL header files, to use the preferred form of the STL header
file names - that is, names WITHOUT the extension explicitly specified.
For example, you should use:
#include <algorithm>
#include <vector>
#include <string>
instead of
#include <algorith.h>
#include <vector.h>
#include <string.h>
When these files are included in the preferred way (without the extension,) the Borland compiler automatically defines the internal macro __USING_STD_NAMES__. This macro is used in the header files string.h, memory.h, limits.h, and complex.h to include either the STL version of these classes, or code relating to the non-STL implementation of these classes.
If the STL files are not included in the preferred manner, this macro is not defined by the compiler, and the STL class and function definitions contained in these four files will not be available. (This includes classes such as string, wstring, auto_ptr, allocator, as well as many helper functions used by STL.)
In case you were wondering, the compiler will not let you define this macro by using a #define statement. (Courtesy of Jim Sugg)
Getting OWL and STL to
Work Together
OWL uses the cstring class (string) and STL also has a string
class. Thus, there is a namespace conflict. Attempting to use STL in
an OWL app results in compiler errors that are elusive and don't point
to the real problem. You can use STL and OWL together in a project,
though.
One method is to not use STL and OWL together in the same module. Although this will work, it is not very practical in a real-world situation. A more practical solution requires renaming the std::string class to std::_string. The following code fragment illustrates:
#include <owl\applicat.h>
#include <owl\framewin.h>
#pragma hdrstop
#define string _string
#include <vector>
#undef string
#define string _string
#include <string>
#undef string
using namespace std;
typedef vector<_string> array;
Now all references to std::string must be '_string' rather than plain 'string.' Notice in the above code the #pragma hdrstop is placed before the STL #includes. If you try to include the STL headers in the pre-compiled header you will get a warning, "Cannot create pre-compiled header - code in header." Stopping compilation of the .csm prior to including the STL headers eliminates the warning and allows use of pre-compiled headers. (With help from John Maddock)