Posts Tagged ‘C#’

ASP.NET GridView with an ObjectDataSource

Monday, October 26th, 2009

Just a quick tip:

I got the following exception today:

If a data source does not return ICollection and cannot return the total row count, it cannot be used by the GridView to implement server-side paging.

If you’re trying to return an IEnumerable from your select method, try changing it to a List or an array. That should clear the problem right up.

C# Interface Method Gotcha When Inheriting

Tuesday, February 3rd, 2009

I noticed some interesting behavior from C# yesterday at work. Truth be told, I’ve noticed this in the past, but I’ve only figured out what’s causing it today.

The behavior is this: when you inherit from a class that implements an interface, calling a hidden/overriden method from an object of the inheriting class that has been upcast to the interface will result in a call the the inherited function.

Ok, so that probably made no sense at all, which is why I will explain it, but not before a warning. I’m not sure if this is intended behavior, and I’m not sure if this is something I’m doing wrong. If someone can point me in the direction of an explanation or a correction, I would be very grateful.

Computer Bugs

On to the explanation.

Take a sample, trivial application that has widgets. These widgets just print messages out to the console. We have an interface, IWidget, which forms the contract for all widgets:

interface IWidget
{
    void DoSomething();
    void DoSomethingElse();
}

Next, we have a generic widget class, which we use for most widgets. This is called GenericWidget:

class GenericWidget : IWidget
{
    public void DoSomething()
    {
        Console.WriteLine("Doing something in GenericWidget");
    }

    public void DoSomethingElse()
    {
        Console.WriteLine("Doing something else in GenericWidget");
    }
}

 
And finally, we have a specific type of widget that does something different, called SpecificWidget:

class SpecificWidget : GenericWidget
{
    public new void  DoSomething()
    {
        Console.WriteLine("Doing something in SpecificWidget");
    }
    public new void DoSomethingElse()
    {
    Console.WriteLine("Doing something else in SpecificWidget");
    }
}

Now, we want to run some tests on our widgets, to see what’s going on. First, we’ll test the widgets themselves. Running:

GenericWidget genericWidget = new GenericWidget();
genericWidget.DoSomething();
genericWidget.DoSomethingElse();

SpecificWidget specificWidget = new SpecificWidget();
specificWidget.DoSomething();
specificWidget.DoSomethingElse();

 
will output:

Doing something in GenericWidget
Doing something else in GenericWidget

Doing something in SpecificWidget
Doing something else in SpecificWidget 

 Which is exactly what we expected to see. Test has passed.

Next, lets say we have a function that we want to pass widgets to, but we don’t know what kind of widgets we will be passing, only that they are widgets. So we pass them as widgets, but upcast them to IWidget, and call the methods on them from the interface. For example:

IWidget genericUpcast = new GenericWidget();
genericUpcast.DoSomething();
genericUpcast.DoSomethingElse();

IWidget specificUpcast = new SpecificWidget();
specificUpcast.DoSomething();
specificUpcast.DoSomethingElse();

 
which will give the following output:

Doing something in GenericWidget
Doing something else in GenericWidget

Doing something in GenericWidget
Doing something else in GenericWidget

Wait, that’s not right. The specificUpcast should call the method on SpecificWidget, shouldn’t it? At least, that’s my expected behavior. Just to prove there’s not something wrong with our specificUpcast:

(specificUpcast as SpecificWidget).DoSomething();
(specificUpcast as SpecificWidget).DoSomethingElse();

 
will yield:

Doing something in SpecificWidget
Doing something else in SpecificWidget 

which is our expected output all along.

If someone can explain this to me, or point me to a better method to upcast, then please do so. I’m finding a lot of my code needs to check for specific types in order to call the proper method, and it seems clunky and awkward. I’m sure I’m doing something wrong, I’m just not sure what.

As usual, you can find the source code here: Interface Upcasting Inherited Classes Gotcha

First Impressions Of Ruby

Saturday, December 20th, 2008

I like it.

A lot.

But I always knew I would. I’m so far impressed with how much effort Ruby goes to at making itself understood at a casual glance, and just how easy it is to write self documenting code. Writing code that’s free of braces and parenthesis is refreshing, and it’s nice to know the safety blanket is there (with regards to parenthesis for functions, conditional statements, etc) is there if I need it.

I started last night by flicking through Why’s (Poignant) Guide, and found it pretty good for the basics. I quickly picked up the general concepts and basic syntax fast, and Why’s Guide was pretty whimsical and kept things interesting. However I quickly bored of the absurdity in chapter 5 where the majority of its content is fluff.

I tried switching to SaphireSteel’s The Book of Ruby, however right at the start when the author stated:

if (subtotal < 0.0) then subtotal = 0.0 end

Putting everything on one line like this adds nothing to the clarity of the code, which is why I prefer to avoid it

I knew that this book would not help me. I already know many languages that require simple statements like that to be spread over multiple lines. I want a language to do this:

subtotal = 0.0 if subtotal < 0.0

Hi, Ruby.

Then I browsed over to Ruby in 20 Minutes and quickly flicked through the pages, and it concreted my knowledge. I like iterators, I like respond_to?, I like how everything seems to make sense. I also am pleased to see how many concepts map onto similar things in C#. Modules are like namespaces, but better. attr_accessor is like { get; set;}. attr_reader is like {get; private set;}.

I feel I’m ready to go find some code in the wild and attempt to read it. I’ll also see if I can come up with a post that maps Ruby concepts to C# concepts for other C# programmers interested in Ruby (and with IronRuby, there’s no reason why you shouldn’t be).