AIM:- Study Windows API and their relationship with MFC classes and how are they

useful in finding complexity of the windows programming.

Basic for Windows Programming

API is an acronym for Application Programming Interface. Its simply a set of functions that are part of Windows OS. Programs can be created, by calling the functions present in the API. Programmer doesnt have to bother about internal working of functions. By just knowing the functions prototype and return value he can invoke the API function. Its two varieties are:a) API for 16-bit Windows (Win 16 API) b) API for 32-bit Windows (Win 32- API) Their descriptions are:Win16API User.exe Win 32 API User32.exe Description User component is responsible for window management, including messages, cursor, timers, etc. This is graphical device interface. It takes care of user-interface and graphics including windows bitmap, context and fonts. Kernel component handles the low level functions of memory, task and resources management that are heart of windows.

Gdi.exe

Gdi32.exe

Kernel386.exe

Kernel32.exe.dll

Win API was created for 16-bit processors (current generations) and it relies on 16-bit values. Although, Win16 versions of these components cant run on their own. Win 32 is future. Dynamic Link Library (DLL) is a binary file that provides a library of functions, objects and resources. All API functions are contains in DLL. The functions present in DLL can be linked during execution. These functions can also be shared between several applications running in windows. Since linking is done dynamically, functions dont become a part of executable file. As a result size of exe files dont go out of hand.

Advantages: Sharing common code between different executable file.

 Breaking an application into component parts to provide a way to easily upgrade application component. Keeping resources data out of application executable but still readily accessible to an application

Queued and NON-Queued messages:- In event driven programming model,

Windows sent numerous messages to the application. Some messages are sent to message Queue. These are queued messages. These messages are got using Got Message () and dispatches to Window procedure by calling Dispatch Message () function. Some messages are sent to application straight way calling the window procedure instead of following message loop routine. Those messages sent to application by directly calling its windows procedures are called Non-Queued messages.

WIN MAIN
The WinMain function is called by the system as the initial entry point for a Win-32 based application. Int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdline, Int nCmdShow ); //handle to current instance instance //handle to previous instance //pointer to command line //show state of window

Parameters
hInstance Handle to the current instance of the application. hPrevInstance Handle to the previous instance of the application. For a Win32 based app, this parameter is always NULL. To detect whether another instance already exists, create a uniquely named mutex using the CreateMutex() function. This will succeed even if the mutex already exists, but the GetLastError() function will return ERROR_ALREDY_ EXISTS. This indicates another instance of the applicant exists, coz it created the mutex first. lpCmdLine Pointer to a null-terminated string specifying the command line for the app, excluding the program name. To retrieve the entire command line, use the Get CommandLine() function. nCmdShow

Specifies how the window is to be shown. This parameter can be one of the Following values: Values Meaning SW_HIDE Hides the window and activates another window. SW_MINIMIZE Minimizes the specified window and activates the top-level window in the systems list. SW_RESTORE Activates and displays a window. If the window is minimized or maximized, the system restores it to its original size and position(same as SW_SHOWNORMAL) SW_SHOW Activates a window and display it in its current size and position. SW_SHOWMAXIMIZED Activates a window and displays it as a maximized window SW_SHOWMINIMIZED Activates a window and displays it as a icon SW_SHOWNNOACTIVE Displays a window as a icon. The active window remains active. SW_SHOWNA Displays a window in its current state. The active window remains active. SW_SHOWNOACTIVATE Displays window in its most recent size & position. The active window remains active. SW_SHOWNORMAL Activates & display a window. If the window is minimized or maximized, the system restores it to its original size & position (same as SE-RESTORE)

Return Values
If the function succeeds, terminating when it receives a WM_QUIT message, it should return the exit value contained in that message wParam parameter. If the function terminates before entering the message loop, it should return zero.

Remarks
WinMain should initialize the app, displays its main window, and enter a msg retrieval and dispatch loop that is the top level control structure for the remainder of the apps execution. Terminate the msg loop when it receives the WM_QUIT msg. At the point WinMain should exit the app, returning the value passed in the WM_QUIT msgs wParam parameter. If WM_QUIT was received as a result of calling PostQuitMessage, the value of wParam is the value of the PostQuitMessage functions nExitCode parameter.

ANSI app can use the lpCmdLine parameter of the WinMain function to access the command line string, excluding the program name. The reason that WinMain cannot return Unicode string that lpCmdLine uses the LPSTR data type, not the LPSTR data type. The GetCommandLine function can be used to access Unicode strings in the command line, coz it uses the LPSTR data type.

ContainedWindow::WindowProc
Static LPESULT CALLBACKM WindowProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); Return Value The result of the msg processing. Parameters hWnd [in]The handle to the window. wMsg [in]The msg sent to the window. wParam [in]Additional msg-specific information. lParam [in]Additional msg-specific information. Remarks This static method implements the window procedure. WindowProc directsmsgs to the msg map identified by m_dwMsgMapID. If necessary, WindowProc calls DefWindowProc for additional msg processing.

Accessing the Microsoft Windows API

You can access to the Windows API (or other outside DLLs) by declaring the external procedures within your Visual Basic application. After you declare a procedure, you can use it like any other language feature in the product. The most commonly used set of external procedures are those that make up Microsoft Window itself. The Window API contains thousands of functions, subs, types, and constants that you can declare and use in your project. These procedures are written in the C language, however, so they must be declared before you can use them with the Visual Basic. The declaration for DLL procedures can become fairly complex. While you can

