Supervisor:Dmitry Davidov

Students:

Roman Kagan 313772121

Tanya Kostanovich308946144

Table of contents:

1. Project purpose:4

2. Technologies that we have used in our project: 5

2.1 COM Technology:5

2.2 ATL Technology:6

2.3 ActiveX Controls:8

3. Programming Languages we developed our project in:11

3.1 Visual Basic:11

3.2 Win32, MFC:13

4. User Manual15

4.1 System requirements15
4.2 How to install PicOrganizer application:15
4.2 Functionality description:17
4.2.1 Main Menu and Main toolbar:17
4.2.1.1 File17

4.2.1.2 Edit17

4.2.1.3 View18

4.2.1.4 Tools18

4.2.1.5 Help18

4.2.2 Upper Window19

4.2.3 Left Window20

4.2.4 Right Window22

4.3 Working with project:26

4.3.1How to add new picture to category?26

4.3.2 What can you do with picture?26

4.3.3 How to add new text to category?28

4.3.4 What can you do with text?28

5. Application Description29

5.1 Overview29

5.2 Compilation instructions29

5.3 Package diagram30

5.4 Classes diagrams31

5.4.1 Main GUI class diagram31

5.4.2 Right window class diagram33

5.4.3 Logic class diagram35

5.4.4 Data Base class diagram36

6. Bibliography37

List of diagrams:Package diagram30

Main GUI class diagram32

Right window class diagram34

Logic class diagram35Data Base class diagram36

1.Project purpose:

To develop user application that can help in creating web pages with large quantity of pictures.

This application should have a user friendly GUI and support following functionalities:

  1. Organization of pictures by categories (folders), types and descriptions.
  2. Addition of pictures and text to the page.
  3. Arrangement of pictures on page (templates or freely).
  4. Change of picture’s size and/or form.
  5. Execution of search operation in project.
  6. Generation of HTML pages.
  7. Preview of HTML pages in Internet Explorer.

2.Technologies that we have used in our project:

2.1.COM Technology:

The Component Object Model (COM) is a way for software components to communicate with each other. It's a binary and network standard that allows any two components to communicate regardless of what machine they're running on (as long as the machines are connected), what operating systems the machines are running (as long as it supports COM), and what language the components are written in. COM further provides location transparency: it doesn't matter to you when you write your components whether the other components are in-process DLLs, local EXEs, or components located on some other machine.
To understand COM (and therefore all COM-based technologies), it is crucial to understand that it is not an object-oriented language but a standard. Nor does COM specify how an application should be structured; language, structure, and implementation details are left to the application programmer. Rather, COM specifies an object model and programming requirements that enable COM objects (also called COM components, or sometimes simply objects) to interact with other objects. These objects can be within a single process, in other processes, and can even be on remote machines. They can have been written in other languages, and they may be structurally quite dissimilar, which is why COM is referred to as a binary standard—a standard that applies after a program has been translated to binary machine code.
The only language requirement for COM is that code is generated in a language that can create structures of pointers and, either explicitly or implicitly, call functions through pointers. Object-oriented languages such as Microsoft® Visual C++® and Smalltalk provide programming mechanisms that simplify the implementation of COM objects, but languages such as C, Pascal, Ada, Java, and even BASIC programming environments can create and use COM objects.
COM defines the essential nature of a COM object. In general, a software object is made up of a set of data and the functions that manipulate the data. A COM object is one in which access to an object's data is achieved exclusively through one or more sets of related functions. These function sets are called interfaces, and the functions of an interface are called methods. Further, COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface.
Besides specifying the basic binary object standard, COM defines certain basic interfaces that provide functions common to all COM-based technologies, and it provides a small number of API functions that all components require. COM also defines how objects work together over a distributed environment and has added security features to ensure system and component integrity.

2.2.ATL Technology:

ATL was originally designed as a way to write fast, small COM components. It was especially intended for Automation components that could, for instance, implement business rules and database access in a multitier architecture.
In its first version, ATL did not have any facilities for any sort of user interface—ATL 1.0 controls could not be visual ActiveX controls, for instance (not without almost as much work as implementing it in C++ without ATL, that is). Version 2.0 added the templates necessary to build visual ActiveX controls.

ATL gives you several important features, including:

  • All of the power of C++.
  • No run-time library, unless you want to use it.
  • A relatively high-level way of abstracting objects and interfaces.
  • Automatic handling of class factory, object creation, reference counting, and QueryInterface.
  • Stock implementations of standard interfaces.

