Archive for May, 2007|Monthly archive page

Explore the Undo/Redo – Part II

Here is the list of the types and variations of the Undo/Redo functionalty.

1.Blind Undo/Redo

The Undo/Redo functionality without specifying the operation which will be performed.

2.Instructional Undo/Redo

The menu item offering the Undo/Redo functionality also displays the operation which will performed. This makes use of the DisplayName of the edit to be performed.

3.Single Undo/Redo

The typical notepad style supporting Undo/Redo only for the last operation performed.

4.Multiple Undo/Redo

Multiple Undo/Redo supports unlimited no of edits for all the opertaions performed.

5.Multiple Undo/Redo with the UI to choose the number of edits.

Its the typical MS word style. The UI(toolBar Button) shows the DisplayName of  all the edits in the Undo/Redo stack providing the option to choose the multiple edits to be performed. This provides the option of performing Undo on the last N opertaion at one shot.

More sophisticated implementation would be allow the user to choose the edit which need not correspond to the last edit operation.

For Eg:

Operation 1- Delete a line

OPeration2- Find Replace operation performed for a particular word

What if user wants to perform Undo for operation1 but NOT for operation2?

My next post will be on the Challenges that I faced in implementing Multiple (Instructional) Undo/Redo .

Explore the Undo/Redo – Part I

Imagine preparing your project report in MS Word without having to use Ctrl Z/Y. You will bulb for sure, its going to be very very painful.

That’s the power of Undo/Redo. We take it for granted in any standard, user-friendly software.

  • It acts as a Saviour, during the times of distress
  • It makes the learning process like a ride on a Highway.
  • It allows the users to explore the software with a confidence that he can always recover easily from the mistakes, during the learning process.

Q. But why does a computer application need the Undo/Redo functionality, when the underlying piece of code will never ever go wrong it its output. You run the same operation 1000 times with the same inputs you are guaranteed to get the same output every time?

Ans. The Undo/Redo is meant for the User and not the application itself. Yes the computer program never makes a mistake but humans do. They are by default error prone.

What the designed applications treats as an invalid input for an operation might be a perfectly valid input from the users side.

The role of Undo/Redo comes into picture when an error(s) is made and the user realises it and express a strong intent to recover from the mistake(s) made.

The application must always assume that the user is always right.

Let’s solve the Recursion

The code posted below is a very simple recursive code for performing the search operation. Reading the code will force you to follow a visually cyclic path but instead visualising the search operation as a traversal along the tree from the root node to the leaf node of the last top level node follows a straight visual path.

Most of the single recursive methods can be split into group of atomic methods .

//iterate the collection (this is where the recursion is imposed)

//validate the input object against the object of interest

——————————————————————–

//Finds the first treeNode encountered in the Hunt operation, which is tagged to the //specified object.

//Returns Null, if the search operation fails to find a node tagged to the object specified Or if the specified object/nodeCollection is Null.
private TreeNode FindNode(object taggedObject, TreeNodeCollection nodes)
{
//validate inputs
if (taggedObject == null || nodes == null)
{ return null; }

TreeNode nodeToReturn = null;
foreach (TreeNode node in nodes)
{
if (Equals(node.Tag, taggedObject))
{
return node;
}

//Now search in children of this node.
nodeToReturn = FindNode(taggedObject, node.Nodes);
if (nodeToReturn != null)
{
return nodeToReturn;
}
}
//no matching node found. Hence return null!!
return null;
}