2) Explain how message passing allows windows to be multitasking? Messages come in the form of an MSG data type in windows.

This data object is passed to the GetMessage() function, which reads a message from the message queue, or waits for a new message from the system. Next, the message is sent to the TranslateMessage() function, which takes care of some simple tasks such as translating to Unicode or not. Finally, the message is sent to the window for processing using the DispatchMessage() function. A simple message loop consists of one function call to each of these three functions: GetMessage, TranslateMessage, and DispatchMessage. If there is an error, GetMessage returns -1 -- thus the need for the special testing. MSG msg; BOOL bRet; while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) { // handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } } The GetMessage function retrieves a message from the queue and copies it to a structure of type MSG. It returns a nonzero value, unless it encounters the WM_QUIT message, in which case it returns FALSE and ends the loop. In a single-threaded application, ending the message loop is often the first step in closing the application. An application can end its own loop by using the PostQuitMessage function, typically in response to the WM_DESTROY message in the window procedure of the application's main window. If you specify a window handle as the second parameter of GetMessage, only messages for the specified window are retrieved from the queue. GetMessage can also filter messages in the queue, retrieving only those messages that fall within a specified range. For more information about filtering messages, see Message Filtering. A thread's message loop must include TranslateMessage if the thread is to receive character input from the keyboard. The system generates virtual-key messages (WM_KEYDOWN and WM_KEYUP) each time the user presses a key. A virtual-key message contains a virtual-key code that identifies which key was pressed, but not its character value. To retrieve this value, the message loop must contain TranslateMessage, which translates the virtual-key message into a character message (WM_CHAR) and places it back into the application message queue. The character message can then be removed upon a subsequent iteration of the message loop and dispatched to a window procedure. The DispatchMessage function sends a message to the window procedure associated with the window handle specified in the MSG structure. If the window handle is HWND_TOPMOST, DispatchMessage sends the message to the window procedures of all top-level windows in the system. If the window handle is NULL, DispatchMessage does nothing with the message. An application's main thread starts its message loop after initializing the application and creating at least one window. Once started, the message loop continues to retrieve messages from the thread's

message queue and to dispatch them to the appropriate windows. The message loop ends when the GetMessage function removes the WM_QUIT message from the message queue. Only one message loop is needed for a message queue, even if an application contains many windows. DispatchMessage always dispatches the message to the proper window; this is because each message in the queue is an MSG structure that contains the handle of the window to which the message belongs. You can modify a message loop in a variety of ways. For example, you can retrieve messages from the queue without dispatching them to a window. This is useful for applications that post messages not specifying a window. You can also direct GetMessage to search for specific messages, leaving other messages in the queue. This is useful if you must temporarily bypass the usual FIFO order of the message queue. In this way the windows message system allows to message to be captured and dispatched to different processes(window) and so making the system multitasking. 3) What are the benefits provided by C objects to MFC classes? Almost every significant object in an MFC program is a CObject instance. Every window in an MFC program is a CWnd object which is derived from the CObject class. CObject has the following basic functions which can be controlled by using macros in the derived classes: 1. 'Memory Leak Detection' management. It requires no macros. 2. Runtime class identification. This requires the use of the macro 'DECLARE_DYNAMIC' in the class declaration (header file with extension as .h) and the use of macro 'IMPLEMENT_DYNAMIC' in the class definition (source file with extension as .cpp) formation (RTTI) capability. 3. Dynamic object creation (uses the CRuntime class). This requires the use of the macro 'DECLARE_DYNCREATE' in the class declaration (header file with extension as .h) and the use of macro 'IMPLEMENT_CREATE' in the class definition (source file with extension as .cpp) formation (RTTI) capability. 4. Serialization support. Storing an object on hard disc and loading it later is called serialization. This requires the use of the macro 'DECLARE_SERIAL' in the class declaration (header file with extension as .h) and the use of macro 'IMPLEMENT_SERIAL' in the class definition (source file with extension as .cpp) formation (RTTI) capability.
5. Run-time object diagnostics All CObject-derived MFC classes have a Dump member function that you can call to print out a C++s object state at run time

