Feeds:
Posts
Comments

I am back!

I had been out of blogging for around the last two months. After getting caught in the cycle of testing and bug fixes, things around me appeared dull and uninspiring. I hardly read any article or book during this period.

The much needed break came when I went to Bangalore for three days. This gave me the chance to do the things I love the most.

  1. Travel
  2. Read a detective or horror novel on a rainy night (It was The Carribean Mystery by Agatha Christie)
  3. Dine at restaurants
  4. Spend some time for myself and find out what I love to do, to decide if I am happy with the where I am and plan for future.

And it worked. I am again bubbling with energy and vigour. The first goal I shall try to achieve on the bloging front is to write regularly.

It is a common practice to represent an UI operation that a user can perform as an Action. For example, to open a file in Notepad is an operation that can be represented by an action, say OpenFileAction.

Actions are implemented using the Command pattern. I’ll provide a short explanation of the Command pattern below.

The Command pattern has the following two major players.

  • IAction Interface – This interface declares the Execute() method.

    public interface IAction
    {
    void Execute();
    }

  • Action Class – The concrete action class like the OpenFileAction implements the IAction interface and provides it’s own Execute() method. Either the constructor or the Execute() method itself can receive an argument that acts as the input on which the action will be performed.

    public class OpenFileAction: IAction
    {
    public void Execute()
    {
    // The code for opening a file goes here…
    }

    }

Thus, the Command pattern allows to encapsulate an operation as an object.

Answers to a few questions need to be explored before going ahead.

  1. Where can the actions be used?
    • In a modern software application, any operation can be performed from a number of places. For example, a new file can be created from the menu or the toolbar or a right click context menu. Having an action like CreateFileAction allows to call it’s Execute() method from all the three places.
  2. Why should I use actions?
    • The biggest advantage of this concept is that the UI and the Business Logic are separated which creates a system with lower coupling. Duplication of code is also avoided as the same action can be used form any place.
  3. Can an action be called from another action?
    • Yes. I’ll give a practical scenario where the calling code must know whether the action was executed successfully. Suppose you are working on a text file in a text editor, say MS Word. To close the application, you click on the Close menu under File. This fires the CloseApplicationAction. But the file has to be saved before closing the application. It’s the SaveFileAction that takes care of saving the file (in case it is unsaved) . Instead of putting the code for checking if the file is unsaved and asking the user if he wants to save the file in both the actions, the CloseApplicationAction simply calls the SaveFileAction internally. Thus, once an operation has been abstracted as an action, it can be called from anywhere given one can pass it the right input.
  4. What if the action needs to inform about it’s success or failure? How can this be done?
    • In the above-mentioned example, the CloseApplicationAction in turn calls the SaveFileAction. The SaveFileAction first checks if the file has been modified. If it has been, the SaveFileAction asks the user if he wants to save the file – Yes, No and Cancel options are provided. Now the CloseApplicationAction depends upon the outcome of the SaveFileAction. In case the user says Yes or No , the SaveFileAction does accordingly, the control comes back to the CloseApplicationAction and it must closes the application. However, if the user chooses Cancel during the SaveFileAction then the CloseApplicationAction must terminate without closing the application. The simplest way to give the success or failure feedback is to return a boolean from the Execute() method.

public interface IAction
{
bool Execute();
}

Thus, the Command pattern allows to encapsulate an operation as an object. The Java framework provides a built-in support for Actions. In one of my next posts, I’ll write about how Java is more “Action friendly” as compared to .NET.

