Skip to content

Inspecting a DataTable or DataSet in Visual Studio

I had to do some coding in Visual Studio, which I had not done in a long time.  I simply needed to retrieve a value from a database and based on that value, limit max quantity to be displayed in a dataset that was returned.  So, if the ‘Max Quantity’ was defined as 50, then no values in the ‘Quantity’ field in the dataset could display as greater than 50.

So, I created a dataset and ran a query on a SQL Server database to get the appropriate values.  At some point, I was getting an error.  I wanted to check the fields and values in the dataset, so into the debugger I went.  As I was inspecting the code, it occurred to me that I could not remember if there was a way to “inspect” the dataset.  In Eclipse, you can inspect any primitive, object, or method by highlighting it or by both highlighting it and pressing [CTRL]+[SHIFT]+I.  This is shown below:

How ‘Inspect’ works in Java

However, I could not find similar functionality in Visual Studio for inspecting datatables or datasets.

It turns out, the way to do this is both straightforward, but not immediately obvious.  To view the data in your dataset in debug, simply highlight the dataset until the intellisense pop-up displays.  See that little magnifying glass icon?

Visual Studio Intellisense

Just double-click that, and you can see your entire dataset in the DataSet Visualizer.  The image below has an empty dataset, but you get the point.

The Visual Studio DataSet Visualizer

Bubblesort

Bubblesort (aka Bin sort) is a slow sorting algorithm. It averages in O(n^2) time, so there are much faster sorting algorithms, but it is still something to think about. It is called bubble sort because the larger values “bubble up” through the sort after successive iterations. The following is an example of a simple bubble sort using Java:

public int[] bubbleSort(int[] array){

int i, j;

for (j = array.Length – 1; j > 1; j–)
{

for (i = 0; i < j; i++)

{

if (array[i] > array[j])
{

int temp = array[j];
array[j] = array[i];
array[i] = temp;

}

}

}

return array;

} // end bubbleSort

There are different ways to implement bubble sort depending on how closely you want to follow Knuth’s definition. With further research, you will find that this previous example does not meet all of his requirements. For more information about Bubblesort and its variants, check out this retina-burningly-awesome resource.

Updates coming soon!

It’s been awhile, so I am trying to force find time to create a new series of posts, so stay tuned!

Code Rush

I just finished watching a film on YouTube called Code Rush.  It is a documentary about the last days of Netscape between 1998 and 2000.  This time period starts just before they released their Mozilla browser code for open-source use up until they were purchased by AOL.  It makes it all the more interesting that the successor to Netscape, Mozilla, actually was able to release FireFox at all.

The video can be found here.

Programming Quotes

There is a great poll over at stackoverflow with a list of programming quotes.  Here are my favorites:

Hofstadter’s Law:  It always takes longer than you expect, even when you take into account Hofstadter’s Law — Douglas Hofstadter

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live — Rick Osborne

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it  – Brian Kernighan

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems — Jamie Zawinski

There are only two kinds of languages: the ones people complain about and the ones nobody uses — Bjarne Stroustrup

If debugging is the process of removing software bugs, then programming must be the process of putting them in –Edsger Dijkstra

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away — Antoine de Saint Exupéry

The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ but ‘That’s funny…’ — Isaac Asimov

And my personal favorite:

It works on my machine — Anonymous programmer

The Importance of Communication

In Code Complete, Steve McConnell discusses the importance of talking to someone else about a problem when debugging in Chapter 23: Debugging.  He says some people call it “confessional debugging,” meaning in the very act of explaining your problem to someone else, you discover its solution.  However, it is not only in the act of debugging that this sort of communication is relevant.

For example, a few weeks ago, I was working on setting up a test version of an ordering website for a customer.  As I assume is common in software, it was a piece of software I had never worked with before and I did not fully understand its functionality.  As I was setting it up, I came across a scenario where I would send an order (as a customer) and the order was not appearing in the seller’s application location.

I conferred with someone who actually developed much of the software.  I said:

Orders come through for some customers, but not others.   I checked the different settings in the database and everything seems to work correctly.  I also checked that each customer’s default location is set properly.  Wait, I did notice their default locations are different.  Duh, the orders are being set to a different location!

This is an example that shows how important face-to-face communication can be when solving a software problem.  It is easy to hide behind e-mail and ask others for help, but when you are actually working through the problem and explaining it to someone else, you can oftentimes solve the problem without their input.

Factory Patterns

So, I’ve been working on a basic Tetris program in Java.  There are probably literally hundreds of these on the internet to download and look at the code, but I figured it would be better to build it from scratch, learn from my mistakes, and then fix/build it again.  With this, I am working on becoming more familiar with the Java Graphics API.  It’s something that is slow going for me, but I’m pushing through.

At the same time, I am reading Head First Design Patterns.   It is a pretty good book for getting a broad overview of design patterns.  Once I finish this, then I will delve into a design patterns book that is a bit more advanced.  After reading the chapter about the Factory pattern, I realized that I could implement this easily into my Tetris program to improve it.  I wonder why I did not do this in the first place.

Now, the factory pattern is a design pattern such that multiple derived classes are created from an interface.  This interface is declared within the class that needs the derived classes.  The interface is typically called a “factory.”  This is useful in cases where the class utilizing the interface does not know what derived class it will need to use.  An interface does not have to be a literal “interface” in Java.  An interface can be a class, abstract, or an interface.

Here’s an abbreviated example of what I was doing wrong in my Tetris code:

public class Shape {
        // All tetris shape definitions
        private int generateShape(){
        // Lots of other code
}
public class GamePanel {
        Shape randomShape = new Shape();
}

In my code, I was creating a new Shape object in class GamePanel.  Within the Shape class itself, it would generate a shape type as an int and then define its properties according to the number (i.e. Color, L-shape, etc.).  This is terrible object-oriented design.  How does the factor pattern come into this?

Here is the new and improved code:

public abstract class Shape {
      // Code that applies to all shape types
}
public SquareShape extends Shape {
      // I have now separated all distinct shape properties into their
 own classes (e.g. Color, Shape Type, etc.)
}
public ShapeFactory {
        Shape shape;
        public Shape generateShape(){
                // Generate random number named randomNumber
                switch(randomNumber){
                       case SQUARE_BLOCK:
                               shape = new SquareBlock();
                       break;
                       // switch statement continues with other derived classes
                 }
                 return shape;
         }
}
public GamePanel {
        ShapeFactory factory = new ShapeFactory();
        Shape currentShape = factory.generateShape();
}

For those with more familiarity with design patterns, this code is not necessarily a “true” factory method.  Although the Shape class is abstract, the ShapeFactory pattern does not extend an abstract class.  This is because it was not necessary because I do not intend to add additional shapes based on the type of factory that is required

So, this is more of a factory idiom.  Anyway, it still does what a true factory method would do, which is encapsulate object creation.  In other words, all the objects are created within the ShapeFactory as needed.

This code is much cleaner because, first, the Shape object no longer defines its own shape type.  This is performed by the ShapeFactory object.  Second, all the derived objects from Shape contain their specific code in their own unique classes.  This has made the code in Shape much more manageable and much easier to read!

- Jason

Follow

Get every new post delivered to your Inbox.