BA 371: VC# Graphic User Interfaces

• User Interfaces in VC# & VS: a simple calculator:

  
  • Some requirements:
  • Let's do additions only.
  • Addition requires two numbers; clicking the Add button when only one number is present or when one or both of the numbers are not numbers generates an error. The error must pop up in a modal window.

  • Note that the interface is a GUI.
  • Note that the interface is a so-called Windows Forms Application (as opposed to a Windows Console Application).

  • In VS, setup a Windows Forms Application (not a Console Application!!)  project (File --> New --> Project --> Windows Forms Application).
    

  • Notice how the IDE automatically generates an empty form for you. Change the file name in the Solution Explorer from Form1.cs into Adder.cs (VS will ask you if it should change all references to that file in the project as well. Answer affirmatively.)
    

  • Notice how the blank form is displayed in Design View. However, behind the scenes, the IDE has generated VC# code for you that represents the form class and object. To see this code:
    
    
  • Select Project --> Show All Files. This should make a number of files appear in the Solution Explorer on the right side of the screen.
    
    
  • Click in the Plus (+) box next to the Adder.cs file. This should make the Adder.Designer.cs file visible.
  • Double click on the Adder.Designer.cs file to view the automatically generated code.
  • Notice how the class Adder is by default equipped with a couple useful methods; e.g.,Dispose() (called when on object of the class gets destroyed) and InitializeComponent() (called when an object of the class getes created).
  • Also notice how as part of the InitializeComponent() method, the form's Text attribute gets set to Form1.

  • Also note that the comment a few lines higher warns not to change this Text attribute in the source code editor, but rather to change it in the design view GUI ('properties' window). The reason for this is that since all of this code got generated automatically, you as a programmer take a risk when making modifications on your own while byapssing the automated code generation system.
  • Select the 'Code View' of Adder.cs and notice how AddForm is declared to be a child (inherits from) of the Form class. Hence, AddForm has all attributes and methods of the Form class.
  • Finally, notice how AddForm has its own constructor (AddForm()) and how, as part of this constructor, the above-mentioned InitializeComponent() is called.

  • In the Design View, select right-click-->properties and change the Text attribute from Form1 to simple adder.  Also change the (Name) attribute to AddForm. Now check the results in both Design View and code view.
    

  • Remember!! A form's Name attribute refers to its class name. The Text attribute only refers to the default Text attribute displayed in the form window's header.

  • Save your results.
  • It is important to note that unlike when programming a console application, when programming a Windows Forms application, you do not supply your own Main(). Instead, you must specify the 'startup form (' (done already for you in case).

  • Add some interactivity to the form:
    
    
    

  • In Design View, using the ToolBox (tab on left side of window) add the two buttons, three text boxes and the '+' sign (use a Label) to the AddForm class. Use the properties dialog of the various interface elements to fine tune them (e.g., font, and bold).
    
    
  • Using the properties dialog for the buttons and text boxes, change their Names and Texts as follows:

  • Top text box: Text: none (leave empty!), Name: FirstBox.
    
    
  • Middle text box: Text: none (leave empty!), Name: SecondBox.
    
    
  • Bottom (sum) box: Text: none (leave empty!), Name: SumBox.
    
    
  • Close button: Text: Close, Name CloseButton.
    
    
  • Add button: Text: Add, Name: AddButton.
    
    
  • Check in code view of Adder.designer.vb or in the form's 'properties' window if all the changes made it. If not, go back and fix the missing/erroneous ones.
    
    
  • Notice how on the AddForm class, each of the interface objects gets created using the new statement, after which their attributes get set.
    
    
  • Compile and run the code.
    
    
  • Note how the form is displayed, but pushing the buttons does nothing.
    
    
  • To make the form's controls 'listen' to the mouse, we must define its event handlers; i.e.,  define what must happen when certain events such as a mouse click occur.
    
    
  • Check in AddForm's code view if you have private functions named ..._Click(); one for each of the buttons. If not, double-click on each of the buttons in Design View and check again. These ..._Click() functions are so-called callback or event handler functions. An event handler gets called automatically when a specified mouse event; e.g., a mouse click while the cursor is located over the button, occurs.
  • Now you have these two ..._Click() event handlers, compile and run the program again. Notice how once again, nothing happens when you click the buttons. Obviously, this is because although the event handlers get called, they have no code yet; hence, they don't do anything yet.

  • Modify the code of the CloseButton_Click() function by adding a call to Dispose():

  private void CloseButton_Click(object sender, EventArgs e) 
  {
    Dispose();
  }
  

  Compile and run and notice how the form stays on the screen until you click the Close button. Also notice how when you click the Add button, it depresses but still does not result in an action (still no event handler defined for it yet).
  • Notice that the textboxes all accept typing. This is problematic, since the SumBox should not accept any typing; it should be used for display of results only.
  • In Design View, set the ReadOnly property of the SumBox to true.
  • Compile and run to check if this worked.

  • Let us now add some action to AddButton. Its job is to read the contents of FirstBox and SecondBox, then add them up and display the result in SumBox. We code this by adding another event handler (either write the event handler yourself, or have its skeleton generated for you by double clicking the Add button in Design View):

    private void AddButton_Click(object sender, EventArgs e) 
    {
      SumBox.Text = System.Convert.ToString(System.Convert.ToDouble(FirstBox.Text) + 
                                            System.Convert.ToDouble(SecondBox.Text));
    }
     

    Note how this subroutine gets called when AddButton is clicked. All it does is convert the Text properties in FirstBox and SecondBox to doubles, adds them up, converts the result back into a string which is then displayed in the SumBox.

  • Compile and run this.
  • What happens when you type a text rather than a number in either FirstBox or SecondBox and try to add them up? What happens when you leave one or both boxes empty?
  • Apparently, our code in AddButton_Click() is not very robust yet; it assumes that the values entered in FirstBox and SecondBox can be converted into doubles. This causes the problem that if a text not representing a number is entered, an exception is thrown and the program dies.

  • First deal with exceptions in general. Add a try/catch block to the AddButton_Click() function that catches any exception:

    private void AddButton_Click(object sender, EventArgs e) 
    {
      try
      {
        SumBox.Text = System.Convert.ToString(System.Convert.ToDouble(FirstBox.Text) + 
                                              System.Convert.ToDouble(SecondBox.Text));
      }
      catch {}
    }
    

  • Compile and run entering a text for one of the boxes. Notice how the exception is handled (no message), but now the program provides no feedback to the user on what the problem is.
  • Change the program so that the exception not only gets caught, but that a meaningful message is displayed to the user. We can do this using a MessageBox:
    that displays the textof the error handed to us by the error handler:

    private void AddButton_Click(object sender, EventArgs e) 
    {
      try
      {
        SumBox.Text = System.Convert.ToString(System.Convert.ToDouble(FirstBox.Text) + 
                                              System.Convert.ToDouble(SecondBox.Text));
      }
      catch(System.Exception f)
      {
        MessageBox.Show(f.message);
      }
    }
    

  • One last thing to do is to make sure that as a user types a new number in one of the text boxes, the SumBox is cleared. This way, the SumBox never contains a faulty sum. This, once again can be accomplished with event handlers; this time one for each of the input text boxes:

    private void FirstBox_TextChanged(object sender, EventArgs e) 
    {
      SumBox.Text = "";
    }
    
    private void SecondBox_TextChanged(object sender, EventArgs e) 
    {
      SumBox.Text = "";
    }
    
    

  • Suppose we want the little calculator we just wrote to be kicked off not as a separate application, but instead, it should be started from a menu option on a window. The parent window also needs a Close option. This would require some changes and additions to the existing code.
  • We must define a new window containing a menu. The menu needs two options:
  • Calculator...

  • Close.

  • Add a form item to the application (right-click on the project in Solution Explorer) (right-click--> Add--> New Item --> Windows Form). Name the form MenuForm.
  • In Design View, select a MenuStrip item from the ToolBox--> Menus & Toolbars category and fill out the menu’s name (MainMenu) and its options:
    • MainMenu
    • Calculator...
    • Close

  • Change Main() so that it now starts MenuForm instead of AddForm.

  • Compile and run. Notice how the application now starts with MenuForm and how its menus are interactive. However, since we have not coded any event handlers on the menu items, clicking them has no effect.

  • The next step is to add the event handlers. We need two:
  • A click on the Close option should dispose of the MenuForm.

  Double-clicking on the menu item creates the skeleton event handler. Add the Dispose() call to its contents:

  
  private void closeToolStripMenuItem_Click(object sender, EventArgs e)
  {
    Dispose();
  }
  
  

  Compile and make sure this works.

  • A click on the Calculator option adds a second skeleton event handler. Fill out its code as follows:

    
    private void calculatorToolStripMenuItem_Click(object sender, EventArgs e)
    {
      MyForm = new AddForm();
      MyForm.ShowDialog();
    }
    
    

    In other words; when the 'Caculator...' option is clicked, make a new AddForm object.

    Notice that this will not compile as the compiler complains that MyForm is not declared. Reason: the calculatorToolStripMenuItem_Click function lives on the MenuForm class, but this class does not yet have an object MyForm of class AddForm declared.
    

    Add the following line at the top of the code for MenuForm: private AddForm MyForm;

  • Now recompile, run, and... hey presto! Notice how the full functionality of the calculator is maintained within the confines of the MenuForm.

• General principles illustrated in this lab:

• User interfaces in C# consist of objects that have other objects that live on them. For instance, a form object may have a few button and textbox objects as well as other form objects living on it.
  

• The VS IDE provides wizards (Design View) that help create and layout the skeleton code for these objects.
  

• All the objects have properties and behavior.
  

• Objects are connected with mouse-based interaction through event handlers. These event handlers are functions that get automatically called when the specified mouse event occurs. Other types of event handlers exist as well.
  

• Objects of specific classes can create objects of other classes.
  

• Once you have a basic set of classes and event handlers, different user interfaces become mere variations on a theme.