SUPPORT THE IDISPOSABLE INTERFACE (continued)

Our objects can now dispose of their contents properly. Be aware that it may not always be a good idea to dispose of contained objects as we do for the PhotoAlbum class here. There are times when an object in a list may be in use elsewhere in the program, and it is best to let the caller or the garbage collector decide when and how to dispose of any contents. For example, if a single Photograph object could be stored in two PhotoAlbum objects at the same time, then our PhotoAlbum.Dispose method would not be appropriate. We will enforce the rule that a single Photograph can only be a member of a single album, so the implementation presented here will work just fine.

We have one more change to make before going on to chapter 6.

5.4.4ASSOCIATING A FILE NAME WITH AN ALBUM

One final addition that hasn’t fit anywhere else in this chapter is the ability to assign a file name to an album. This will come in handy when we save and open albums in chapter 6. We will do this by providing a FileName property in the class, as detailed by the following table.

ADD A FILE NAME PROPERTY FOR AN ALBUM

ADD A FILE NAME PROPERTY FOR AN ALBUM (continued)

Note that we permit a nonexistent file name to be assigned in this property. This allows an album name to be assigned before any data is actually saved into the file.

This completes the implementation of the PhotoAlbum and Photograph classes, at least for now. As usual, we finish this chapter with a quick summary of our accomplishments.

5.5RECAP

In this chapter we created an external library that applications everywhere can use when a photo album is required. We implemented a Photograph class to encapsulate a photographic image, and a PhotoAlbum class to encapsulate a collection of Photograph objects. Along the way we examined interfaces, .NET collection classes, custom bitmap creation, internals of the Object class, and the IDisposable interface.

The MyPhotoAlbum.dll library is ready for use in our MyPhotos application. Integrating this library into our application is the topic of our next chapter. This will allow us to support multiple images in our application, and set the stage for future changes to come.

More .NET For questions on C#, Windows Forms, and other aspects of .NET, Microsoft provides a number of Internet newsgroups on a variety of topics. These are available at Microsoft’s News Server at news.microsoft.com. Among the newsgroups provided are microsoft.public.dotnet.framework.windowsforms for questions about Windows Forms application development, and microsoft.public.dotnet.languages.csharp for questions about the C# programming language.

Common file dialogs

In the previous chapter we created the Photograph and PhotoAlbum classes as a way to encapsulate a photographic image and a collection of photographs. In this chapter we make use of these classes in our application to display a photo album to the user. We will stick with our model of one photo at a time, but allow a user to move forward and backward within the album. This will permit us to focus on integrating the library without too many changes to the user interface.

In future chapters, we will expand our class library with additional functionality such as storing the date a photograph was taken, or the name of a photographer. Adding such features to a photo album will take some work by the user, which we would not want to throw away when the program exits. As a result, before any of these additional features really make sense, we need to store our photo album on the disk so it can be used again (and again and again).

How will we store our album on disk? In a file, of course, to match the chapter title. Specifically, this chapter will show how to perform the following tasks:

•Use the PhotoAlbum and Photograph classes to display, navigate, and manage a set of photographs in the MyPhotos application.

•Allow multiple images to be loaded at once using the OpenFileDialog class.

161

•Save the current album using the SaveFileDialog class.

•Open a previously saved album using the OpenFileDialog class.

Figure 6.1 shows how our application will look by the end of this chapter, with the new File menu displayed. Note that we have also added an Edit menu and a new status bar panel showing the current position within the album. In the figure, the third of a total of four photographs in the album is shown.

Figure 6.1

In this chapter we implement a more traditional File menu structure for our application.

6.1DESIGN ISSUES

The changes planned for this chapter require that we rewrite our menu bar. Before we plunge ahead, let’s do some brief design work to lay out this new main menu. It is always a good idea to sketch your graphical elements up front. You can even do this on paper. The point is to have in mind the graphical interface you wish to implement before you start writing code. While it is always possible to move menus and other objects around, it can also waste a lot of time. This is especially true if the application has to be approved by a manager, the customer, or anyone else. Doing a quick sketch on paper creates a basis for discussion and allows initial thoughts and ideas to be aired before a more formal design document or any code is written.

6.1.1CHANGING THE MENU BAR

While we are not doing a formal design here, let’s at least write down the new menu structure we will implement. As shown in the following table, in addition to the File menu changes, we will also add an Edit menu to our application.