CONTENTS ___________________________________________________________________________ Changes to windows.h from 3.0 to Message cracker examples . . 26 3.1 . . . . . . . . . . . . . . . 1 Message handler function Catching coding errors at signatures . . . . . . . . . 28 compile-time: STRICT . . . . . . . 1 Improving reusability: Why STRICT? . . . . . . . . . . 2 Template_DefProc . . . . . . 28 Compiling 3.0 applications . . . 3 Private and registered window New typedefs, constants, and messages . . . . . . . . . . 29 helper macros . . . . . . . . . 4 Message crackers and window COMSTAT structure change . . . 5 instance data . . . . . . . . 30 Making your code STRICT Message crackers and dialog compliant . . . . . . . . . . . 6 procedures . . . . . . . . . 33 STRICT conversion hints . . . 10 Message crackers and window Common compiler warnings and subclassing . . . . . . . . . 34 errors . . . . . . . . . . . . 11 Dialog procedures: A better Macro APIs and message crackers . 14 way . . . . . . . . . . . . . 36 Macro APIs . . . . . . . . . . 15 Executing default dialog 3.1-only macro APIs . . . 18 procedure functionality . . 37 Control message APIs . . . . . 18 Returning message results from Control API Examples . . . . 18 dialog procedures . . . . . 37 Message cracker macros . . . . 22 How it works . . . . . . . 37 Using message crackers and A simplified example using forwarders . . . . . . . . . 23 predefined macro APIs . . . 39 Saving time and improving Converting existing code to use readability with HANDLE_MSG . 24 message crackers . . . . . . 41 How message crackers work . 25 i TABLES ___________________________________________________________________________ 1: New handle types . . . . . . . 5 ii =========================================================================== Changes to windows.h from 3.0 to 3.1 =========================================================================== The windows.h header file included with Borland C++ 3.1 contains various features that make application development faster and easier by helping you find problems as you compile your code. These improvements include: o STRICT option provides stricter type checking, helping you find type mismatch errors quickly. o windows.h has been completely reorganized so that related functions, types, structures, and constants are grouped together. o New UINT type used for 32-bit Windows upward compatibility o New unique typedefs for all handle types, such as HINSTANCE and HMODULE. o Various constants and typedefs missing in the 3.0 windows.h have been added. o Windows 3.0 compatibility: windows.h can be used to compile applications that run under Windows 3.0. o Proper use of "const" for API pointer parameters and structure fields where pointer is read-only. If you have ObjectWindows, also see OWL31.DOC in your OWL\DOC directory for details about how these changes affect ObjectWindows and your ObjectWindows applications. =========================================================================== Catching coding errors at compile-time: STRICT =========================================================================== The new windows.h supports an option called STRICT that enables the strictest possible compiler error checking. Strict compile-time checking helps you find programming errors when you compile your application, rather than at runtime. The idea is that you define STRICT before including windows.h, which causes the various types and function prototypes in windows.h to be declared in a way that enforces very strict type checking. For example, without STRICT, it is possible to pass an HWND to a function that requires an HDC without any kind of compiler warning: with STRICT defined, this results in a compiler error. Specific features provided by the STRICT option include: o Strict handle type checking (you can't pass an HWND where an HDC is declared). o Correct and more consistent declaration of certain parameter and return value types (for example, GlobalLock returns void FAR* instead of LPSTR). o Fully prototyped typedefs for all callback function types (for example, dialog procedures, hook procedures, and window procedures) o Windows 3.0 backward compatible: STRICT can be used with the 3.1 windows.h for creating applications that will run under Windows 3.0. o The COMM DCB and COMSTAT structures are now declared in an ANSI compatible way. Why STRICT? ======================================================= The best way to think of STRICT is as a way for you to get the most out of the error checking capabilities built into Borland C++. STRICT is of great benefit especially with code under development, because it helps you catch bugs right away when you compile your code, rather than having to track it down at runtime with a debugger. By catching certain kinds of bugs right away, it's less likely that you'll ship your applications with bugs that weren't encountered in testing. STRICT also makes it easier to migrate your code to the 32-bit Windows platform later, because it will help you locate and deal with type incompatibilities that will arise when migrating to 32 bits. - 2 - It's not very difficult to convert your application to use STRICT, and it can be done in stages if needed. In order to take advantage of the STRICT option, you will probably have to make some simple changes to your source code (described in detail later). We think you'll find that STRICT makes modifying, maintaining, and even reading your code much easier, and well worth the effort to convert your application. Compiling 3.0 ======================================================= applications Unless you define STRICT, your 3.0 applications will compile with windows.h without serious modifications. The type declarations for many of the Windows APIs and callback functions have changed; those changes are backward compatible for C code, but not for C++ code. If you use C++, you'll notice compile- and link-time errors in many Windows API functions because of changes to types like WORD to UINT. See the following sections for more information. All of the features of Borland C++ 3.1 can be used to develop applications that will run under Windows 3.0. There are two things you must do: 1. Define WINVER to 0x0300 before including windows.h This ensures that only 3.0 compatible functions, structures, and definitions are available for use. You can do this in your makefile with -DWINVER=0x0300 in the compiler command line, in the IDE in the Options|Compiler|Code Generation|Defines input box, or in your code by adding "#define WINVER 0x0300" before you include windows.h. 2. Use the -30 parameter to BRC or RC. This marks your executable as a 3.0 application, so that Windows 3.0 won't prevent it from running with a "This application requires a later version of Windows" message. You will typically run RC twice in your makefile: Once to produce the .res file (with ...
mek4test