Problem # 2 - The Picture Box
The Picture Box as Container
You may be wondering why this form has a timer on the picture box. Then again, why would it need a picture box at all? The picture box has everything to do with the scheduling wizard we’ll be creating in a later chapter from this particular form. We need to see what the problem is and how to fix it before we get into the more complicated construction of a wizard.
To briefly explain, in a professional Windows application, a wizard is created using a single form, with the individual buttons (such as ‘Back’ and ‘Next’) having multiple uses. Off to the left of the screen is a stack of picture boxes, normally at
picBox.Left = -10000. Each picture box contains a collection of controls for a single step of the wizard. When the wizard is started, only the picture box for the first step is on the form, while the rest are in the stack to the far left of the screen. When the ‘Next’ button is clicked, the picture box for the first step is swapped with the one for the second step. If the ‘Back’ button is pressed, the opposite occurs. The process with the ‘Next’ button continues until the ‘Finish’ button is clicked to close the wizard.Unfortunately, the problem with the MSVBCalendar control only occurs when it has a picture box for a container! Remember, it worked just fine with its test program. Let’s take a look at the problem in greater detail.
Go back into Chapter6.vbp and go to the properties for Timer1. You’ll find that the Interval property is set to 1, which is in milliseconds. Change this value to 1000, or 1 second, and press F5. For 1 second, the form will look similar to this:
Then it gets refreshed and looks as it should:
Make sure you set the timer’s interval back to 1 before continuing.
When I first started looking at this problem, I noticed something interesting. If I clicked within the current month when the calendar was in its incomplete state, all I got were more individual dates. But if I clicked on the previous or next months, the calendar recovered fully when it was repainted with the selected month.
I’ve added the timer to the form since simply refreshing the calendar upon Load or Activate didn’t work. The timer is set for 1 millisecond, but its Enabled property is set to False at design-time. When the form is shown, the Activate event enables the timer:
Private Sub Form_Activate() ' Set the timer for its one-time firing Timer1.Enabled = True End Sub
After the 1 millisecond time period has elapsed, the timer refreshes the calendar, then promptly disables itself:
Private Sub Timer1_Timer() ' Refresh the calendar so it appears correctly Calendar1.Refresh ' We're done, so disable the timer Timer1.Enabled = False End Sub
This workaround becomes important in a later chapter for the development of our scheduling wizard. However, if you’re using the MSVBCalendar on a form without using a picture box as a container, there’s no need to implement this solution.
MSVBCalendar GUI Notes
Something to consider: We have the source code for this calendar control, so it should be quite a simple task to make changes as we see fit. We know how calendars work, as we’ve been using them most of our lives. Is there anything you would like to change about this calendar?
My first thought goes to the iteration buttons at the top of the calendar control itself. At first glance, it’s a bit difficult to understand their exact purpose. As you may have noticed, the left one moves the calendar to the previous month, while the right one moves the calendar to the next month. However, the right iteration button is to the right of the Year text box. How many others think like I do and, at first, believed that this button on the right would affect the Year? A change to this aspect of the calendar might look something like this:
In designing user interfaces, it’s important to place items correctly, in the locations the user will expect them to appear. Doing otherwise will cause unwarranted confusion. The user shouldn’t require a Help file to use something as simple as a common calendar.
At this point, we’re going to work on the menu structure of our form, looking at the resulting common dialogs differently then we ever have before.
Dialog Automation Objects
The Windows Common Dialogs, which are provided to us complements of commdlg32.dll, are quite important in the development of a GUI. All five of the common dialogs, Open (and Save), Color, Font, Print, and Help, are necessities which are well known to all computer users, regardless of their operating-system-of-choice. Each one of these dialogs fulfills a specific need for the user, and we, as developers, need to be aware of exactly what the user is looking to do when he or she opens one of these dialogs in our applications.
One of the methods for implementing these dialogs in our applications is through the CommonDialog control. However, this control has always been a bit confusing to me. I’ve never quite found an easy way to keep track of all of the coding and flags necessary to implement a specific usage. Also, since we end up using the same control for various uses on different forms, the confusion can quickly snowball.
Microsoft has found a better way to implement the common dialogs from Visual Basic … without the CommonDialog control! All that’s required is a single project reference to a rather small DLL, using syntax which is easy to understand. By taking the control off the form, and making the implementation of the common dialogs global to the project, a lot of the confusion subsequently disappears. The syntax has also been cleaned up a bit, without all of the cryptic flag settings.
The CommonDialog falls right out of the concept of code reuse with a loud thunk. Let’s think about this for a moment. The CommonDialog control can be considered to be a template of sorts, and in using it we access the same template a number of times throughout a given application. But when else would we consciously place a control on multiple forms and give it the same purpose in life each and every time, even duplicating the same code? A couple of aspects of the individual implementations may be different, but the redundancy can get old rather fast. Also, you're not always using all of the possible aspects of the control anywhere close to 100% of the time. So we end up with unused portions of the control, or "dead code", all through our applications.
In using a global definition for the common dialogs, it’s kind of like placing the CommonDialog control on a module. We can get to it whenever we need it, only accessing the portion we need at the time. This is much more efficient.
In fact, for a couple of these dialogs we’ll be placing the implementation in a module and accessing it whenever we need to, passing various items to new functions and retrieving the end result. We’ll also discuss how to take care of the user’s personal preferences, storing them in the registry and retrieving them as they are needed.
A dialog missing from the CommonDialog control is the Page Setup. This dialog has been included in the Dialog Automation Objects.
The only thing missing is the Help dialog, and any functions related to it. We’ll be covering this subject in a later chapter anyway, so we’ll leave it alone for now.
[Home Page] [Next Lesson] [Previous Lesson] [Dave Liske's Site] [Wrox Web-Developer]