All 'DECLARE' macros have only one parameter as the name of the class. All 'IMPLEMENT' macros have two parameters as the name of the class and the name of the immediate base class. IMPLEMENT_SERIAL is the only one with three parameters. In addition to the two already mentioned, the third is for the schema number. This is the version no. for the class layout at the time the objects are serialized or de-serialized. The program throws an exception if the schema number for the data being loaded does not match with schema number of the object reading the file. Therefore at the time of adding a class member or changing the serialization order, the schema number should be incremented. For examples look at the wizard generated code of the projects created so far and note the use of macros DECLARE_DYNCREATE in the header files and IMPLEMENT_DYNCREATE in the source files.

4) Explain the different ways of creating menus in an MFC application? There are three ways to create menu. The easiest way is to create a menu template in your applications rc file using the resource editor. Once this menu has been created it can be loaded into your applications window by specifying the resource ID of the menu while creating the window. Instead of specifying the resource ID while creating the window we may also first create the window and then load the menu using CMeNU::LoadMenu Sometimes it is not possible to determine the menus content until run-time. In such cases menus can be created programmatically using functions like Create Menu(),Insert Menu(),Append Menu().All these functions members of the MFC CMenu class. The functionality of creating and handling a menu has been implemented in this class.The functionality of creating and handling a menu has been implemented in this class. The third method for creating menu is to first fill a series of data structures defining the menus content and then create the menu using CMenu::LoadMenuIndirect() function. This is the difficult method among the three. 11) What are the functions of windows message system? The system passes input to a window procedure in the form of messages. Messages are generated by both the system and applications. The system generates a message at each input event for example, when the user types, moves the mouse, or clicks a control such as a scroll bar. The system also generates messages in response to changes in the system brought about by an application, such as when an application changes the pool of system font resources or resizes one of its windows. An application can generate messages to direct its own windows to perform tasks or to communicate with windows in other applications. The system sends a message to a window procedure with a set of four parameters: a window handle, a message identifier, and two values called message parameters. The window handle identifies the window for which the message is intended. The system uses it to determine which window procedure should receive the message. A message identifier is a named constant that identifies the purpose of a message. When a window procedure receives a message, it uses a message identifier to determine how to process the message. For example, the message identifier WM_PAINT tells the window procedure that the window's client area has changed and must be repainted. Message parameters specify data or the location of data used by a window procedure when processing a message. The meaning and value of the message parameters depend on the message. A message parameter can contain an integer, packed bit flags, a pointer to a structure containing additional data, and so on. When a message does not use message parameters, they are typically set to NULL. A window procedure must check the message identifier to determine how to interpret the message parameters. Two types of messages: System-Defined Messages Application-Defined Messages System-Defined Messages The system sends or posts a system-defined message when it communicates with an application. It uses these messages to control the operations of applications and to provide input and other information for applications to process.

