In this Opencart 3 tips and tricks, we are showing you how to make the friendly URLs in Opencart 3 and make changes in the .htaccess which will help in SEO and user-friendly URLs.
Enable SEO URL’s in the OpenCart Admin
First of all, enable the SEO URL’s in your store’s admin. Go to the Admin >>System >>Settings. Edit your store, and finally click the Server tab and set the SEO URLs radio to Yes and save your settings.
Rename the .htaccess.txt file to .htaccess
OpenCart provides a file called .htaccess.txt. Rename this file to .htaccess and you will be good to go. If you don’t have this file in your root directory where opencart installed, you need to make your own .htaccess file and then paste the following code:
# 1.To use URL Alias you need to be running apache with mod_rewrite enabled.
# 2. In your opencart directory rename htaccess.txt to .htaccess.
# For any support issues please visit: http://www.opencart.com
Options +FollowSymlinks
# Prevent Directoy listing
Options -Indexes
# Prevent Direct Access to files
Order deny,allow
Deny from all
# SEO URL Settings
RewriteEngine On
# If your opencart installation does not run on the main web folder make sure you folder it does run in ie. / becomes /shop/
RewriteBase /
RewriteRule sitemap.xml /index.php?route=feed/google_sitemap
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]
### Additional Settings that may need to be enabled for some servers
### Uncomment the commands by removing the # sign in front of it.
### If you get an "Internal Server Error 500" after enabling any of the following settings, restore the # as this means your host doesn't allow that.
# 1. If your cart only allows you to add one item at a time, it is possible register_globals is on. This may work to disable it:
# php_flag register_globals off
# 2. If your cart has magic quotes enabled, This may work to disable it:
# php_flag magic_quotes_gpc Off
# 3. Set max upload file size. Most hosts will limit this and not allow it to be overridden but you can try
# php_value upload_max_filesize 999M
# 4. set max post size. uncomment this line if you have a lot of product options or are getting errors where forms are not saving all fields
# php_value post_max_size 999M
# 5. set max time script can take. uncomment this line if you have a lot of product options or are getting errors where forms are not saving all fields
# php_value max_execution_time 200
# 6. set max time for input to be recieved. Uncomment this line if you have a lot of product options or are getting errors where forms are not saving all fields
# php_value max_input_time 200
Enter SEO Keywords for URL’s
Finally, you need to enter SEO keywords for every page, information, product, and category you want to have URL rewrite. You can find the field for SEO Keywords under the Data tab when editing and creating items.
Once you have entered the SEO Keywords your URL will be working. Now go and enjoy more traffic and happy customers.
Things to take into consideration while Enter SEO Keywords for URL’s
When SEO URLs are activated now on keep in mind the following things while inserting the data:
Always insert the SEO keywords while inserting the data
Remove space in the SEO keywords like for this “Backyard Water Slide” use “Backyard-Water-Slide”.
Remove special characters (/, & $ @ # etc) also, as some browser will not detect them.
The most important things are that SEO Keywords must be unique throughout the site if repeated then the system will be confused which to show and it shows errors.
I have found you are not inserting SEO keywords field for the category so insert it as well but remember must be unique through the site.
Today, I was wondering and searching in the Opencart forum but i was unable to find out the show all products like the category listing in the Opencart so decide to develop it and i was so tired today so i left it to the forum so hope to get the best module by Sunday :).
I have searched for the extensions but it was not free, it cost $10.
So i decided to make the things by my self and was able to make it but i was feeling so dizzy so left to the forum so that any one will like to extend further.
Please help me to broaden it. Installation:
1 – Unzip showallproduct.zip in the folder of your choice.
2 – Upload the files inside the “root” folder to your server, no other files are overwritten.
3- Link to link the page is “index.php?route=product/productall”
For OpenCart version 1.5.6.4 you have to download following:
All Product Display Module OpenCart Version 1.5.6.4
Install VqMod to show link of All Products in Menu
We moved the majority of the code to the common.js in the hope that this will be updated less than the product.tpl
– Seen as we are now using a function and not inline JS to animate the image, we can reuse this throughout the website. So I though why not show you how this could work with HTML5 data attribute and eventually this might be updated in the core.
The easiest way to remove the lines in the PHP files or in HTML files, aspx files cold fusion file, JSP file from the Dreamweaver. Likewise, we can remove the static page space like of the HTML, XSLT, CSS, XML, Javascript, XML and other as follows:
Open the file
Click CTRL + F
Select “Current document” in “Find in” (You can also select the folder if you have multiple files)
Search in “Source code”
Tick “Use regular expression”
Type “[rn]{2,}” (without quotes) in “Find”
Type “n” (without quotes) in “Replace”
Press “Replace All”
We can also replace the multiple line breaks through coding the coding is as below:
<?php
$base = array("f:/www/docs/files/");
while (!empty($base)) {
$next = array_pop($base);
foreach (glob($next . '*.php') as $item) {
if (!is_dir($item)) {
file_put_contents($item, preg_replace(array("#^s*r?n+#s", "#s*r?n+$#s", "#s*r?n+#s"), array("", "", "rn"), file_get_contents($item)));
} else {
$base[] = $item . '/';
}
}
}
echo "Removing extra lines is done";
?>
These are the two methods by which we can remove the extra lines.
This is final year report example on E-shopping, E-commerce with affiliation which details about the page title, declaration of the report, Acknowledgement, table of contents, and executive summary.
Final Year Report on E-shopping
named Rupjaygri Shop
By:
Rupak Nepali
P.U. Reg. No: #####, Roll. No: #####
Jayman Tamang
P.U. Reg. No: #####, Roll. No: ####
Grishma Shah
P.U. Reg. No: #####, Roll. No: ####
Final Year Project Report
Submitted To:
Nobel College
Faculty of management
Pokhara University
In partial fulfillment of the requirements for the degree of
Bachelor of Computer Information System (BCIS)
Kathmandu
November 2010
—————————————————————————–
Pokhara University
Faculty of Management
Nobel College
DECLARATION
We hereby declare that the work reported in this project work on E-shopping named Rupjaygri Shop submitted to Nobel College, Pokhara University is our original work done in the form of partial requirement for the degree of Bachelor of Computer Information System (BCIS) under the supervision of Mr. Surendra Shrestha Principal, Nobel College, and Mr. Dipesh Shrestha, Coordinator, Nobel College, Mr Sanjay Lama Project-Coordinator and Mr. Nimesh Shrestha Lecturer, Nobel College.
Grishma Sharma JaymanTamang Rupak Nepali
——————————————————–
Faculty of Management Studies
PokharaUniversity
RECOMMENDATION
This is to certify that the final year report:
Submitted by:
Rupak Nepali
Jayman Tamang
Grishma Sharma
Entitled
E-Shopping named Rupjaygri Shop has been prepared as approved by this college. This internship report is forwarded for examination.
——————————— ——————-
Principal Coordinator/Lecturer
Nobel College
Date: June 14, 2010
——————————————————————————
Acknowledgment
This report has been prepared for the Final Year Project on topic E-shopping named Rupjaygri Shop to implement the theory in the real field with the purpose of fulfilling the requirements of the course of BCIS (Bachelor of Computer Information System).
The aim of this project is to make familiar to the practical aspect and uses of theoretical knowledge and clarifying the career goals, so we have successfully completed the project and compiled this report as the summary and the conclusion that we have drawn from the project.
We would like to express our sincere gratitude to our Project Coordinator Mr. Sanjay Lama who had given his valuable time and given us chance to learn something despite having his busy schedule, Principal Mr. Surendra Shrestha and Coordinator Mr. Dipesh Shrestha for their great guidelines.
Lastly, we would like to thank Mr. Nimesh Shrestha who had provided us with the guidance and his easiest MVC framework and for his encouragement, patience and expert advice and also for supplying so much invaluable information and finally special thanks go to my friends and family who have supported us throughout our project.
——————————————————–
Table of Contents
SN
Contents
Page No
a.
Title Page
i
b.
Declaration
ii
c.
Recommendation
iii
d
Acknowledgment
iv
e.
Table of Contents
v
f.
List of Figures
vii
g.
Executive Summary
ix
h.
Chapters
Introduction 1.1. Background of Study 1.2. Objectives of the Study 1.3. Limitations of the Study 1.4. Selection Methods of Data Collection Report Body 2.1. Introduction of the D.P Sign 2.2. Corporate Goal of the D.P Sign 2.3. Mission Statement of the D.P Sign 2.4. D.P Sign™s Spirit is infused into every component
2.5. Services 2.5.1. Web-Based Application Design and Development 2.5.2. Flex printing and other printing services 2.5.3. Custom Software Solutions 2.5.4. Embedded Software Solutions 2.5.5. Online Earning Training
2.6. Engagement Models 2.6.1. Fixed Price Turnkey Model 2.6.2. Per Resource Model 2.6.3. Offshore Model
2.7. Delivery Model 2.8. Process and Standards 2.9. Domain Profile 2.10. Competitive Advantage of DP Sign 2.11. Physical Infrastructure 2.12. Organizational Hierarchy Chart 2.13. The number of employees 2.14. Introduction of Departments We have worked at 2.15. Major Clients 2.16. Business Volume 2.17. Products Offered by DP Sign 2.18. Time Frame of Internship Analysis
3.1. Strategic Business Units 3.1.1 Web Development Department Analysis 3.1.2 Online Earning Department Analysis 3.1.3 PEST Analysis 3.1.4 SWOT Analysis
4 Recommendations 5 Summary and Conclusion 6 Program Workplace Relationship
1 1 1 1 2 3 3 4 4 4 5
5 5 5 5 5 6 6
6 6 7 7
11 13 14 15 16 16 20 20 21 22 23 23 23
24 25 26 28 29
30
i.
Bibliography
j.
Appendices
List of Figures
SN
Name of Figure
Page No.
Fig:2.1
Organization Structure
13
Fig:2.2
The business volume of DP Sign
19
Fig:2.3
Timeframe representation in Gantt chart
22
List of Tables
SN
Name of Table
Page No.
Tab:2.1
System unit and its Software
11
Tab:2.2
List of technology with the platform
Tab:2.3
Number of employees
Tab:2.4
Collection of Pay Per Click sites
Tab:2.5
List of major clients
Tab:2.6
Printing product of DP Sign
Tab:2.7
Web services providing by DP Sign
ABBREVIATION USED
DP Sign
Digital Printed Sign
CRM
Customer Relation Management
IT
Information Technology
QA
Quality Assurance
CMS
Content Management System
SWOT
Strength, Weakness, Opportunity, and Threats
PEST
Political, Economical, Social and Technological
RFQ
Request For Quotation
RFP
Request For Proposal
GIS
Geographic Information System
PMBOK
Project Management Body of Knowledge
PMI
Project Management Institute
CMMI
Capability Maturity Model Integration
ISO
International Organization for Standardization
ODC
Offshore Development Center
IP
Internet Protocol
CVS
Current Version Software
TFS
Team Foundation Server
EXECUTIVE SUMMARY
The main objective of this report is to recapitulate our Final Year Project on E-shopping named Rupjaygri Shop and to be familiar with the practical aspect of the theoretical knowledge gained in a classroom. This report is the part of the final year project, required by Pokhara University in partial fulfillment for the requirement of BCIS program.
We (Rupak Nepali, Jayman Tamang, and Grishma Sharma) feel that Nepal is progressing in the ICT field thus the import and export of this country are mounting with the help of e-commerce and e-businesses. Thus, there is a need for shopping software so that people can broaden their business worldwide.
In this post, we are defining ActiveX Classes, Category Common classes, Database Classes, Client-Side Classes, SDI and MDI Applications, Document/View Architecture, Message Maps and provide some self-check questions.
ActiveX Classes
MFC provides classes that simplify the process of adding ActiveX capabilities to your applications and significantly reduce development time. The ActiveX classes work with the other application framework classes to provide easy access to the ActiveX API. Using the ActiveX classes, you can:
Create ActiveX controls and ActiveX control containers.
Use Automation to control one program with another.
Create compound documents, which enable users to create and edit documents containing various types of data, including text, graphics, spreadsheets, and sound. These various data objects can be created by different applications.
Create OLE objects that can be embedded in compound documents.
Use drag-and-drop to copy data between applications.
Note This course does not cover creating ActiveX components. For information about how to create and modify ActiveX components using MFC, see Mastering MFC Development Using Visual C++ 5, listed in the Library.
To see an illustration that shows the ActiveX and OLE classes within the MFC object hierarchy, click this icon.
ActiveX classes can be divided into the categories shown in the following table.
Category Common classes
ActiveX control classes COleControlModule, COleControl, CConnectionPoint, CPictureHolder, CFontHolder, COlePropertyPage, CPropExchange, CMonikerFile, CAsyncMonikerFile, CDataPathProperty, CCachedDataPathProperty, COleCmdUI, COleSafeArray Active Document classes CDocObjectServer, CDocObjectServerItem ActiveX-related classes COleObjectFactory, COleMessageFilter, COleStreamFile, CRectTracker Automation classes COleDispatchDriver, COleDispatchException Container classes COleDocument, COleLinkingDoc, CDocItem, COleClientItem OLE server classes COleServerDoc OLE drag-and-drop and data transfer classes COleDropSource, COleDataSource, COleDropTarget, COleDataObject OLE common dialog classes COleDialog, COleInsertDialog, COlePasteSpecialDialog, COleLinksDialog, COleChangeIconDialog, COleConvertDialog, COlePropertiesDialog, COleUpdateDialog, COleChangeSourceDialog, COleBusyDialog
Database Classes
Accessing data and connecting to databases are two of the most common Windows environment programming tasks. MFC provides classes that enable operations on databases through Open Database Connectivity (ODBC) and the data access objects (DAO). To see an illustration that shows the database classes within the MFC object hierarchy, click this icon.
Note This course does not cover creating database applications. For information about how to create database applications using MFC, see Mastering MFC Development Using Visual C++ 5 listed in the Library.
CDatabase and CDaoDatabase A CDatabase or CDaoDatabase object represents a connection to a data source through which you can operate on the data source. A data source is a specific instance of data that is hosted by a database. CRecordset and CDaoRecordset A CRecordset or CDaoRecordset object represents a set of records selected from a data source. Known as recordsets, CRecordset and CDaoRecordset objects are available in two forms: Dyna-sets and snapshots. A Dyna-set is a dynamic recordset that stays synchronized with updates by other users. A snapshot is a static recordset that reflects the state of the database at the time the recordset is requested. CDaoRecordset also can directly represent a table in a database. ï‚®Internet Classes
Creating applications that interact with the Internet, intranets, or both, is becoming a major focus for developers. MFC includes the WinInet APIs and the Internet Server API (ISAPI), which provide classes for client-side and server-side applications, respectively. To see an illustration that shows the Internet classes within the MFC object hierarchy, click this icon.
Note This course does not cover creating Internet applications. For information about creating Internet applications using MFC, see Mastering MFC Development Using Visual C++ 5, listed in the Library.
Client-Side Classes
This table describes MFC Internet classes related to client-side applications.
Class Description
CInternetSession Creates and initializes one or more simultaneous Internet sessions. Specific application-level services can be established by using the member functions GetHttpConnection, GetFtpConnection, and GetGopherConnection. CHttpConnection Manages an application’s connection to an HTTP server. CFtpConnection Manages an application’s FTP connection and provides for member functions that enable you to create applications that explore remote directories, retrieve files, and otherwise manage remote file systems. CGopherConnection Manages an application’s Gopher connection and enables the application to search for and retrieve various types of documents. CFileFind This class, the base class for CFtpFileFind and CGopherFileFind, supports searching, locating, and returning information about found files. All these classes support wildcard searches.
Server-Side Classes
This table describes MFC Internet classes related to server-side applications.
Class Description
CHttpServer Use this class to create and manage a server extension DLL, also known as an Internet server application (ISA). ISAs are used to extend an Internet server’s capabilities. CHttpServerContext Used by CHttpServer to encapsulate the instance of a single client-side request. CHttpFilter Use this class to create a DLL to filter incoming and outgoing client data. CHttpFilterContext Used by CHttpFilter to encapsulate the instance of a single notification for a single client. CHtmlStream Encapsulates an HTML data buffer to be used by a CHttpServer to respond to the client.
Global Afx Functions
MFC provides some functions that are not members of classes. These are global functions whose names begin with Afx. Class member functions can only be called in the context of the class to which they belong, but Afx functions are available to all classes and functions in an application. The following table lists some commonly used Afx functions and describes the tasks they perform.
Function Description
AfxAbort() Unconditionally terminates an application. AfxMessageBox() Displays a Windows message box. AfxGetApp() Returns a pointer to the project’s CWinApp object. AfxGetAppName() Returns a pointer to a string containing the application name. AfxGetMainWnd() Returns a pointer to the main frame window. AfxGetInstanceHandle() Returns a handle (HINSTANCE) to the current instance of the application.
Documents, Views, and the Application Framework
MFC provides an application framework on which you can build applications for Windows. The framework provides a set of starter files for an application and supplies standard user-interface features that you can implement in your application. You provide the rest of the code, specifically those things needed for your application. Your work with the framework is based largely on a few major MFC classes and several Visual C++ tools. Some of the classes encapsulate the Win32 API. Other classes encapsulate application objects such as documents, views, and the application itself. Still, others encapsulate ActiveX, database, and Internet features. This section presents an overview of the application framework, the major objects that make up your application and how they are created, and a brief look at how messages are handled in the MFC environment. This section includes the following topics:
Document/View Architecture
The MFC document/view architecture provides a single, consistent way of coordinating application data, referred to as a document, and views of that data. A document is a data object with which the user interacts in an editing session. A view is a window object through which the user interacts with the document. This topic provides a broad overview of document/view architecture. For detailed information, see Chapter 4: Creating MFC Applications.
Document/view architecture is important because applications that use documents and views derive the greatest benefit from the application framework. You can write MFC applications without using documents and views; however, to get the most out of the framework and take advantage of advanced MFC features, you must use document/view architecture. For more information about non-document/view architecture, see Writing Applications in Non-Document/View in Chapter 4: Creating MFC Applications.
To see an illustration that shows how a single set of data can be viewed or displayed in more than one way by a document/view application, click this icon.
As shown in the previous illustration, Microsoft Graph is a good example of an application that separates the data from the interface. The user can select a set of values from the data in a spreadsheet view, and then display the same information as a bar chart or a three-dimensional bar chart. If the user changes values or changes the range of data that is selected in the spreadsheet view, the chart view is updated. The application can also present two views of the same type; changes made in one view would also appear in the other. To see a demonstration that shows how the Microsoft Excel application uses document/view architecture, click this icon.
SDI and MDI Applications
MFC makes it easy to work with both single document interface (SDI) and multiple document interface (MDI) applications. SDI applications allow only one document frame window at a time. MDI applications allow multiple document frame windows to be open in the same instance of an application. An MDI application has a window within which the user can open multiple MDI child windows that are themselves frame windows, each containing a separate document. In some applications, the child windows can be of different types, such as chart-windows and spreadsheet windows. In that case, the menu bar can change as MDI child windows of different types are activated.
Note Under Windows 95, applications will increasingly be SDI as the operating system moves toward a “document-centered” view. This course teaches you how to create SDI applications using MFC. For information about how to create MDI applications, see Mastering MFC Development Using Visual C++ 5 listed in the Library.
Objects in an SDI Application
Document/view architecture provides the framework for documents and views in the base classes CDocument and CView. The CWinApp, CFrameWnd, and CDocTemplate classes work in conjunction with CDocument and CView to ensure that all the pieces of the application fit together. You will learn more about how to implement these classes in an application in later chapters. The following table lists the application objects and related classes in an SDI application and describes the major tasks each object performs. Object Description
Document Your document class (derived from CDocument) specifies your application’s data.
View Your view class (derived from CView) is the user’s window to the data. The view class specifies how the user sees your document’s data and interacts with it.
Frame window Views are displayed inside document frame windows using the CFrameWnd class. In an SDI application, the document frame window is also the mainframe window for the application.
Document template A document template orchestrates the creation of documents, views, and frame windows. A particular document-template class (derived from CDocTemplate) creates and manages all open documents of one type. Use class CSingleDocTemplate for SDI applications.
Application Your application class (derived from CWinApp) controls all of the objects above and specifies the application’s behavior such as initialization and cleanup.
In an SDI application, each document template creates and manages one document. The user views and manipulates a document through a view contained inside a frame window. The application objects cooperatively respond to user actions, bound together by commands and other messages. The following illustration shows the relationship between the document/view objects in a running SDI application.
Non-Document/View Architecture
Although most of the discussion about Visual C++ and MFC functionality assumes the use of the document/view architecture, this is not a requirement. The benefits associated with document/view architecture also carry with them potentially significant performance and size costs. In some cases, document/view may not be the right choice for your application. For example, applications that compress files may need only a dialog box that requests file names and displays a progress bar. The mainframe window and a view are not needed; document/view architecture would provide little, if any, benefit in this instance. For another example, consider an application that provides a single database recordset to a simple database browser. The document/view architecture could be used, but it may be more effective for the view (the browser) to hold the recordset directly. Remember that an MFC application consists of a number of objects that you can combine in many ways to create a program solution. Some possible combinations in a non-document/view application include:
A CWinApp object and a modal dialog box. In such applications, the dialog box is responsible for storing and displaying data.
A CWinApp object, the mainframe (CFrameWnd) window, and a view. In such applications, the view usually is located where any data is stored and displayed.
Regardless of the combination you choose, the non-document/view application usually begins with the override of the CWinApp:: InitInstance function. At this point, the main window, either a dialog box or other window, is created.
Messages
Communication between the operating system, applications, and application components is conducted through various types of messages. For example, when creating an instance of an application, the operating system sends a series of messages to the application, which then responds appropriately to initialize itself. Keyboard and mouse activity causes the operating system to generate messages and send them to the proper application. User-interface components, such as command buttons and list boxes, generate messages to their parent windows. There are many types of messages; two of the most important are standard Windows messages and command messages. The MFC architecture supports Windows messages through the CWnd class and its derived classes, such as CView and CFrameWnd. MFC supports command messages through any of the classes derived from the CCmdTarget class. A command message originates from a menu item, command button, or accelerator key. In Chapter 6: Handling Messages, you will learn how to handle Windows and command messages in MFC applications.
Message Maps
Before you start writing MFC applications, it is important to understand how MFC maps messages to the functions that will handle the messages. The application framework implements the message map data structure, which provides the link between the message ID and the function that will handle the message. Each entry consists of a message-specific macro. Standard Windows messages all have predefined macros containing an implicit ID and handler name. Command message macros contain an explicit ID and handler name. Below is an example of a message map for the CMyView class with two entries. Note that the base class is included to allow the framework to continue searching for a given handler if one does not exist within this class. Every standard Windows message has a macro of the form ON_WM_xxx, where xxx is the name of the message. A simple convention is used to generate the handler function name. The name of the function starts with “On.” This is followed by the name of the message with the “WM_” removed and only the first letter of each word capitalized. In the following example, the handler name would be OnCreate: BEGIN_MESSAGE_MAP(CMyView, CView) ON_WM_CREATE() ON_COMMAND(ID_APPLY_SEQUENCE, OnApplySequence) END_MESSAGE_MAP()
You can add a message map entry by using ClassWizard or the WizardBar in Developer Studio. Alternatively, you can add the entry manually.
Self-Check Questions
Which one of the following statements is true about MFC’s relationship to the Win32 API? A. The current version of MFC does not wrap any of the Windows operating system extensions. B. MFC represents a high-level encapsulation of the Windows API. C. A program can easily mix MFC- and API-level calls. D. MFC completely encapsulates the Windows API, freeing the developer from all SDK dependency.
Which one of the following is not a potential benefit of MFC? A. MFC reduces complexity by providing a higher-level abstraction of Windows. B. MFC simplifies database programming through the DAO and ODBC classes. C. A developer needs less knowledge and skill to program with MFC than with the Windows SDK. D. MFC displays many of the stronger features of the C++ language, including support for object-oriented techniques, stronger type checking, exception handling, and so on.
Which one of the following is a primary function of the application class? A. It starts the application€™s message loop. B. It forms the primary window for the application. C. It acts as a binder for the frame, view, and document objects and a set of GUI resources in an application. D. It contains member functions to enumerate through all the views in an application.
Which one of the following is not considered to be one of the main classes that comprise the application framework? A. CObject B. CWinApp C. CView D. CFrameWnd
The Microsoft Foundation Class (MFC) Library and Visual C++ provide an environment that you can use to easily create a wide variety of applications. This chapter discusses the various class types and primary architectures that are used in most applications.
Objectives
After completing this chapter, you will be able to:
List the major categories of MFC classes and the primary classes derived from each category.
Describe the relationship of the foundation class CObject to the other MFC classes.
Explain the key features CObject contributes to the classes derived from it.
Define the main base classes used in a typical MFC application.
Describe the document/view architecture and how this architecture applies to MFC.
Describe the benefits and costs of document/view, non-document/view, and dialog-based application architectures.
Describe how MFC maps messages to functions.
Introduction to MFC
The MFC Library is a collection of C++ classes and an application framework designed primarily for creating Microsoft Windows-based applications. This collection of classes extends the C++ language to include most of the basic structural elements used to create Windows programs. The application framework defines the structure of an application and handles many routine tasks for the application.
This section describes the relationship between MFC and Windows technology and explains some key advantages that MFC and Visual C++ offer developers.
This section includes the following topics:
MFC and the Win32 API
The MFC Library is built on top of the Win32 application programming interface (API). This API is a set of functions exposed by the operating system for use by applications. Through MFC, base classes are exposed that represent common objects in the Windows operating system, such as windows and menus.
MFC does not encapsulate or wrap, the entire API, just the main structural components and components that are commonly used. Because MFC is written in C++, MFC developers can easily use the Win32 API to make native calls to the operating system.
To see an illustration that shows the relationship between MFC, the Windows Base Operating Services, and the Windows Operating System Extensions, click this icon.
MFC version 1.0 was little more than a thin wrapper for the Win32 API. However, each subsequent version of MFC provides significantly more features and functionality. MFC incorporates many names and constructions familiar to developers who have used the Microsoft Windows Software Development Kit (SDK). For example, MFC provides a member function named CWnd::InvalidateRect that corresponds to the Win32 function InvalidateRec.
Wrapper Classes for Operating System Extensions
MFC encapsulates important Microsoft Windows operating system extensions, including COM, ActiveX, ODBC, and Windows Internet APIs. The encapsulation is not complete. However, combining MFC and native API usage is usually simple.
Benefits of Using Visual C++
Visual C++ provides a productive visual development environment that gives you the tools you need to create a wide variety of applications, from client/server solutions to high-performance multimedia applications.
Visual C++ supports the latest in Windows operating system-based technology, including the Windows 95 operating system. Visual C++ offers full support for the common controls in the Windows 95 and Windows NT operating systems, as well as support for the Windows 95 Explorer shell. Most of the new Windows 95-based common controls are fully supported by Visual C++, and you can access them through MFC and the Win32 API.
Some other features that make Visual C++ an excellent choice for developing solutions are:
Code reusability.
Application wizards for MFC applications, DLLs, ActiveX controls, Active Template Library (ATL) projects, ATL Component Object Model (COM) objects, and ISAPI extensions.
The integrated development environment of the Developer Studio.
Components and Controls Gallery, a place to store and access reusable components and controls.
Support for the MFC Library.
Portability and cross-platform support.
Availability in Chinese, English, German, French, Italian, Korean, Japanese, and Spanish.
Support for the latest C++ features.
Benefits of Using MFC
The Microsoft Foundation Class (MFC) Library enables you to build on the work of expert Windows developers. MFC shortens development time, makes the code more portable, provides support without reducing programming freedom and flexibility, and provides easy access to hard-to-program user-interface elements and technologies such as ActiveX, OLE, and Internet programming. Furthermore, MFC simplifies database programming through data access objects (DAO) and Open Database Connectivity (ODBC) and simplifies network programming through Windows Sockets. MFC makes it easy to program such features as property sheets (tab dialog boxes), print preview and floating, customizable toolbars.
By using MFC, you can add many features to your applications in an easy, object-oriented way. In MFC version 3.0, you could add ToolTips to your application by adding only three lines of code. With MFC 4.0, a similar amount of code enables ActiveX controls in your application. Now with MFC version 4.2, Visual C++ 5.0, the Gallery, and the wizards, you can add the Active Template Library (ATL) components, Internet classes, and synchronization for multithreaded programs.
MFC offers the experienced C++ developer many advantages when developing full-featured Windows applications, front-end database applications, ActiveX controls and components, and Internet applications, such as:
An application framework on which you can build a Windows application
Compatibility with previous MFC versions and the new C++ classes
The largest base of reusable C++ source code in the industry
Integration with Visual C++
Flexible, fast database access methods using DAO or ODBC
Support for ActiveX and Internet technologies
Support for popular data-binding technologies
Support for Windows messaging API
Support for multithreading
The MFC Class Hierarchy
The first step on the road to becoming an MFC developer is becoming familiar with the classes. This section gives you an overview of the kind of infrastructure MFC provides, including the classes and class hierarchy.
MFC provides nearly 250 classes designed to serve a wide range of programming needs. The first step in programming with MFC is to become familiar with these classes and learn how they are related to one another in the MFC hierarchy. Some classes are used directly, while others serve as base classes for the classes that you create.
When learning about the MFC classes, it is helpful to organize them into the following categories, which are the topics included in this section:
CObject-Derived Classes
Application Architecture Classes
User-Interface Classes
General-Purpose Classes
ActiveX Classes
Database Classes
Internet Classes
Global Afx Functions
These categories of MFC classes are not mutually exclusive. The majority of MFC classes are derived, either directly or indirectly, from CObject.
CObject-Derived Classes
CObject is the base class for most of MFC and provides the foundation for serialization (loading and saving data to a file), run-time class information, diagnostic and debugging support (validations and dumps), and compatibility with collection classes.
CObject Hierarchy
To see an illustration that shows the relationship of CObject to the other classes in the MFC class hierarchy, click this icon.
The classes in MFC that are derived from CObject provide most of the structure and functionality of an MFC application. The following table lists some of the most important classes and describes the tasks they perform.
Category
Base class
Description
Command targets CCmdTarget For classes that are capable of handling the user’s requests.
Applications CWinApp Represents the core of the application.
Documents CDocument Contains an application’s data set.
Windows CWnd For graphical user interface (GUI) objects that are capable of handling general Windows messages.
Frames CFrameWnd For an application’s primary window frame.
Views CView Displays data and interacts with the document object.
In addition, there are many CObject-derived classes for other aspects of a Win32-based application, such as menus, graphics, file services, and so on.
Support for CObject-Derived Classes
CObject provides three basic types of support to classes that inherit from it, as shown in this table.
Type of support Description
Serialization In this context, serialization is the process of writing or reading an object to or from a persistent storage medium, such as a disk file.
Run-time class information Because it is derived from CRuntimeClass, objects derived from CObject contain information about their origins that are accessible at runtime. This run-time type-checking feature gives functions the ability to react based on the type of object that is acted on.
Diagnostic output To aid in the development of an MFC application, CObject provides a number of diagnostic or debug output functions. Overriding these functions provides information about the execution of your program that is especially useful when program behavior is not as expected.
Classes Not Derived from CObject
MFC also contains a set of classes that are not derived from CObject. These classes are useful in situations where the overhead associated with CObject and run-time type identification are unnecessary. These classes fall into three general categories, as shown in the following table.
Category Examples
General utility classes for general programming CString, CTime, CTimeSpan, CRect, CPoint, CSize
MFC support classes to assist the architecture CArchive, CDumpContext, CRuntimeClass, CFileStatus, CMemoryState
Templatized versions of the collection classes that take a user-defined pointer CTypedPointerArray
Application Architecture Classes
The application architecture classes represent the basic architectural elements of an application and include CWinApp, which represents the application itself. To see an illustration that shows the architecture classes in the MFC object hierarchy, click this icon.
Some of the architectural classes include CWinApp, CDocument, CCmdTarget, and CWinThread. These classes are the first to be instantiated when the application starts, and they have significant responsibility.
The following table describes these four classes in more detail.
Class name Description
CWinApp This class represents the application itself. All MFC applications derive a class from CWinApp.Depending on the type of framework chosen, the application object is responsible for:
Initializing the application.
Building the document template structures. Providing the message loop with retrieved messages from the message queue and dispatching these messages to the appropriate location. Cleaning up the application on exit.
CDocument This is the base class for documents in applications that use document/view architecture. A document is simply an abstract representation of a program’s data. A major architectural task for the developer is to determine how data is to be stored in the document, and how and to what extent the document will provide access to that data.
CCmdTarget This is the foundation class for message map architecture in MFC. The capabilities that a class inherits from CCmdTarget enable it to serve as a target for a special class of messages, known as command messages. These messages are generated when the user chooses a command from a menu.
CWinThread This class encapsulates the threading capabilities of the operating system. Member functions enable MFC applications to create and manipulate threads.
User-Interface Classes
Typically, the user-interface classes encompass the elements of a Windows-based application that are visible to the user. These include windows, dialog boxes, menus, and controls. The user-interface classes also encapsulate the Windows device context and graphics device interface (GDI) drawing objects.
To see an illustration that shows the user-interface classes within the MFC object hierarchy, click this icon.
Some of the user-interface classes include CWnd, CView, CGdiObject, and CMenu.
CWnd
CWnd is the base class for all MFC windows and defines the basic functionality of a window and a window’s default response to most messages. CWnd is sometimes used directly to derive classes, but more often, classes are derived from the other built-in classes that are derived from CWnd. The following table shows some of the classes that are derived from CWnd.
Class and Description
CFrameWnd Models the behavior of a single document interface (SDI) frame window.
CControlBar Serves as the base class for toolbars, status bars, and other controls.
CDialog Encapsulates the functionality of dialog boxes.
CButton, CListBox, CScrollBar, and so forth Corresponds to controls such as buttons, list boxes, and scroll bars.
CView
Most applications provide the user with one or more views of the underlying data. For example, Microsoft Excel provides a worksheet view and a graphic view of the same data. The CView class, derived from CWnd, is the base class that provides visible representation in a document/view application.
CGdiObject
The graphics device interface (GDI) portion of Windows is designed to provide applications with a device-independent and feature-rich set of drawing capabilities. The GDI contains a number of “objects” that are used to display output, such as brushes, pens, and fonts. CGdiObject is a wrapper class that provides MFC applications with the ability to create and use these objects.
CMenu
Menus are one of the main methods by which users interact with applications. An application’s menu items not only give the user the ability to invoke an action, but they also provide information to the user about the state of the application and what options are currently available.
The CMenu class provides an object-oriented interface to menus. Through the CMenu class interface, the application can dynamically control its menus at run time.
® General-Purpose Classes
MFC includes a number of general-purpose classes that do not encapsulate the Win32 API. These classes represent simple data types such as points and rectangles and more complex data types such as strings.
To see an illustration that shows the general-purpose classes within the MFC CObject hierarchy, click this icon.
The following table lists some commonly used general-purposes classes and describes the tasks they perform.
Class and Task
CFile File I/O
CString Managing string variables
CException Exception handling
CByteArray, CIntArray, CStringArray, CStringList, CObList Working with data structures such as arrays and linked lists
We are detailing about Anatomy of a Windows-Based Application, Elements of a Windows-Based Application, Resource type Description, how a Window Processes Message, and show you the illustration of Anatomy of a windows-based application.
Anatomy of a Windows-Based Application
Knowing the elements that make up a Windows-based application and how windows communicate information between the application and the user is important to writing effective MFC applications.
In this section, you will learn about the essential components of a Windows-based application and get a brief introduction to how messages are processed in the Windows environment.
This section includes the following topics:
Elements of a Windows-Based Application
The basic elements that make up a Windows-based application include code, user interface resources, and library modules invoked by the application through dynamic linking.
The primary content of any application is executable code. Windows-based applications have two required functions. One, called WinMain, provides an entry point for the operating system. The second function, a window procedure, is needed to handle messages from the operating system.
User Interface Resources
Many application-defined elements of an application’s graphical user interface (GUI), such as menus and dialog boxes, are stored as templates and references in a special read-only section of the corresponding executable or DLL file. When required, Windows reads from this resource section and constructs the GUI element dynamically.
Note that while resources are primarily used to store information about the GUI elements of an application, any read-only information could be placed in the resource section. The advantage is that resources are shipped as part of the executable file, minimizing the need for additional files to be shipped with an application.
The following table lists the common Win32 resources.
Resource typeDescription
Accelerator Stores the keystrokes and their command associations. Bitmap Contains a graphical image in Windows-compatible format.
Dialog box Details the controls, layouts, and attributes for dialog boxes.
Icon Stores special sets of bitmaps for icons.
Menu Details the text and layout for menus and their items.
String table Stores character strings and an associated ID value.
Toolbar Details toolbar layouts and contains references to the special bitmaps that are used to draw the button faces.
Version information Maintains program status information, such as program name, author, copyright data, version number, and so on.
Cursor Contains the special bitmap that is used to draw the cursor.
Library Modules
Microsoft Windows, along with most modern operating systems, supports dynamic linking, a method for invoking library modules at run time. A library module is a binary file that contains the executable library routines. A library module that can be loaded in this manner is called a dynamic-link library, or DLL.
How an Application Is Started?
For a Windows-based application to get up and running, several events must occur first. When a user starts an application, the following events occur in sequence:
The operating system creates a new process and an initial thread.
The application code is loaded into memory.
Dynamic-link libraries also are loaded into memory, if your application uses them.
Space for items, such as data and stacks, is allocated from physical memory and mapped into the virtual address space.
The application begins execution.
How a Window Processes Message?
Most Windows users are familiar with the term window and the visual elements that characterize applications. From a developer’s standpoint, windows take on a new meaning. In a Windows-based application, windows are the primary method of communicating information from the application to the user. Similarly, the user uses the window to communicate with the application, thus achieving the desired behavior to accomplish a task.
The following steps explain how a Windows-based application prepares itself to receive messages that are sent to it by the system queue.
When a Windows-based application is started, the operating system connects with the application at a predefined entry point. This entry point is defined in the WinMain function, a required function in all Windows-based applications.
The application then creates one or more windows. Each window contains a window procedure that is responsible for determining what the window displays and how the window responds to user input.
A section of code called a message loop retrieves messages from the message queue and gives them back to Windows to send to the appropriate window procedure. This gives the application a chance to preprocess messages before they are sent to a window.
The code to implement each of the steps in this process is presented in a sample application and described in detail in Analyzing a Simple Windows-Based Application later in this chapter.
The following illustration shows how messages passed from the system queue are processed by the application.
