Visual programming lab

HARDWARE REQUIRED
- P-IV/III PROCESSOR
- HDD 40GB
- RAM 128MB or above
SOFTWARE REQUIRED
- Window 2000/ME/XP
- Visual Studio 6.0/Visual Studio 2003
- SQL Server/MS-Access
RATIONALE BEHIND THE VP LAB

Visual Programming Lab basically covers two languages: Visual C++ and Visual Basic Microsoft Visual C++
is one of the most sophisticated and comprehensive software development environments available. It is a
compiler especially designed for windows programming.
Initially Windows programming was done using C. It took a very long time and a great deal of efforts on
the part of programmers to write the code for a very small program part. For example, creating and putting a
small window on the screen required around 5 pages of code in C. Then came the era of C++ which reduced
this time and efforts to a great extent. It also simplified the programming and made the program modules
manageable. Then Microsoft introduced MFC, the Microsoft Foundation Class Library, which is a package
of prewritten, ready-to-use code. Due to this prewritten code made available to the programmer, programming
efforts were further reduced to a large extent.
Visual C++ makes use of this class library and facilitates the programmer by making available a good
number of programming tools like menu editor and dialog editor for designing menus and dialog boxes
respectively. It takes us away from the conventional method of starting from the scratch and coding similar
programs & objects for normally every application. Visual C++ also provides the facility of various wizards that
lead us through a step by step process of building the skeleton of application. It also has a set of integrated
debugging tools. All these features make Visual C++ a complete programming environment specifically suited
for system level applications. Once you start appreciating the great power of Visual C++, you can design your
own editors, scribble applications or may be a whole GUI environment in a very short time.
Some of the features of Visual C++ are:
• Code reusability
• Application wizards for MFC applications, DLLs, ActiveX controls, ATL projects,
ATL COM Objects and ISAPI extensions
• Integrated development environment
• Components and Controls Gallery to store and access reusable controls and
components
• Portability across platforms
Visual C++ 6.0
Visual C++ 6.0 in particular provides lot of new features, some of which are mentioned
below:
. Visual C++ 6.0 provides a whole new set of wizards to build the skeleton
applications.
. It provides easier application coding and building and a greater support for ActiveX1
and Internet Technologies.
.
A number of new classes are added in Visual C++ 6.0 especially for internet related
requirements, like creating interface for accessing internet, downloading text & files,
using FTP & HTTP etc., that are collectively called WinInet classes.
The Visual C++ 6.0 editor is more intelligent as it provides the facility of automatic
completion of statements, which is also known as IntelliSense. This feature provides
the list of functions available with any object, syntax of the common functions and
even a brief idea about what these functions do as and when the user tries to use them.
The Visual C++ 6.0 compiler is faster and has a better throughput.
Visual C++ 6.0 components:
• VC++ Developer Studio - An integrated application, which provides a set of
Programming-tools.

• VC++ Runtime Libraries – These are the libraries that provide standard functions like
strlen and strcpy etc. that can be called from a standard C or C++ functions.
• MFC and Template Libraries – The extensive C++ class library especially designed
for creating GUI programs.
• VC++ Build Tools – It comprises of C/C++ Compiler, the Linker, resource compiler
especially designed for compiling the resources and some other tools required for
generating a 32-bit Windows programs.
• ActiveX
• Data Access Components – This includes Database drivers, controls and other tools
required by VC++ to interact with Databases.
• Enterprise Tools – These are the advanced level Tools like Application Performance
explorer or Visual Studio Analyzer.2
• Graphics – Consist of Bitmaps, Metafiles, Cursors and icons available for inclusion in
the application.
PROGRAM 1
OBJECT OF THE PROGRAM: Study Window’s API and Their Relationship
with MFC classes
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 doesn’t
have to bother about the internal working of the functions. By just knowing the 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 amazing GUI magic.The Windows APIs are of two basic varieties:
API for 16-bit Windows (Win16 API)
API for 32-bit Windows (Win32 API)