Application-Defined Messages An application can create messages to be used by its own windows or to communicate with windows in other processes. If an application creates its own messages, the window procedure that receives them must interpret the messages and provide appropriate processing. 12) What are windows dialog boxes? How are they differing from message boxes? Message Box function creates a window of limited flexibility. It has 1. a title bar 2. Close button 3. Optional Icon 4. One or more lines of text 5. Up to 4 buttons Messages are send by the operating system to the window and vice versa. These messages inform the window about its visible state, its size and many other properties. We can resize windows and whenever there is a change in the size of the window, the window send message to the program indicating the new size. i.e. by invoking a function call in the program, called a window procedure. Dialog boxes are of two types: Modal and Modeless. In a modal dialog box, unless the user dismisses the dialog box (possibly by clicking OK or Cancel)the user cannot do anything else with the application. Unlike this when modeless dialog box is displayed, the user is free to reactivate the main window, leaving the dialog box floating in the background. 14) What are virtual key codes?. Explain their need. For each key on a keyboard there is a virtual key code. Since OEM scan codes of the key hit may vary from keyboard to keyboard, Windows identifies keys with the virtual key codes. For example the virtual key codes for function keys F1-F12 are VK_F1-VK_F12 and that for Ctrl_Break is VK_CANCEL.Theser virtual codes are defined in the file winuser.h.The virtual key codes for capital letters, small letters and digits are same as their ASCII values. 19) What are message loops?Where are they used? Messages come in the form of an MSG data type in windows. This data object is passed to the GetMessage() function, which reads a message from the message queue, or waits for a new message from the system. Next, the message is sent to the TranslateMessage() function, which takes care of some simple tasks such as translating to Unicode or not. Finally, the message is sent to the window for processing using the DispatchMessage() function. A simple message loop consists of one function call to each of these three functions: GetMessage, TranslateMessage, and DispatchMessage. If there is an error, GetMessage returns -1 -- thus the need for the special testing. MSG msg; BOOL bRet; while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) {

// handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } } The GetMessage function retrieves a message from the queue and copies it to a structure of type MSG. It returns a nonzero value, unless it encounters the WM_QUIT message, in which case it returns FALSE and ends the loop. In a single-threaded application, ending the message loop is often the first step in closing the application. An application can end its own loop by using the PostQuitMessage function, typically in response to the WM_DESTROY message in the window procedure of the application's main window. If you specify a window handle as the second parameter of GetMessage, only messages for the specified window are retrieved from the queue. GetMessage can also filter messages in the queue, retrieving only those messages that fall within a specified range. For more information about filtering messages, see Message Filtering. A thread's message loop must include TranslateMessage if the thread is to receive character input from the keyboard. The system generates virtual-key messages (WM_KEYDOWN and WM_KEYUP) each time the user presses a key. A virtual-key message contains a virtual-key code that identifies which key was pressed, but not its character value. To retrieve this value, the message loop must contain TranslateMessage, which translates the virtual-key message into a character message (WM_CHAR) and places it back into the application message queue. The character message can then be removed upon a subsequent iteration of the message loop and dispatched to a window procedure. The DispatchMessage function sends a message to the window procedure associated with the window handle specified in the MSG structure. If the window handle is HWND_TOPMOST, DispatchMessage sends the message to the window procedures of all top-level windows in the system. If the window handle is NULL, DispatchMessage does nothing with the message. An application's main thread starts its message loop after initializing the application and creating at least one window. Once started, the message loop continues to retrieve messages from the thread's message queue and to dispatch them to the appropriate windows. The message loop ends when the GetMessage function removes the WM_QUIT message from the message queue. Only one message loop is needed for a message queue, even if an application contains many windows. DispatchMessage always dispatches the message to the proper window; this is because each message in the queue is an MSG structure that contains the handle of the window to which the message belongs. You can modify a message loop in a variety of ways. For example, you can retrieve messages from the queue without dispatching them to a window. This is useful for applications that post messages not specifying a window. You can also direct GetMessage to search for specific messages, leaving other messages in the queue. This is useful if you must temporarily bypass the usual FIFO order of the message queue. An application that uses accelerator keys must be able to translate keyboard messages into command messages. To do this, the application's message loop must include a call to the TranslateAccelerator function. For more information about accelerator keys, see Keyboard Accelerators. If a thread uses a modeless dialog box, the message loop must include the IsDialogMessage function so that the dialog box can receive keyboard input. 20) Explain the role of DLLs in programming windows?

DLL Stands for Dynamic Link Library.A DLL is a binary file that provides library of functions,objects and resources.All the API functions are contained in Dynamic Link Libraries.The function present in DLLs can be linked during execution.These functions can also be shared between several applications running in windows.Since linking is done dynamically the functions do not become part of the executable file.As a result the size of EXE files do not go out of band.It is also possible to create your own DLLs .You can create your own DLLS for sharing common codes between different executable files,breaking an application in to component parts to provide a way to easly upgrade applications component and keeping resource data out of an applications executable,but still readly accessible to an application. 21) Explain the features and advantages of MFC. MFC is an abbreviation for Microsoft Foundation classes. MFC provides an object oriented framework that the application developers can use to create windows applications. MFC is organized as a hierarchy of C++ classes. Several high level classes provide general functionality while low level classes implement more specific behaviors. MFC was introduced in 1992 with Microsoft's C/C++ 7.0 compiler for use with 16-bit versions of Windows. It was part of an overall Microsoft effort to gain market share for development tools, and it was designed to showcase the capabilities of the C++ programming language. C++ was just beginning to replace C for development of commercial application software and C/C++ 7.0 was the first of Microsoft's compilers to add C++ support. The MFC is a C++ class library and an application framework for Microsoft Windows. The MFC encapsulate the Windows API in C++ classes. In a MFC application, we dont need to call the Windows API directly, just creating objects from MFC classes and call member functions belonging to those objects. The MFC offers C++ base classes for the user interface, general- purpose classes for collections, files, persistent storage, diagnostics, memory management, strings, time, and other for creating Windows- based applications (MFC applications) in an object- oriented way.

