PaintPictureBoxDemo

1. PaintPictureBoxDemo Refers to the PaintPictureBoxDemo Visual Basic Program Included With The Lecture

2. Topics Demonstrated • Inheritance from Existing Classes • Events and Event Handling • Adding Controls at Runtime • Overloaded Constructors • Encapsulation

3. The PaintPictureBoxDemo Program • The program consists of: • A custom class, PaintPictureBox, which inherits from the built-in .NET Framework class PictureBox. • A form, frmPPBDemo, which adds an instance of PaintPictureBox at runtime, and has controls to add simple shapes to the PaintPictureBox and change the colors.

4. PaintPictureBox code • Here is the collapsed view of the PaintPictureBox class’s code: • The four sections by the plus signs are “regions”. • The VB editor allows you to organize your code into regions using the #Region syntax. • Regions can be expanded to show all their code by clicking on the plus sign, or collapsed back to a single line by clicking the minus sign. • Like comments, regions do not affect how your code runs; they just help you to organize it, and to hide sections of code you are done working on.

5. Inherits • As you will recall, inheritance is one of the four key elements of OOP (along with abstraction, encapsulation, and polymorphism). • Inheriting from the built-in .NET classes, especially controls, is one of the most useful ways to use inheritance in your programs. • By inheriting from PictureBox, the custom PaintPictureBox has all of the properties, procedures, and other elements of the PictureBox control.

6. Inherits • In fact, if all I did was inherit from PictureBox, • I would have a class EXACTLY like PictureBox, just with a different name. • Not much point in that, however. • We inherit from an existing class so that we can take advantage of its built-in elements, and then add to them. • And that’s what the rest of the PaintPictureBox code is: adding new elements to PictureBox to increase its functionality.

7. Properties and Variables • Most of the code in this region should be familiar. • The variable “Private mLastMouseLocation As Point” is used with the MouseMove event to draw a line from the last place the mouse was to where it is now (see Sub pbGraphics_MouseMove)

8. Events and Handlers • The MouseDown event provides more detailed information than does the Click event. • With Click, a control just says “The user clicked the mouse on me somewhere” • With MouseDown, the control identifies which button was clicked (e.Button) and where (e.Location) • In this class, I want a left-click to start a line drawing operation, and a right-click to change the values in the Left and Top numeric updowns (where the next shape will be drawn).

9. Declaring an Event • This simple declaration adds an event to the PaintPictureBox class. • The event can be raised by other code in the class; in this case, it will be raised in the MouseDown procedure. • It includes a parameter, Loc, that will be passed to any routine written to handle this event (in a class/form that uses objects of the PaintPictureBox class; in this case, frmPPBDemo).

10. Raising the Event • This means that whenever this last line of code runs, a flag goes up telling any object using this object (PaintPictureBox) that the right button has been clicked in a certain spot. • The calling code can then “handle” the event if it chooses to.

11. Handling the Event • Here’s how the form in this project handles this event: • We create a Sub (ChangeStartLocation) that takes the same parameter(s) as the event. • We use AddHandler to have that Sub handle the desired event.

12. Other Uses for Events • StartLocationChanged is a somewhat artificial event; I could have accomplished the same thing by handling pbGraphics’ MouseDown event directly in the form code. • However, adding events is a very OOP way to add intelligence to your classes. • Consider some sort of vehicle class (car, truck, airplane) where the range of the vehicle is limited by the size of the fuel tank. • Suppose you have lots of vehicle objects in your program whose fuel tanks are in varying states of emptiness. • Your calling code could loop through all of the vehicles each time the timer ticks to see if they are out of gas; or • There could be an OutOfFuel event in the Vehicle class which is raised whenever the vehicle’s fuel amount reaches zero. • This second choice is the preferred OOP way.

13. Vehicle Example • Obviously, this isn’t a very useful class. • It needs additional properties and procedures to be useful. • Actual fuel consumption wouldn’t always be 1; it would depend on speed, mpg, and other factors. • But as a start, you can see that every time the calling code tells the vehicle object to drive, the fuel remaining will be reduced, and when it runs out of fuel, the vehicle will raise the OutOfFuel event for the calling code to handle (if it wants to).

14. Overloaded Constructors • The PaintPictureBox class has two constructors: • A detailed one allowing the calling code to specify four parameters, and • A simpler one which only takes two parameters. • Note that the simpler one simply calls the detailed one, using pre-selected colors. • This is a very common approach to overloading constructors.

15. Adding Controls at Runtime • The PaintPictureBox control is not added at design time; • In fact, it doesn’t even exist in the Toolbox! • So how do we get our custom control, inherited from PictureBox, onto the form?

16. Adding Controls at Runtime • Here’s how: • Declare a class-level variable. This is how we will reference the object once it is created. • Create the object using the constructor. • Add the new object to the form’s Controls collection. • Add any required/desired event handlers. • Here’s the code: • A form’s Controls collection contains all controls on the form. (duh) • To put a control on a form in code, you must add it to the Controls collection.(not so duh)

17. Custom Controls in the Toolbox? • It is possible to create your own controls, either inherited from existing controls or created from scratch, and use them at design time. • That is, they can appear in the toolbox, be placed on the form, and have their properties edited in the properties window. • If you will use the control frequently, this is a good idea. • However, it is much more work than was involved in creating the PaintPictureBox class. • We will not cover this topic this semester. Chapter 22 in the Stevens book describes how it is done. • For a custom control that will only be used in a single program, the procedure outlined in this lecture is the simplest and best way to go.

18. Adding Ordinary Controls at Runtime • Regular controls can be added at runtime as well. • However, they only have default constructors, so any non-default properties you want to set will require extra lines of code. • Example: • This can be especially useful when you want to let the user determine the number of controls to add, or when doing animation using controls (next topic!).

19. PaintPictureBox: Summary • The PaintPictureBoxDemo program demonstrates two of the four key elements of OOP: • Inheritance: The PaintPictureBoxclass inherits from the PictureBox class, which means that it starts life as a fully-functional control capable of displaying pictures and creating graphics. Additional features are then added. • Encapsulation: This is a fairly powerful drawing program. But note that the code in the form consists of just six very short subroutines. Most of the code which makes this program work is encapsulated in the PaintPictureBox class (including, of course, the unseen code inherited from the PictureBox class).