Each of these has sub-APIs within it. If you are to program Windows 3.1 then you have to use Win16 API,
whereas for programming Windows95 and WindowsNT you have to use Win32 API.
Win16 is a 16-bit API that was created for 16-bit processors, and relies on 16-bit values. Win32 is a 32-bit API
created generation of 32-bit CPUs and it relies on 32-bit values.
Win16 API Win32 API Description
USER.EXE USER32.DLL The USER components is responsible for
window management, including messages,
menus, cursors, communications, timer etc.
GDI.EXE GDI32.DLL The GDI management is the Graphics Device
Interface; it takes care of the user interface
And graphics drawing, including Windows
metafiles, bitmaps, device contexts, and
fonts.
KRNL386.EXE KERNEL32.DLL The KERNEL component handles the low
level functions of memory, task, and resource
Management that are the heart of Windows.
The Win16 and Win32 APIs ere similar in most respects, but the Win16 API can be considered as a subset of
Win32 API.Win32 API contains almost everything that the Win16 API has, and much more.
At its core each relies on three main components to provide most of the functionality of Windows. These core
components along with their purpose are shown in the table given above.
Although the Win16 versions of these components have .EXE extensions, they are actually all DLLs and cannot
execute on their own.
The Win32 API has many advantages, some obvious and others that are not so
obvious. The following lists major advantages that applications have when
developed with the Win32 API and a 32-bit compiler (such as Microsoft’s
Visual C++) :-
• True multithreaded applications.
Win32 applications support true preemptive multitasking when running on Windows 95
and Windows NT.
• 32-bit linear memory.
Applications no longer have limits imposed by segmented memory. All memory
pointers are based on the applications virtual address and are represented as a 32-bit
integer.
• No memory model.

The memory models (small, medium, large, etc.) have no meaning in the 32-bit environment. This means
there is no need for near and far pointers, as all pointers can be thought of as far.
• Faster .
A well-designed Win32 application is generally faster. Win32 applications execute
more efficiently than 16-bit applications.
• Common API for all platforms. The Win32 API is supported on Windows 95,
Windows NT on all supported hardware, Windows CE, and the Apple Macintosh.
MFC ( Microsoft Foundation’s Class)
The C++ class library that Microsoft provides with its C++ compiler to assist programmers in creating
Windows-based applications. MFC hides the fundamental Windows API in class hierarchies, so that,
programmers can write Windows-based applications without needing to know the details of the native Windows
API.
The MFC classes are coded in C++. It provides the necessary code for managing windows, menus and
dialog-boxes. It also helps in carrying out basic tasks like performing basic input-output, storing the collection
of data objects etc. It provides the basic framework for the application on which the programmer can build the
rest of the customized code.
MFC Library is a collection of classes in hierarchical form, where classes are derived from some base
class. For most of the classes provided by MFC, base class is CObject from which most of the classes are
inherited. The rest few classes are independent classes. The classes in MFC Library can be categorized as:
• Root Class: CObject
• MFC Application Architecture Classes
• Window, Dialog, and Control Classes
• Drawing and Printing Classes
• Simple Data Type Classes
• Array, List, and Map Classes
• File and Database Classes
• Internet and Networking Classes
• OLE Classes
• Debugging and Exception Classes
In addition to these classes, the Microsoft Foundation Class Library contains a number of
global functions, global variables, and macros.
The Microsoft Foundation Class Library (MFC) supplies full source code. The full source
code is supplied in the form of Header files (.H) that are in the MFCInclude directory and implementation files
(.Cpp) that are in the (MFCSrc) directory

MFC Library was especially designed to provide an object oriented interface to windows, simultaneously
providing the compatibility with the windows programs written in C language. The compatibility with C
language was required as the Windows was developed long before MFC came into existence and hence all the
applications for Windows were initially written in C, a large number of which is still in use.
MFC Library provides the following features:
• Significant reduction in the effort to write an application for Windows.
• Execution speed comparable to that of the C-language API.
• Minimum code size overhead.
• Ability to call any Windows C function directly.
• Easier conversion of existing C applications to C++.
• Ability to leverage from the existing base of C-language Windows programming
experience.
• Easier use of the Windows API with C++ than with C.
• Easier-to-use yet powerful abstractions of complicated features such as ActiveX,
database support, printing, toolbars, and status bars.
• True Windows API for C++ that effectively uses C++ language features.
Advantages of MFC
Microsoft Foundation Class Library greatly reduces the development time, makes the
code more portable, provides support without reducing the programming freedom and
flexibility and provides easy access to user interface elements and technologies like
ActiveX and Internet programming which are otherwise very hard to program.
By using MFC, developers can add many capabilities to their applications in an easy,
object-oriented manner. MFC simplifies database programming by providing Data
Access Objects (DAO) and Open Database Connectivity (ODBC) and network
programming through Windows Sockets.
MFC offers many advantages like:
• Application Framework
• Largest base of reusable C++ source code
• Integration with Visual C++
• Flexible and fast database access
• Support for Internet and ActiveX technology
• Support for messaging API
• Support for multithreading
MFC is not only library of classes. MFC is also an application framework.MFC helps to define the structure of
an application and handles many routine chores on the application’s behalf.
Starting with CWinApp, the class that represents that represents the application itself, MFC encapsulates
virtually every aspect of a program’s operation. The framework supplies the WinMain() function, and
WinMain() in turn calls the application object’s member functions to make the program go. One of the