Features When MFC was introduced, Microsoft extended the C++ syntax with a series of macros for management of Windows messages (via Message Maps), exceptions, run time type identification, and dynamic class instantiation. A macro in is a rule or pattern that specifies how a certain input sequence (often a sequence of characters) should be mapped to an output sequence (also often a sequence of characters) according to a defined procedure. The macros for Windows messages were intended to reduce memory required by avoiding needless virtual table use and provide a more concrete structure for various Visual C++ supplied tools to edit and manipulate code without parsing the full language. The message-handling macros replaced the virtual function mechanism provided by C++.

MFC provides really nice classes for doing windows programming. It has taken away all the pains of SDK, where a programmer is expected to handle everything in the world except writing for application logic The main features provided by MFC are 1) Document /view architecture MFC provides an application development model called document /view model .It is a method designing an application so that the application data is separated from the user interface elements so that programmer can make changes to one without changing the other. The document object usually represents file that the application has opened while the view window provides a visual presentation of the documents data and accepts user interaction. Eg:- Consider a word processor or spread sheet application The data contained in the application is the documents and the presentation of the data is the view

CDocument class Contains data

Pointer to CView1

Pointer to CView2

Pointer to CView3

This shows a one to many relationship between the document and its views .The document stores the data and manages printing the data and coordinates updating multiple views of the data. There are four main classes used in a Document/View application.
1. The Document class derived from Document- controls the data used by the application, which

includes the storage when necessary. 2. The View class derived from CView - Displays information about the document to the user and handles any interaction between the user and the document. 3. The Frame class derived from CFrmWnd- Physically contains the view, menu, toolbar etc. 4. The Application class derived from CWinApp- Controls the application level interaction with window. 2) Multiple document Interface (MDI) MDI are those whose windows reside under single parent window .In a single document interface all windows are separated from each other.

Tool bar

Some text

Egs of MDI word ,excel ,power point adobe Photoshop. Egs of SDI Windows explorer, Internet explorer, notepad. 3) Print and print preview Support 4) Using and creating ActiveX Controls ActiveX is -reusable components that can be plugged in to VB,VC++ etc. -examples calendars, spellcheckers, image editor 5) ODBC and Access database support 6) Internet (TCP/IP) programming support 7) Multithreaded support 26) Differentiate between windows API & MFC programming? API is an acronym for Application Programming Interface.It is simply a set of functions that are part of Windows OS. Programs can be created by calling the functions present in the API.The programmer doesnt have to bother about the internal working of the functions .By just knowing function prototype and return value he can invoke the API functions. A good understanding of Windows API would help you to become a good Windows programmer .Windows itself uses the API to perform its GUI magic. Windows APIs are of two basic varieties: API for 16-bit Windows (Win16 API) API for 32-bit Windows (Win32 API) Each of these have sub-APIs within it. If you are working in Windows 3.1 then you have to use Win16 API and in Windows NT you have to use Win32 API. VC++ provides us a rich class library called the MFC Library, which is a set of C++ classes that encapsulate the functionality of applications written for the Microsoft Windows Operating System. The class library gives you a complete application framework .The framework defines an architecture for integrating user interface of an application for Windows with the rest of the application. It also provides implementations for a set of the user-interface components.MFC represents entire family of class libraries.MFC offers high level of abstraction that lets you focus in details to your application while allowing its classes to be customized and extended.MFC makes programming in Windows and C++ a much more productive endeavour.It is a collection of Windows API calls which are written in C.Programming in MFC reduces the code to a considerable extent as compared to SDK.