Writing a method is as often a job for a programmer as posing for a photograph by an actress. The following 10 points can be used as guidelines while writing one.

  1. Single well-defined purpose – A method must have a single well-defined purpose to serve. This functional cohesion is at the very base of constructing a method.
  2. Documentation, a must – A method should be well documented that is it must include notes on the following.
    1. The problem the method is going to solve
    2. The input parameters
    3. The output provided
    4. The Pre-conditions that must be satisfied before the method is called
    5. The post-conditions that the method will fullfill once the method terminates
    6. Exceptions that the method throws in case of an unexpected situation.
  3. Name must clearly indicate the purpose – A method must have a good name that summarizes what the method does.
    1. In object oriented programming the object on which the method works is mentioned. For example, document.Print() implies that the print is for the document. Thus a verb like Print is sufficient as a method name.
    2. In procedural programming the method name should include a noun as well like PrintDocument().
    3. The name should indicate everything that the method does. For example, suppose a method opens a file and display’s it’s content. The name of this method may be OpenFileAndDisplayInfo(). Following this can indicate a possible violation of the first rule of functional cohesion. Opening a file and displaying it’s content are two different tasks and should be done by two diferent methods like Open() and DisplayInfo().
  4. Not more than 7 arguments – A method should not have more than seven arguments. Imagine what will happen if you have 7 kids to take care of. However, I personaly find it difficult to work with more than three or four arguments in a method.
  5. Have an argument, must use it – A method must use all the arguments that it takes. If this is not the case, just remove the redundant argument.
  6. Beware of bad data – A method must guard against bad data that might be provided as the input or can be generated inside the method during a calculation like division by zero.
  7. No magic numbers - Use of numbers like 100 instead of array.Length leads to error when the array length has changed. Moreover, they are difficult to change as you will have to go on hunting for all the occurances of 100, figure out which of those 100’s represent array.Lenght and then change them.
  8. Proper layout - A method should be easier to read, without much effort or pain, for a person.
  9. Write what the method does- All the steps inside the method should be put as comments at the beginning of the method.
      public bool Open(string fileLocation)
      {
      // 1. Validate the input – check whether the fileLocation is a valid location
      // 2. Check if the file exist
      // 3. Check if the user has the required permission
      // 4. Check if the file is read-only
      // 5. Open the file
      // 6. Return true if file could be opened and false otherwise

      // 1. Validate the input – check whether the fileLocation is a valid location

      // 2. Check if the file exist

      // 3. Check if the user has the required permission

      // 4. Check if the file is read-only

      // 5. Open the file

      // 6. Return true if file could be opened and false otherwise

      }

  10. 100 to 200 LOC - A method length should preferably be between 100 to 200 lines of code. Remember the lines of code does not include comments and spaces.

The above 10 points will make a method far more reliable and easy to understand.

The Form has a property FormBorderStyle that decides the kind of border around it. A similar property for a Control is BorderStyle. There is no way to customize these borders directly from the Form Designer. The class System.Windows.Forms.ControlPaint has the methods that come handy when you want to:

  1. Draw the border with a particular color say blue or yellow.
  2. Draw a border whose sides have different color or thickness

The MSDN link for the class is here.

Create a Windows application in Visual Studio

I have written a small program to illustrate this. Create a Windows application in Visual Studio and added a Panel – panel1, to the form, Form1 – the default form created by Visual studio. Anchor the panel to all the four sides of the form.

Add event handler for the Paint event of the Panel

Next add an event handler for the Paint event of the panel and use ControlPaint.DrawBorder method to draw a deep blue border around the panel. The panel BorderStyle must be set to none in the Form designer.

private void panel1_Paint(object sender, PaintEventArgs e)
{

ControlPaint.DrawBorder(e.Graphics, this.panel1.ClientRectangle, Color.DarkBlue, ButtonBorderStyle.Solid);
}

The only problem is that when the form resizes, the panel resizes but the previous borders of the panel are not deleted. To solve this problem, just invalidate the form on panel resize.

Invalidate the Form on Panel Resize

Invalidating the form on panel Resize, triggers the Paint event of the form and all it’s controls. The panel is also repainted. This erases the previously drawn panel borders and creates a new border around the panel.

private void panel1_Resize(object sender, EventArgs e)
{
Invalidate();
}

To draw a border whose each side is different color or thickness, use the other overloaded form of DrawBorder method. To draw 3D border just use DrawBorder3D method.

« Newer Posts - Older Posts »