CWinApp member functions called by WinMain()- Run() – encapsulates the message loop that literally runs the
program.
PROGRAM 2
OBJECT OF THE PROGRAM: Study essential classes in Document View
Architecture and Their Relationship with each other
Parts of Application
The application source code generated for you by AppWizard actually consists of 4 major
classes. All these classes can be seen by expanding the class listing in the Class View tab.
For each of these classes corresponding header file (.h) and an implementation file (.cpp)
is generated.
The MainFrame Window Class
This class is named CMainFrame and is derived from the MFC class CFrameWnd. This
class manages the main window of the application that contains the window frame, Menu
bar, Toolbar, Status bar, System menu and Minimise, Maximise and Close boxes and also
contains the view window of the application.
The Application Class
This class named C ProjectNameApp is derived from the MFC class CWinApp. It manages the application as a
whole by managing the tasks, like initialising the application
instance, managing the message loop and performing final cleanup of the program.
The Document Class
This class named C ProjectNameDoc is derived from the MFC class CDocument. It is
responsible for storing the program data as a single string and reading and writing this
data to disk files.
The View Class
The class named C projectNameView is derived from CView class from the MFC classes.It manages the view
window, which is used to display program data on the screen and also used in processing the input from the
user.
MFC and AppWizard use the Document/View architecture to organize programs written for Windows.
Document/View separates the program into four main classes:
• A document class derived from CDocument
• A view class derived from CView
• A frame class derived from CFrameWnd
• An application class derived from CWinApp

Each of these classes has a specific role to play in an MFC Document/View application. The document class is
responsible for the program's data. The view class handles interaction between the document and the user. The
frame class contains the view and other user interface elements, such as the menu and toolbars. The application
class is responsible for actually starting the program and handling some general-purpose interaction with
Windows. Figure shows the four main parts of a Document/View
The
Document/View
architecture.
Although the name
"Document/View" might
seem to limit you to only
word-processing
applications, the
architecture can be used in a wide variety of program types. There is no limitation as to the data managed by
CDocument; it can be a word processing file, a spreadsheet, or a server at the other end of a network connection
providing information to your program. Likewise, there are many types of views. A view can be a simple
window, as used in the simple SDI applications presented so far, or it can be derived from CFormView, with all
the capabilities of a dialog box. You will learn about form views in Section 23, "Advanced Views."
SDI and MDI Applications
There are two basic types of Document/View programs:
• SDI, or Single Document Interface
• MDI, or Multiple Document Interface
An SDI program supports a single type of document and almost always supports only a single view. Only one
document can be open at a time. An SDI application focuses on a particular task and usually is fairly
straightforward.
Several different types of documents can be used in an MDI program, with each document having one or more
views. Several documents can be open at a time, and the open document often uses a customized toolbar and
menus that fit the needs of that particular document.
Why Use Document/View?