27) What are messages? In the event driven programming model that Windows is based on, Windows sends numerous messages to the application. For example a message is sent when the window is first being created. Messages are also sent when a menu item is clicked,or the window is moved or the window is resized.There are over 200 messages that Windows can send to an application.Some of these messages are placed in a message queue.These are known as queued messages.A Window program has a message loop that retrieves messages from the message queue by calling the GetMessage() function and dispatches them to the window procedure by calling the DispatchMessage() function.At times Windows sends messages to the application by straight-way calling the window procedure instead of following the message loop route.The message which are sent to the application by directly calling its window procedure are called nonqueued message.So windows procedures gets two type of messages for the application.The queued messages are posted to the window procedure and non-ueued messages are sent to the window procedure. 28) What is an MFC class? Explain the significance of C object. A part of the MFC class hierarchy is shown in the below figure. At the top is a class called CObject. This base class provides various run- time support features, including run- time type information, serialization, and diagnostics. Many MFC base classes are derived directly from CObject. Some of the most commonly used derived MFC classes are CCmdTarget, CWinApp, CDocTemplate, CWnd, CDocument, CFrameWnd, CView, CDialog, and CMDIFrameWnd. The serialization feature of the MFC base class CObject allows building persistent objects. A persistent object store itself on disk or some other type of storage device and be restored later - usually by a subsequent invocation of the program.

In the Windows programming model, applications respond to events by processing messages sent by Windows. An event could be a keystroke, a mouse move, or something else. For message processing, MFC applications use message maps to correlate incoming messages with class member functions. To use a MFC message map, a class must be derived from the MFC top level base class CCmdTarget. This class encapsulates the basics for message processing. Some of the other important MFC base classes are: CWinApp: The CWinApp class is the base class from which you derive a Windows application object. An application object provides member functions for initializing your application and for running the application.

CDocTemplate: The CDocTemplate class is derived from the CCmdTarget base class. The MFC class CDocTemplate provides some basic functionality for the MFC document / view architecture and works in conjunction with the CDocument and CView classes. CWnd: The CWnd class provides the base functionality of all window classes in the MFC. The CWnd class encapsulates the properties of a window. This class also provides default handlers for many messages and offers many member functions. CDocument: The CDocument class is derived from the base class CCmdTarget. The CDocument class provides the basic functionality for MFC user- defined document classes. A document is a part of the MFC document / view architecture. CFrameWnd: The CFrameWnd class is derived from the CWnd base class. The CFrameWnd class provides the functionality of a Windows single document interface (SDI) overlapped or pop- up frame window, along with members for managing the window. CView: The CView class is derived from the base class CWnd. The CView class provides the basic functionality for MFC user- defined view classes. A view is a part of the MFC document / view architecture. CDialog: The CDialog class is derived from the base class CWnd. The CDialog class provides the basic functionality of a Windows dialog box window, along with members for managing the window. CMDIFrameWnd: The CMDIFrameWnd class is derived from the CFrameWnd base class. The class CMDIFrameWnd provides the functionality of a Windows multiple document interface (MDI) frame window, along with members for managing the window

II. THE CObject BASE CLASS Almost every significant object in an MFC program is a CObject instance. Every window in an MFC program is a CWnd object which is derived from the CObject class. CObject has the following basic functions which can be controlled by using macros in the derived classes: 1. 'Memory Leak Detection' management. It requires no macros. 2. Runtime class identification. This requires the use of the macro 'DECLARE_DYNAMIC' in the class declaration (header file with extension as .h) and the use of macro 'IMPLEMENT_DYNAMIC' in the class definition (source file with extension as .cpp) formation (RTTI) capability. 3. Dynamic object creation (uses the CRuntime class). This requires the use of the macro 'DECLARE_DYNCREATE' in the class declaration (header file with extension as .h) and the use of macro 'IMPLEMENT_CREATE' in the class definition (source file with extension as .cpp) formation (RTTI) capability. 4. Serialization support. Storing an object on hard disc and loading it later is called serialization. This requires the use of the macro 'DECLARE_SERIAL' in the class declaration (header file with extension as .h) and the use of macro 'IMPLEMENT_SERIAL' in the class definition (source file with extension as .cpp) formation (RTTI) capability.
5. Run-time object diagnostics

All CObject-derived MFC classes have a Dump member function that you can call to print out a C++s object state at run time