This last point is probably the most important: One of the hardest things about writing an ActiveX control in unaided C++ is that you have to write an implementation for every method of every interface you implement—and for a visual ActiveX control, that's more than a dozen interfaces! None of these methods have anything to do with the problem you're trying to solve, but you have to write these nontrivial methods correctly anyway.
That's why MFC, Visual Basic, Visual J++, Visual FoxPro, and Delphi are so popular for writing ActiveX controls: their run times implement all the methods of the dozen or so interfaces for you, allowing you to concentrate on the problem at hand.
But using these techniques to implement your ActiveX controls is a Faustian bargain: the run times for all of these products are, to one degree or another, big and slow. If you need your controls to be small and fast, you'll either implement them in C++ directly or you'll use ATL.
ATL give you the leanest, meanest code around, because:

  • First off, it relies on no run-time libraries at all—so the only time your control needs to use a run-time library is if your code makes use of it.
  • Second, through the magic of templates, ATL controls contain only the code they actually need.

So ATL controls are very comparable in size and speed to controls hand-coded by COM experts in C++. But they're far easier to write.

The big advantages of using MFC are that you get to reuse code that you didn't write or debug—someone else's code. So MFC gives you print preview virtually for free—that's several thousand lines of code you don't have to write. And it makes it easy to write OLE in-place editing servers. That's many thousands of lines you don't have to write.

That code is especially valuable when it's been tested and debugged. Now, no library is perfect. But the code in a mature library has been used and debugged by many, many programmers—and, as good as you are, the libraries are likely to be faster and more robust than you have time to write yourself. They basically encapsulate all of the developer's expert knowledge and allow you to stand on their shoulders by reusing it.

Template libraries represent a different type of reuse than function libraries or class libraries. First, reusing templates means reusing source code directly. That means that you can turn the optimizer loose on your programs and make it more efficient. It also means that, should a bug be discovered in a template library, you can fix the bug by modifying the template source. You don't have to rebuild MFC or the CRT and distribute new copies. Just build the next version of your projects with the new templates and the bug will be no more.

2.3.ActiveX Controls:

An ActiveX control is essentially a simple OLE object that supports the IUnknowninterface. It usually supports many more interfaces in order to offer functionality, but all additional interfaces can be viewed as optional and, as such, a container should not rely on any additional interfaces being supported. By not specifying additional interfaces that a control must support, a control can efficiently target a particular area of functionality without having to support particular interfaces to qualify as a control. As always with OLE, whether in a control or a container, it should never be assumed that an interface is available, and standard return-checking conventions should always be followed. It is important for a control or container to degrade gracefully and offer alternative functionality if a required interface is not available.
It is important for controls that require optional features, or features specific to a certain container, to be clearly packaged and marketed with those requirements. Similarly, containers that offer certain features or component categories must be marketed and packaged as offering those levels of support when hosting ActiveX Controls. It is recommended that controls target and test with as many containers as possible, and degrade gracefully to offer less or alternative functionality if interfaces or methods are not available. In a situation where a control cannot perform its designated job function without the support of a component category, that category should be entered as a requirement in the registry to prevent the control being inserted in an inappropriate container.
These guidelines define those interfaces and methods that a control can expect a container to support, although as always a control should check the return values when using QueryInterface or other methods to obtain pointers to these interfaces. A container should not expect a control to support anything more than the IUnknown interface. These guidelines identify what interfaces a control can support and what the presence of a particular interface means.

ActiveX Controls have become the primary architecture for developing programmable software components for use in a variety of different containers, ranging from software development tools to end-user productivity tools. For a control to operate well in a variety of containers, the control must be able to assume some minimum level of functionality that it can rely on in all containers.

By following these guidelines, control developers make their controls more reliable and interoperable, and, ultimately, better and more usable components for building component-based solutions.

It is expected that new interfaces and component categories will develop over time; future versions of this document reflecting these changes will be made readily available through Microsoft. It is important to note that this document does not cover detailed semantics of the OLE interfaces; this is covered by the Microsoft Platform Software Development Kit (SDK) documentation.

ActiveX Controls Architecture

As noted above, ActiveX controls technology builds on a foundation of many lower-level objects and interfaces in OLE. The exact interfaces available on a control vary with its capabilities. This section takes a closer look at the capabilities a control might provide.

