The Windows Registry

If you've used Win16-based applications, you've probably seen INI files. You can still use INI files in Win32-based applications, but Microsoft recommends that you use the Windows Registry instead. The Registry is a set of system files, managed by Windows, in which Windows and individual applications can store and access permanent information. The Registry is organized as a kind of hierarchical database in which string and integer data is accessed by a multipart key.

For example, a text processing application, TEXTPROC, might need to store the most recent font and point size in the Registry. Suppose that the program name forms the root of the key (a simplification) and that the application maintains two hierarchy levels below the name. The structure looks something like this.

TEXTPROC

    Text formatting

       Font = Times Roman

       Points = 10

Unicode

European languages use characters that can be encoded in 8 bits—even characters with diacritics. Most Asian languages require 16 bits for their characters. Many programs use the double-byte character set (DBCS) standard: some characters use 8 bits and others 16 bits, depending on the value of the first 8 bits. DBCS is being replaced by Unicode, in which all characters are 16-bit "wide" characters. No specific Unicode character ranges are set aside for individual languages: if a character is used in both the Chinese and the Japanese languages, for example, that character appears only once in the Unicode character set.

When you look at MFC source code and the code that AppWizard generates, you'll see the types TCHAR, LPTSTR, and LPCTSTR and you'll see literal strings like _T("string"). You are looking at Unicode macros. If you build your project without defining _UNICODE, the compiler generates code for ordinary 8-bit ANSI characters (CHAR) and pointers to 8-bit character arrays (LPSTR, LPCSTR). If you do define _UNICODE, the compiler generates code for 16-bit Unicode characters (WCHAR), pointers (LPWSTR, LPCWSTR), and literals (L"wide string").

The _UNICODE preprocessor symbol also determines which Windows functions your program calls. Many Win32 functions have two versions. When your program calls CreateWindowEx, for example, the compiler generates code to call either CreateWindowExA (with ANSI parameters) or CreateWindowExW (with Unicode parameters). In Microsoft Windows NT, which uses Unicode internally, CreateWindowExW passes all parameters straight through, but CreateWindowExA converts ANSI string and character parameters to Unicode. In Microsoft Windows 95, which uses ANSI internally, CreateWindowExW is a stub that returns an error and CreateWindowExA passes the parameters straight through.

If you want to create a Unicode application, you should target it for Windows NT and use the macros throughout. You can write Unicode applications for Windows 95, but you'll do extra work to call the "A" versions of the Win32 functions. As shown in Chapter 24, Chapter 25, Chapter 26, Chapter 27, Chapter 28, Chapter 29, and Chapter 30, COM calls (except DAO) always use wide characters. Although Win32 functions are available for converting between ANSI and Unicode, if you're using the CString class you can rely on a wide character constructor and the AllocSysString member function to do the conversions.

For simplicity, this book's example programs use ANSI only. The code AppWizard generated uses Unicode macros, but the code I wrote uses 8-bit literal strings and the char, char*, and const char* types.

The MFC library provides four CWinApp member functions, holdovers from the days of INI files, for accessing the Registry. Starting with Visual C++ version 5.0, AppWizard generates a call to CWinApp::SetRegistryKey in your application's InitInstance function as shown here.

SetRegistryKey(_T("Local AppWizard-Generated Applications"));

If you remove this call, your application will not use the Registry but will create and use an INI file in the Windows directory. The SetRegistryKey function's string parameter establishes the top of the hierarchy, and the following Registry functions define the bottom two levels: called heading name and entry name.

  • GetProfileInt

  • WriteProfileInt

  • GetProfileString

  • WriteProfileString

These functions treat Registry data as either CString objects or unsigned integers. If you need floating-point values as entries, you must use the string functions and do the conversion yourself. All the functions take a heading name and an entry name as parameters. In the example shown above, the heading name is Text Formatting and the entry names are Font and Points.

To use the Registry access functions, you need a pointer to the application object. The global function AfxGetApp does the job. With the previous sample Registry, the Font and Points entries were set with the following code:

AfxGetApp()->WriteProfileString("Text formatting", "Font",                                 "Times Roman"); AfxGetApp()->WriteProfileInt("Text formatting", "Points", 10);

You'll see a real Registry example in EX15A, and you'll learn to use the Windows Regedit program to examine and edit the Registry.

The application framework stores a list of most recently used files in the Registry under the heading Recent File List.



Programming Visual C++
Advanced 3ds max 5 Modeling & Animating
ISBN: 1572318570
EAN: 2147483647
Year: 1997
Pages: 331
Authors: Boris Kulagin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net