37) What are message map? Explain working with an example? Message Maps In MFC window class, a message map is used to link member functions to messages. Message map is a simple associative array where keys are message types (WM_PAINT, ...) and elements are function pointers. MFC provides an alternative to the switch statement used in traditional Windows programs to handle messages sent to a window. Message Maps are the way by which MFC handles the Application messages. Any class which is derived from CCmdTarget is a candidate for handling messages. A mapping from messages to member functions may be defined so that when a message is to be handled by a window, the appropriate member function is called automatically. This message-map facility is designed to be similar to virtual functions but has additional benefits not possible with C++ virtual functions. The application should have a function to handle the messages and do the actions according to the commands passed to it. Following code is an example for creating MFC Application with message map. //MFC2.CPP - MFC #include <afxwin.h> class MFC_Tutorial_Window :public CFrameWnd { public: MFC_Tutorial_Window() { Create(NULL,"MFC Tutorial Part 2 CoderSource Window"); } void OnLButtonDown(UINT nFlags, CPoint point); DECLARE_MESSAGE_MAP() }; BEGIN_MESSAGE_MAP( MFC_Tutorial_Window, CFrameWnd) ON_WM_LBUTTONDOWN() //Macro to map the left button click to the handler END_MESSAGE_MAP() void MFC_Tutorial_Window::OnLButtonDown(UINT nFlags, CPoint point) { // TODO: Add your message handler code here and/or call default CFrameWnd::OnLButtonDown(nFlags, point); MessageBox("Left Button clicked"); } class MyApp :public CWinApp { MFC_Tutorial_Window *wnd;? public:

BOOL InitInstance() { wnd = new MFC_Tutorial_Window(); m_pMainWnd = wnd; m_pMainWnd->ShowWindow(1); return 1; } }; MyApp theApp; //End of program There are 4 macros which are used here for implementing this concept. DECLARE_MESSAGE_MAP: This tells the application that the class in which this is called is going to have a message map and handle messages. A class can have only one message map. Also a class will be eligible to execute a message map if it is derived from CCmdTarget or a class which is derived from CCmdTarget. BEGIN_MESSAGE_MAP & END_MESSAGE_MAP: This macro takes two parameters. The class name which implements the message map and the base class for it. It then is succeeded by the macros which represent messages viz., ON_WM_LBUTTONDOWN, ON_WM_SIZE etc., It is then closed by END_MESSAGE_MAP ON_WM_LBUTTONDOWN: This is the macro which declares that the MFC_Tutorial_Window is going to handle Left button clicks and the function which will handle this is OnLButtonDown(UINT nFlags, CPoint point). When there is any click related to this class, the mentioned function will be called automatically with the specific parameters. This is how all the messages are handled. The function name corresponding to the message map ON_WM_XXX() will be always OnXxx().number arguments to the function and the return value will be different for each message.for example the OnPaint() has got zero aruguments and OnLButtonDown() has got 2 arguments. 65)What are the different function calling conventions available in Visual C++? CDECL In most C compilers, the CDECL calling convention is the de facto standard. However, the programmer can specify that a function be implemented using CDECL by prepending the function declaration with the keyword __cdecl. Sometimes a compiler can be instructed to override cdecl as the default calling convention, and this declaration will force the compiler not to override the default setting. CDECL calling convention specifies a number of different requirements: 1. Function arguments are passed on the stack, in right-to-left order. 2. Function result is stored in EAX/AX/AL 3. The function name is prepended with an underscore. CDECL functions are capable of accepting variable argument lists. STDCALL STDCALL is the calling convention that is used when interfacing with the Win32 API on Microsoft Windows systems. STDCALL was created by Microsoft, and therefore isn't always supported by non-