The first reason to use Document/View is that it provides a large amount of application code for free. You
should always try to write as little new source code as possible, and that means using MFC classes and letting
AppWizard and ClassWizard do a lot of the work for you. A large amount of the code that is written for you in
the form of MFC classes and AppWizard code uses the Document/View architecture.
The Document/View architecture defines several main categories for classes used in a Windows program.
Document/View provides a flexible framework that you can use to create almost any type of Windows program.
One of the big advantages of the Document/View architecture is that it divides the work in a Windows program
into well-defined categories. Most classes fall into one of the four main class categories:
• Controls and other user-interface elements related to a specific view
• Data and data-handling classes, which belong to a document
• Work that involves handling the toolbar, status bar, and menus, usually belonging to the frame class
• Interaction between the application and Windows occurring in the class derived from CWinApp
Dividing work done by your program helps you manage the design of your program more effectively.
Extending programs that use the Document/View architecture is fairly simple because the four main
Document/View classes communicate with each other through well-defined interfaces. For example, to change
an SDI program to an MDI program, you must write little new code. Changing the user interface for a
Document/View program impacts only the view class or classes; no changes are needed for the document,
frame, or application classes.
Documents
Documents are the basic elements that are created and manipulated by the application.
Windows provides a graphic interface that gives a user a natural way to use the
application. To implement this interface, the developer has to provide ways to see and
interact with the information that the application creates and uses.
A document is simply a place to collect common data elements that form the processing
unit for the application.
Documents and the Application Relationship
The application class uses documents as a way to organize and present information to the
user. Each application derived from the MFC defines at least one type of document that is
a part of the application. The type of document and the number of documents that the
application uses are defined in the code of the application class.
As we have already discussed, MFC supports two types of applications – MDI and SDI.
MDI - In applications that support Multiple Document Interface, a number of text files
can be opened for editing at once; each in a different window. Each of the open files has
a corresponding document. Also, in MDI, the same document can have multiple views,
where a window is split. Each pane of the window can show a different portion of the
data whereas this data is coming from a common source, the document.
SDI - In applications with Single Document Interface only one document is open at a
time. A SDI application does not have a Window menu and the File menu does not have
a Close option because only one document can be open at a time, opening a document
automatically closes the current document. These are two common characteristics of a
SDI application.
Why Documents
The fundamental responsibility of the document is to store all the elements that constitute

an application unit. An application may support more than one type of data like numbers,
text, drawings etc.
The document also controls all the views associated with it. As the user opens and
manipulates windows on the screen, views are created and the document is associated
with each view. The document is responsible for controlling and updating the elements
within a given view.
The view may either request the document to draw its components or directly request the
components to draw themselves. It must provide a device context where the drawing
occurs. All elements of a drawing must be able to display themselves correctly upon
request.
Views
The view is the user’s window to the document. The user interacts with a document using
the view. Each active document will have one or more active views available on the
display. Generally, each view is displayed in a single window.
Why Views
The view gives the document a place to display information. It is the intermediary
between the document, which contains the information and the user.
The view organises and displays the document information onto the screen or printer and
takes in the user input as information or operation on the document.
The view is the active area of the document. It has two functions –
Acts as the display area for the document data and
Acts as the input area where the user interacts with the document, normally
providing additional commands or data for the document to process.
All the information passes through the view before reaching the document. Therefore, if
an application handles mouse messages in functions like OnLButtonDown(), it first
receives the message, translates the information into an appropriate form and then calls
the required document function to process the mouse command.
Although view is responsible for displaying the document and its information, there are
two possibilities –
Let the view directly access the document’s data elements
Create a document function that handles access to the appropriate data member
The choice of writing directly in the view has two advantages –
It is the responsibility of the view to handle document display, so having the
code there is more appropriate
Placing the code in the view keeps all the code regarding the device context in
the view where it seems natural.
A view is always tied to a single document.
One document can have several views.
Opening another window on the document can create two views of the same document.
Alternative ways can be presented to look at the same information by implementing
different types of views for the document. For example, as we discussed in the beginning
of the chapter, in MS Excel same data can be viewed either in the form of a table or in the
form of different graphs.

Gaining Access to Document Data from the View
The view accesses its document’s data either with the GetDocument() function, which
returns a pointer to the document or by making the view class a C++ friend of the
document class.
The view then uses its access to the data to obtain the data when it is ready to draw or
otherwise manipulate it.
For example, from the view’s OnDraw() member function, the view uses GetDocument()
to obtain a document pointer. Then it uses that pointer to access a CString data member
in the document. The view passes the string to the TextOut() function.
PROGRAM 3
OBJECT OF THE PROGRAM: Creating a Dialog based Application
1. Open Visual C++ and click the New item in the File menu, opening the New
dialog box.
2. Now select the MFC AppWizard(exe) entry in the New dialog box.
3. Give the new program the name dialogbased in the Project name box.
4. Click OK to starts the Visual C++ AppWizard.
5. Click the option marked Dialog Based in the AppWizard, click Finish.
6. Here, the AppWizard indicates four classes will be created : CdialogbasedApp,
CMainFrame, CdialogbasedDoc, CdialogbasedView .
7. Click the Resources tab, open the Dialog folder, and click the entry for our program
main window, IDD_BUTTONS_DIALOG. This opens the dialog editor.
8 Add a new button with the caption “Click me” to our code.
9. Open Class Wizard to connect Click me button to our code.
10. Use Class Wizard to connect the button to an event handler, OnButton1().
11. Double-click IDC_BUTTON1 in the Object IDs box, and double click
BN_CLICKED in the Message Box. This creates OnButton1() :
void Cdialog::OnButton1()
{
}
12. Add a member variable, m_edit to EDIT box i.e IDC_EDIT1.
13. Add following code to OnButton1():
void Cdialog::OnButton1()
{
m_edit.SetWindowText(CString(“Good Morning “));
}