Controls are used to provide the building blocks for creating user interfaces in applications. For example, a button that initiates some action in the container application when it is clicked is a simple control. The following aspects are involved in providing these user interface building blocks:

  • A control can be embedded within its container client to support some user interface activity within the client. Thus, a control needs to provide a visual representation of itself when it is embedded within the container and needs to provide a way to save its state, for example, its property values and its position within its container. The client must support being a container with objects embedded in it.
  • By activating the control using a keyboard or mouse, the end user initiates some action in the client application. Thus, a control must respond to keyboard activity and must be able to communicate with its client so it can notify its container of its activities and trigger events in the client.
  • The client also typically provides a programming language through which the end user can initiate actions provided by the control’s properties and methods. Thus, a control must support automation and some set of design-time versus run-time features as well.

As a result of its role in providing user interface building blocks, a control typically supports features in the following areas using OLE technologies as indicated:

Properties and methods

Like any OLE object, a control can provide much of its functionality through a set of incoming interfaces with properties and methods. The container can supply additional ambient properties, and it can support extending the control’s properties through aggregation. These features rest on OLE automation, property pages, connectable objects, and ActiveX control technologies.

Events

In addition to providing properties and methods, an ActiveX control can also provide outgoing interfaces to notify its client of events. The client must support handling of these events. These features use OLE automation and connectable objects.

Visual representation

A control can support positioning and displaying itself within its container. The container positions the control and determines its size. These features use compound document technology, including OLE drag and drop technology.

Keyboard handling

A control can respond to keyboard accelerators so the end-user can initiate actions performed by the control. The container manages keyboard activity for all its embedded controls. These features use control and compound document technologies.

Persistence

A control can save its state. The client manages the persistence of its embedded controls. These features use structured storage and object persistence technologies.

Registration and licensing

A control typically supports self-registration and creates a set of registry entries when it is instantiated. A control can also be licensed to prevent unauthorized use.

Most of these features involve both the control and its client container.

  1. Programming Languages we developed our project in:
  2. Visual Basic:
    So what is Visual Basic? The "Visual" part refers to the method used to create the graphical user interface (GUI). Rather than writing numerous lines of code to describe the appearance and location of interface elements, you simply add prebuilt objects into place on screen. If you've ever used a drawing program such as Paint, you already have most of the skills necessary to create an effective user interface.

The "Basic" part refers to the BASIC (Beginners All-Purpose Symbolic Instruction Code) language, a language used by more programmers than any other language in the history of computing. Visual Basic has evolved from the original BASIC language and now contains several hundred statements, functions, and keywords, many of which relate directly to the Windows GUI. Beginners can create useful applications by learning just a few of the keywords, yet the power of the language allows professionals to accomplish anything that can be accomplished using any other Windows programming language.

The Visual Basic programming language is not unique to Visual Basic. The Visual Basic programming system, Applications Edition included in Microsoft Excel, Microsoft Access, and many other Windows applications uses the same language. The Visual Basic Scripting Edition (VBScript) is a widely used scripting language and a subset of the Visual Basic language. The investment you make in learning Visual Basic will carry over to these other areas.

Whether your goal is to create a small utility for yourself or your work group, a large enterprise-wide system, or even distributed applications spanning the globe via the Internet, Visual Basic has the tools you need.

a)Data access features allow you to create databases, front-end applications, and scalable server-side components for most popular database formats, including Microsoft SQL Server and other enterprise-level databases.

b)ActiveX™ technologies allow you to use the functionality provided by other applications, such as Microsoft Word word processor, Microsoft Excel spreadsheet, and other Windows applications. You can even automate applications and objects created using the Professional or Enterprise editions of Visual Basic.

c)Internet capabilities make it easy to provide access to documents and applications across the Internet or intranet from within your application, or to create Internet server applications.

d)Your finished application is a true .exe file that uses a Visual Basic Virtual Machine that you can freely distribute.

3.2.Win32,MFC:

The Microsoft Foundation Classes were written for one single purpose: to make Windows programming easier by providing classes with methods and data that handle tasks common to all Windows programs. The classes that are in MFC are designed to be useful to a Windows programmer specifically. The methods within each class perform tasks that Windows programmers often need to perform. Many of the classes have a close correspondence to structures and windowclasses, in the old Windows sense of the word class. Many of the methods correspond closely to API (Application Programming Interface) functions already familiar to Windows programmers, who often refer to them as the Windows SDK or as SDK functions.