microsoft compilers. STDCALL functions can be declared using the __stdcall keyword on many compilers. STDCALL has the following requirements: 1. Function arguments are passed on the stack in right-to-left order. 2. Function result is stored in EAX/AX/AL 3. Function name is prepended with an underscore 4. Function name is suffixed with an "@" sign, followed by the number of bytes of arguments being passed to it. STDCALL functions are not capable of accepting variable argument lists. For example, the following function declaration in C: _stdcall void MyFunction(int, int, short); would be accessed in assembly using the following function label: _MyFunction@12 Remember, on a 32 bit machine, passing a 16 bit argument on the stack (C "short") takes up a full 32 bits of space. FASTCALL FASTCALL functions can frequently be specified with the __fastcall keyword in many compilers. FASTCALL functions pass the first two arguments to the function in registers, so that the timeconsuming stack operations can be avoided. FASTCALL has the following requirements: 1. The first 32-bit (or smaller) argument is passed in EAX/AX/AL 2. The second 32-bit (or smaller) argument is passed in EDX/DX/DL 3. The remaining function arguments (if any) are passed on the stack in right-to-left order 4. The function result is returned in EAX/AX/AL 5. The function name is appended with an "@" symbol 6. The function name is suffixed with an "@" symbol, followed by the size of passed arguments, in bytes. 66) What are the arguments to the Create Window() Function? There are 11 arguments to Create window function and it returns an handle to the window. Hwnd=CreateWindow(szAppName // window class name Text //windows caption WS_OVERLAPPEDWINDOW //window style CW_USEDEFAULT //intial x position CW_USEDEFAULT //initial y position CW_USEDEFAULT // initial width of window CW_USEDEFAULT //initial height of window NULL //parent window handle NULL //window menu handle Hinstance // program instance handle NULL ) ; //creation parameters First parameter is the class name to which window is registered.second argument is the window title or window caption.Third argument specifies the window style.fourth and fifth arguments are the initial coordinates of the top left corner of the window.sixth and seventh arguments are the window width and window height respectively.Next two arguments are the parent window handle and menu handle.tenth argument is the program instance handle and it one of the parameters to WinMain Function.Last parameter is the window creation parameter.few arguments are set to null or zero normally when we call the CreateWindow() function

67) What are the fields available in the message structure(MSG)? There are 6 fields in the message structure. They are HWND hwnd; UINT message; WPARAM wParam; LPARAM lParam; DWORD time; POINT pt; First parameter is the handle to the window to which the message is associated Second parameter is the message itself.third and fourth parameters are message parameters and its value depend up on the particular message.fifth parameter stores the time at which the message was generated.sixth parameter is structure which encloses the mouse co-ordinates at the time at which message was generated. 68) What are the fields available in the WNDCLASS ? There are 10 fields in the window class.they are UINT style; WNDPROC lpfnWndPROC Int cbClsExtra; Int cbWndExtra; HINSTANCE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCTSTR lpszMenuName; LPCTSTR lpszClassNAme; First argument specifies the window style.Second argument specifies the window procedure to which control should go when we call dispatch message() function.Third and fourth argument specifies the extra space for class and window.fifth argument is an handle to the application instance to which the window belongs.Sixth argument can be used to select the ICON for the window,while seventh argument can be used for selecting the CURSOR for window.Next argument specifies the background color for the window.Last two argument are the menu name and name for the window class object. 71) What is a Device Context handle? What are the two methods for getting Device Context handle for windows client area? What are the methods to get device context handle for entire window and entire display?

Device context is really just a data structure maintained internally by GDI.A device context is associated with a particular display device such as video display or a printer. For video display a device context handle is associated with a particular window on the display. When a program needs to paint it must first obtain a handle to a device context. There are functions to get device context handle. Once handle is obtained you have functions to paint on the client area of the window. After program finished painting its client area, it should release the device context handle. When the handle is released, the handle is no longer valid and must not be used. There are two methods to get device context handle for client area Method 1 You use this method when you process the WM_PAINT message. There are two functions involved, they are BeginPaint and EndPaint. These two functions require the handle to the window, which is passed to the window procedure as argument and the address of a structure variable of type PAINTSTRUCT, which is defined in WINUSER.H. While processing WM_PAINT windows first calls beginpaint().it will return a device context handle and this handle can be used to paint on the window client area. After painting we call EndPaint() which will release the device context handle. Method 2 To get the handle to the device context of the client area of the window,you can call GetDC to obtain the handle and ReleaseDC after you are done with the handle. Like BeginPaint() and EndPaint(), the GetDC() and ReleaseDC() should be called in pair. To get a device context handle for entire window we can use the function GetWindowDC(hwnd).Here the handle includes the windows title bar, menu, scroll bar and frame in addition to the client area. Application programmers rarely use GetWindowDC(). To release the above device context handle you should use ReleaseDC(hwnd,hdc). To get the device context handle for the entire display we can use CreateDC(DISPLAY,NULL,NULL,NULL).To release the device context handle we can call DeleteDC(hdc ). Sometimes you need to obtain some information about device context and not do any drawing. In this case you can obtain handle to an information context by using CreateDC. The arguments to these functions are same as that of CreateDC(). All the device context handle mentioned above are applicable to VC++.MFC Uses different classes such as CpaintDC, CClientDC, CWindowDC and CMetaFileDC for handling the problem of device context handle. 74) What is window procedure subclassing and super classing? When registering a window class, you fill in the members of the WNDCLASSEX structure and pass the address of the structure to the RegisterClassEx function. Of course, before calling RegisterClassEx, you must initialize the lpfnWndProc member of the WNDCLASSEX structure to point to the address of the class's window procedure. This procedure processes messages pertaining to all windows of this class. Before RegisterClassEx returns, the system allocates an internal block of memory that contains information about the window class. The class's window procedure address is part of this block. Whenever a new window is created, the system allocates another internal block of memory containing information specific to the new window. When the system allocates and initializes the block of memory for this window, the system copies the class's window procedure address from the class's internal memory block into the window's internal memory block. When a message is dispatched to a window