translate these yourself, the easiest way to access the windows API is by using the predefined declares included with Visual Basic. The file Win32api txt, located in the \Winapi subdirectory of the main Visual Basic directory, contains declarations for many of the Windows API procedures commonly used in Visual Basic. To use a function, Type, or other feature from this file, simply copy it to your Visual Basic module. You can view and copy procedures from Win32api.txt by using the API Viewer application, or by loading the file in any text editor. Note: The Windows API contains a vast amount of code. To find reference information on the procedures and other details included in this API set, refer to the Win 32 SDK, included on the Microsoft Developer Network Library CD.

Using the API Viewer Application

The API Viewer application enables you to browse through the declares, constants, and types included in any text file or Microsoft Jet database. After you find the procedure you want, you can copy the code to the Clipboard and paste it into your Visual Basic application. You can add as many procedures as you want to your application. The API Viewer application

To view an API file

1. From the Add-Ins menu, open the Add-In Manager and load API Viewer. 2. Click API Viewer from the Add-Ins menu. 3. Open the text or database file you want to view. To load a text file into the viewer, click File \ Load Text File and choose the file you want to view. To load a database file, click File \ Load Database File. 4. Select the type of item you want to view from the API types list. Note: You can have the API Viewer automatically display the last file you viewed in it, When it is opened, by selecting View \ Load Last File.

To add procedures to your Visual Basic code.

1. Click the procedure you want to copy in the available Items list. 2. Click Add. The item appears in the selected Item list. 3. Indicate the scope of the item by clicking Public or Private in the Declare Scope group. 4. To remove an entry from the selected Items list box, click the item and click Remove. 5. To remove all the entries from the Selected Items list box, click Clear.

MFC: Overview

The Microsoft Foundation Class Library (MFC) is an application framework for programming in the Microsoft Windows. Written in C++, MFC provides much of the code necessary for managing windows, menus, and dialog boxes; performing basic input/output; storing collections of data objects; and so on. All you need is to do is add your application-specific code into this framework, and given the nature of C++ class programming, its easy to extend or override the basic functionality the MFC framework supplies. The MFC framework is a powerful approach that lets you build upon the work of expert programmers for windows. MFC shortens development time; makes code more portable; provides tremendous support without reducing programming freedom and flexibility; and gives easy access to hard to program user-interface elements and technologies, like Active technology, OLE, and Internet programming. Furthermore, MFC simplifies database programming through Data Access Objects (DAO) and Open Database Connectivity (ODBC), and network programming through Windows Sockets. MFC makes it easy to program features like property sheets (tab dialogs), print preview, and floating, customizable toolbars.

What do you want to know more about?

Learning to program with MFC. MFC fundamentals: windows, documents, views, and more. A specific key area of MFC programming. What MFC assumes I know already. Where to find third-party information about programming for Windows and programming with MFC. What MFC can and cant do for me.

The Framework
Your work with the Microsoft foundation Class Library (MFC) framework is based largely on a few major classes and several visual C++ tools. Some of the classes encapsulate a large portion of the Win32 application programming interface (API). Other classes encapsulate application concepts such as documents, views, and the application itself. Still others encapsulate Ole features and ODBC and DAO data-access functionality. For example, Win32s concept of window is encapsulated by MFC class CWnd. That is, a C++ class called CWnd encapsulates or wraps the HWND handle that represent a Windows window. Likewise, class CDialog encapsulates Win32 dialog boxes. Encapsulation means that the C++ class CWnd, for example, contains a member variable of type HWND, and the classs member functions encapsulate calls to Win32 functions that take an HWND as a parameter. The class member functions typically have the same name as the Win32 function they encapsulate.

What do you want to know more about?

SDI and MDI. Documents, views, and the framework. Wizards, WizardBar, and resource editors. Building on the framework. How the framework calls my code. CWinApp: the application class. Document templates and the document/view creation process. Messages and commands. Windows.

The Assumptions of MFC

Among the important assumptions made by the MFC documentation are thet: You already know a little about programming for windows. You know basics of programming in C++. You understand the fundamentals of object-oriented programminf. What do you want to do? Learn where to find third-party information about MFC programming. Find out how to start learning MFC. Get an overview of MfC fundamentals. MFC Application Architecture Classes Classes in this category contribute to the architecture of a framework application. They supply functionality common to most applications. You fill in the framework to add application-specific functionality. Typically, you do so by deriving new classes from the architecture classes, then adding new members and/or overriding member functions. AppWizard generates several types of applications, all of which use the application framework in differing ways. SDI(single document interface) and MDI (multiple document interface) applications make full use of a part of the framework called document/view architecture. Other types of applications, such as dialog-based applications, form-based applications, and DLLs, use only some of document/view architecture features. Document/view applications contain one or more sets of documents, views, and frame windows. A document-template object associates the classes for each document/view/frame set. Although you do not have to use document/view architecture in your MFC application, there are a number of advantages to doing so. MFCs OLE container and server support is based on document/view architecture, as is support for printing and print preview. All MFC applications have at least two objects: an application object derived from CWinApp, and some sort of main window object, derived (often indirectly) from CWnd.

(Most often, the main window is derived from CFrameWnd, CMdIFrameWnd, or CDialog, all of which are derived from CWnd.) Applications that use document/view architecture contain additional objects. The principal objects are as follows: An application object derived from the class CWinApp, as mentioned before. One or more document class objects derived from class CDocument. Document class objects are responsible for the internal representation of the data manipulated in the views. They may be associated with a data file. One or more view objects derived from class CView. Each view is a window that is attached to a document and associated with a frame window. Views display and manipulate the data contained in a document class object. Document/view applications also contain frame windows (derived from CFrameWnd) and document templates (derived from CDocTemplate).