OBJECT OF THE PROGRAM 4: Creating a Notepad in VC++
dialog box.
3. Give the new program the name Keystrokes in the Project name box.
5. Click the option marked Single Document in the AppWizard, click Finish.
6. Here, the AppWizard indicates four classes will be created : CKeystrokesApp,
CMainFrame, CKeystrokesDoc, CKeystrokesView .
7. Declare the StringData variable on the document’s header file,
KeystrokesDoc.h, in the protected part.
class CKeystrokesDoc : public CDocument
{
protected: // create from serialization only
CKeystrokesDoc();
DECLARE_DYNCREATE(CKeystrokesDoc)
CString StringData;
.
.
};
8. Initialize that string to an empty string -“ “- in the document’s constructor, which
we find in KeystrokesDoc.cpp.
CKeystrokesDoc::CKeystrokesDoc()
{
StringData=" ";
// TODO: add one-time construction code here
}
9. Add a new event handler –OnChar( )- to our view class which is called every time
the user types the character.
10. The character the user typed is now in the nChar parameter, which we store in the
our data string object, StringData. The object in our document, so we need a
pointer(pDoc) to our document object.
11. Add the character nChar to the string StringData.
void CKeystrokesView::OnChar(UINT nChar, UINT nRepCnt,
UINT nFlags)
{
// TODO: Add your message handler code here and/or call default
CKeystrokesDoc* pDoc=GetDocument();
ASSERT_VALID(pDoc);
pDoc->StringData+=nChar;
Invalidate();
CView::OnChar(nChar, nRepCnt, nFlags);

}
12. We’ll handle the display of our data in the view’s OnDraw( ). We need to draw
the text string, which we do with TextOut( ).
void CKeystrokesView::OnDraw(CDC* pDC)
{
CKeystrokesDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
pDC->TextOut(0,0,pDoc->StringData);
// TODO: add draw code for native data here
}

PROGRAM 5
OBJECT OF THE PROGRAM: Serializing your own Objects & Class
dialog box.
3. Give the new program the name Serialize in the Project name box.
6. Here, the AppWizard indicates four classes will be created : CSerializeApp,
CMainFrame, CSerializeDoc, CSerializeView .
7. Click Project Add to Project New. A list of file types appear in the dialog box.
Choose C/C++ Header File(be sure that “Add to Project” checkbox is checked.
Type file name CData.h in the Edit Box.
8. Open the CData.h file and place the code :
class CData
{
private:
CString data;
public:
CData()
{ data=CString(" "); }
void AddText(CString text)
{ data+=text; }
void DrawText(CDC* pDC)
{ pDC->TextOut(0,0,data); }
void ClearText()
{ data=" "; }
};
CData() Constructor to initialize the string to empty .
AddText() to add more text to the end of string.
DrawText() to draw string in the device context.
ClearText() to clear the string.
9. Include this new file in the documents’ header & create a new object of CData class named
DataObject.
10. Now we add code to OnChar(), which adds the newly typed character to internal data in
DataObject using the AddText() method.
void CSerializeView::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)
{
CSerializeDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
pDoc->DataObject.AddText(CString(nChar));
Invalidate();
}