procedure, the system examines the value of the window procedure in the window's memory block and calls the function whose address is stored there. The system does not use the window procedure address stored in the window class's memory block when dispatching a message to a window. The window procedure address stored in the class's memory block is there only so that it can be copied when a window is created--the system does not use this address for any other purpose. To subclass a window, you change the window procedure address in the window's memory block to point to a new window procedure. Because the address is changed in one window's memory block, it does not affect any other windows created from the same class. If the system did not give each window instance its own copy of the window procedure address, changing the class's address would alter the behavior of all windows in the class. If this were the case, subclassing a single edit control so that it would no longer accept digits also would cause all edit controls used within a single process to stop accepting digits. This certainly is not desirable. Once you have changed the window procedure address in the window's memory block, all messages destined for the window are sent to the function at this new address. This function must look exactly like a standard window procedure. In other words, its prototype must have an identical prototype. Once the message destined for the original window procedure has been sent to your procedure, you can: Pass it to the original procedure. This option is used for most messages. The reason for subclassing is usually to alter the behavior of a window only slightly. For this reason, most messages are passed to the original procedure so that the default behavior for this window class can be performed. Stop the message from being passed to the original procedure. For example, if you want an edit control to stop accepting digits, you examine WM_CHAR messages, check to see if the character (wParam parameter) is between 0 and 9, and, if it is, immediately return from the SubClassWndProc function. If the character is not a digit, you pass the message to the original window procedure for edit controls. Alter the message before sending it. If you want a combobox to accept only uppercase characters, examine each WM_CHAR message and convert the key (contained in wParam) to uppercase (using the CharUpper function) before passing the message to the original procedure. Window superclassing is similar to window subclassing. Again, you are associating a different window procedure address with a window to alter a single window's behavior slightly. With window superclassing, however, you create a new window class that has altered behavior. Superclassing is most useful if you intend to create several windows, all with slightly altered behavior. (There are some other differences between subclassing and superclassing that will be discussed later.) Creating a superclass is accomplished by registering a new window class. For example, let's say that your application needs to create several edit windows where each of the windows can accept only letters. You could create all the windows and then subclass each individually in order to get the desired effect, or you could use window superclassing. For window super classing, you must create a superclass window procedure that is almost identical to a window subclass procedure. The prototype is the same, and the way that you intercept messages is the same. In fact, the only difference is how you call the original window procedure The main difference between subclassing and superclassing is that subclassing alters the behavior of an existing window, while superclassing creates a new window class where all windows created by the class have altered behavior. It is better to use superclassing when you wish to create several windows whose behavior differs slightly from an existing window class. This is because it is easier to register a new class, give it a new name, and create windows of this new class than it is to create all the desired windows and use the function or macro to change the address of each of their window procedures. Windows subclassing uses the API functions SetWindowlong() and CallWindowProc().Superclassing uses the functions SetClassLong() and GetClassInfo().

SetWindowlong is used to store new window procedure address where as CallWindowProc is used to call the original window procedure from the new procedure.