11. We draw the text in the DataObject object using the DrawText() method in the
OnDraw() method.
void CSerializeView::OnDraw(CDC* pDC)
{
CSerializeDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
pDoc->DataObject.DrawText(pDC);
}
12. To make class serializable, add code to CData class (i)- make it derived from MFC
CObject class.(ii)- Also include DECLARE_SERIAL macro to add the declarations of
the methods use for serialization. (iii)-Override CObject’s Serialize() method.
class CData : public CObject (i)
{
private:
CString data;
DECLARE_SERIAL(CData); (ii)
public:
CData()
{ data=CString(" "); }
void AddText(CString text)
{ data+=text; }
void DrawText(CDC* pDC)
{ pDC->TextOut(0,0,data); }
void ClearText()
{ data=" "; }
void Serialize(CArchive& archive);(iii)
};
13. To write new version of Serialize, add new file to the project : CData.cpp.
(i) Call base class’s Serialize() method(). (ii) Serialize our CString data member
using << & >> . (iii) Include IMPLEMENT_SERIAL macro, which adds additional
methods for serialization.
void CData::Serialize(CArchive& archive) (i)
{
CObject::Serialize(archive);
if(archive.IsStoring())
{
archive<<data; (ii)
}
else
{
archive>>data;
}
}
IMPLEMENT_SERIAL(CData,CObject,0); (iii)
14. To serialize our DataObject object, we have to call its Serialize() method in
document’s Serialize() method :
void CSerializeDoc::Serialize(CArchive& ar)
{
DataObject.Serialize(ar);

OBJECT OF THE PROGRAM 6: Database Connectivity in VC++
dialog box.
3. Give the new program the name dbvc in the Project name box.
4. Click Next button, There is a Question “ What Database support would you like to
include?”, click the VPio button labeled Database View with File Support.
5. Next, click the button labeled Data Source to open the Database Options box.
6. We select the DAO button, and specify the dbs.mdb filesas our Data source.
7. When the Select Database Tables appears, click the Student table and the OK
button.
Note :
8. Now we click the OK button and finish button in App Wizard, letting AppWizard
create the New Program.
9. Open the main view, IDD_DBVC_FORM, in the dialog editor, and add the
controls : two text boxes & a button with caption “ Display the current record’s
fields “.
10. Using Class Wizard, we connect an event handler, OnButton1() to the button &
four member variable m_text1, m_text2, m_text3, m_text4 to four text boxes &
four static box to four text boxes.
11.Add codes to OnButton1():
void CDbvcView::OnButton1()
{
m_text1=m_pSet->m_Name;
UpdateData(false);
m_text2=m_pSet->m_Roll_No;
UpdateData(false);
m_text3=m_pSet->m_Branch;
UpdateData(false);
m_text4=m_pSet->m_Semester;
UpdateData(false);
}

PROGRAM 7
OBJECT OF THE PROGRAM: Creating a Menu, Dialog Box and
Adding Shortcut &Accelerator Keys, Status Bar, Tools to the Menu items
dialog box.
3. Give the new program the name DME in the Project name box.
6. Here, the AppWizard indicates four classes will be created : CDMEApp,
CMainFrame, CDMEDoc, CDMEView .
7. Click Resources tab in the VC++ viewer window to open the Menu Editor, find
the folder marked Menu & open it. Double click the entry in that folder,
IDR_MAINFRAME, Opening the Menu Editor.
8. Add new menu item, Display to the Edit menu.
9. Double click this new menu item, opens the Menu Item Properties box. Place the
caption &Display, & makes Display a shortcut menu. In Prompt Box write
“Display the message”. This text appear in the status bar when user lets mouse
rest on this menu item.
10.check the grayed button in dialog box to disable the menu item.
11.Rebuild All and Execute

Value Added Experiments
OBJECT OF THE PROGRAM: Creating an ActiveX Control
dialog box.
2. Now select the MFC ActiveX ControlWizard entry in the New dialog box.
3. Give the new program the name boxer in the Project name box.
4. Accept all the defaults by pressing the Finish button.
5. We have to divide the control into four rectangles, naming those rectangles box1 to
box4 and declaring them in BoxerCtl.h:
class CBoxerCtrl : public COleControl
{
.
.
.
.
// Implementation
protected:
~CBoxerCtrl();
CRect box1;
CRect box2;
CRect box3;
CRect box4;
.
.
.
};
6. Now, we have four rectangles to divide the control up in OnDraw(), placing the
four boxes at upper left, upper right, lower left, and lower right.
7. Then we draw the four rectangles.
void CBoxerCtrl::OnDraw(
CDC* pdc, const CRect& rcBounds, const CRect& rcInvalid)
{
pdc->FillRect(rcBounds,
CBrush::FromHandle((HBRUSH)GetStockObject(WHITE_BRUSH)));
box1=CRect(rcBounds.left,rcBounds.top,
rcBounds.right/2,rcBounds.bottom/2); //6
box2=CRect(rcBounds.left,rcBounds.bottom/2,rcBounds.right/2
,rcBounds.bottom); //6
box3=CRect(rcBounds.right/2,rcBounds.top,
rcBounds.right,rcBounds.bottom/2); //6
box4=CRect(rcBounds.right/2,rcBounds.bottom/2,rcBounds.righ
t,rcBounds.bottom); //6

pdc->Rectangle(&box1); //7
}
8. To handle mouse click we add an eventhandler LButtonDown() using
ClassWizard.
9. We can record which of our flag rectangles the user clicked, and which rectangle to
fill with color- by setting up four new Boolean flags, fill1 to fill4, in the
CBoxerCtl header.
class CBoxerCtrl : public COleControl
{
.
.
// Implementation
protected:
~CBoxerCtrl();
CRect box1;
CRect box2;
CRect box3;
CRect box4;
boolean fill1;
boolean fill2;
boolean fill3;
boolean fill4;
.
.
};
10. Set those flags to false in the control’s constructor :
CBoxerCtrl::CBoxerCtrl()
{
InitializeIIDs(&IID_DBoxer,&IID_DBoxerEvents);
fill1=fill2=fill3=fill4=false;
}
11. In OnLButtonDown(), we can set the boolean fill flags using the handy
CRect method PtInRect(), which returns true if the point you pass to it is in a
certain rectangle, such as our box1 to box4 objects:
void CBoxerCtrl::OnLButtonDown(UINT nFlags, CPoint point)
{
fill1=box1.PtInRect(point);
Invalidate();
COleControl::OnLButtonDown(nFlags, point);
}

12. Invalidate() calls the OnDraw(), there we check the four Boolean fill flags
and fill the corresponding rectangle using the CDC method FillSolidRect():
void CBoxerCtrl::OnDraw(
CDC* pdc, const CRect& rcBounds, const
CRect& rcInvalid)
{
pdc->FillRect(rcBounds,
CBrush::FromHandle((HBRUSH)GetStockObject(WHITE_BRUSH)));
box1=CRect(rcBounds.left,rcBounds.top,
rcBounds.right/2,rcBounds.bottom/2);
box2=CRect(rcBounds.left,rcBounds.bottom/2,rcBounds.right/2
,rcBounds.bottom);
box3=CRect(rcBounds.right/2,rcBounds.top,
rcBounds.right,rcBounds.bottom/2);
box4=CRect(rcBounds.right/2,rcBounds.bottom/2,rcBounds.righ
t,rcBounds.bottom);
pdc->Rectangle(&box1);
if(fill1) pdc-> FillSolidRect(&box1,RGB(0,0,0));
if(fill2) pdc-> FillSolidRect(&box2,RGB(0,0,0));
if(fill3) pdc->
FillSolidRect(&box3,RGB(0,0,0));
if(fill4) pdc->
FillSolidRect(&box4,RGB(0,0,0));
}
13. To test “boxer”, start Build Build Boxer .ocx to build the
boxer.ocx and registered that control with Windows.
14. Select the ActiveX Control Test Container item in the tools menu, which brings
up the very useful test container tool.
15. Select Insert New Control item in the test container’s Edit menu
and Double click the Boxer control in the Insert Control box that
appears.This inserts our ActiveX control in the test container.
16. Click one of the boxes in the control,shading it. Clicking another rectangle shades
that rectangle instead.
17. To embed the ActiveX in a program.Create a new dialog based program now
named Boxerapp. To insert a control of Boxer type in this program : select
Project Add to Project Components and Controls, opening
the Components and Controls Gallery.
18. Double click on the Registered ActiveX Controls. Select the Boxer

Control entry and click insert button.This inserts the Boxer
control into the dialog’s editor’s toolbox, where it has an icon OCX.
OBJECT OF THE PROGRAM: Creating a Blinking Cursor
dialog box.
3. Give the new program the name Carets in the Project name box.
6. Here, the AppWizard indicates four classes will be created : CCaretsApp,
CMainFrame, CCaretsDoc, CCaretsView .
7. Declare the StringData variable on the document’s header file,
CaretsDoc.h, in the protected part.
class CCaretsDoc : public CDocument
{
CCaretsDoc();
DECLARE_DYNCREATE(CCaretsDoc)
CString StringData;
.
.
};
8. Initialize that string to an empty string -“ “- in the document’s constructor, which

we find in CaretsDoc.cpp.
CCaretsDoc::CCaretsDoc()
{
StringData=" ";
// TODO: add one-time construction code here
}
9. Add a new event handler –OnChar( )- to our view class which is called every time
the user types the character.
10. The character the user typed is now in the nChar parameter, which we store in the
our data string object, StringData. The object in our document, so we need a
pointer(pDoc) to our document object.
11. Add the character nChar to the string StringData.
void CCaretsView::OnChar(UINT nChar, UINT nRepCnt,
UINT nFlags)
{
CCaretsDoc* pDoc=GetDocument();
ASSERT_VALID(pDoc);
pDoc->StringData+=nChar;
Invalidate();
}
12. Set a boolean variable named CaretCreated in view object to keep track that caret
has been created or not & CaretPosition & x,y.
class CCaretsView : public CView
{
CCaretsView();
DECLARE_DYNCREATE(CCaretsView)
CPoint CaretPosition;
int x,y;
boolean CaretCreated;
// Attributes
.
.
};
13. Set CaretCreated to false in the View’s Constructor.
CCaretsView::CCaretsView()
{
CaretCreated=false;
// TODO: add construction code here
}
14. We’re ready to create our new caret. We’ll make the caret the same height
and width as our text.We call CreateSolidCaret() to actually create the caret.
15. We’ll store caret’s position in a new CPoint object named CaretPosition.
The CPoint class has two data members x & y which holds the position of
Caret.

16. Initially, set caret’s position to (0,0) in OnDraw().
17. We set the caret’s position with SetCaretPos(), show caret on the screen with
ShowCaret(), and set the CaretCreated Boolean flag to true.
18. In next step the caret is to move as the user types text.
19. Place the caret at the end of displayed text string.
20. To display the caret at the end of the text string, we first hide it using
HideCaret().
21. Set the CaretPosition & Show the Caret.
void CCaretsView::OnDraw(CDC* pDC)
{
CCaretsDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
if(!CaretCreated)
{
TEXTMETRIC textmetric;
pDC->GetTextMetrics(&textmetric);
CreateSolidCaret(textmetric.tmAveCharWidth/8,textmetri
c.tmHeight);//(14)
CaretPosition.x=CaretPosition.y=0;
//(16)
SetCaretPos(CaretPosition);//(17)
ShowCaret(); //(17)
CaretCreated=true; //(17)
}
pDC->TextOut(x,y,pDoc->StringData);
//(18)
CSize size=pDC->GetTextExtent(pDoc
->StringData); //(19)
HideCaret(); //(20)
CaretPosition.x=x+size.cx;
CaretPosition.y=y;
SetCaretPos(CaretPosition); //(21)
ShowCaret(); //(21)
// TODO: add draw code for native data here
}
22. To handle left mouse button down we select LButtonDown, point parameter , an
Object of the CPoint class, holds mouse’s present location.
23. Store the variables in x & y.
void CCaretsView::OnLButtonDown(UINT nFlags, CPoint point)
{
x=point.x;
y=point.y;
CCaretsDoc* pDoc=GetDocument();
ASSERT_VALID(pDoc);
pDoc->StringData.Empty();
Invalidate();

CView::OnLButtonDown(nFlags, point);
}

VISUAL PROGRAMMING
PRACTICAL FILE
Submitted To:- Submitted By:-
Mr. Dheerdawaj Rajat Suneja
Lect CSE 1856
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Soumya S. Behera
Lect CSE 1826
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Rahul Bansal
Lect CSE 1820
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Shivank Aggarwal
Lect CSE 1828
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Rahul Chhabra
Lect CSE 1829
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Prateek Malhotra
Lect CSE 1830
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Yash Khaneja
Lect CSE 1851
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Neetu Sharma
Lect CSE 1833
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Poonam
Lect CSE 1832
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Richa
Lect CSE 1812
6th Semester, CSE
UIET, MDU, Rohtak
VISUAL PROGRAMMING

PRACTICAL FILE
Mr. Dheerdawaj Vikas Jyani
Lect CSE 1825
6th Semester, CSE
UIET, MDU, Rohtak

Visual programming lab

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Visual programming lab (20)

More from Soumya Behera (12)

Visual programming lab