An IComparer

In .Net you can very easily create a special class to handle comparing of (custom) objects. All you have to do is implement the IComparer or IComparer interface and implement it's one simple function: Compare.

So write a class that implements it:

public class MyComparer : IComparer<MyObj>
{
  public int Compare(MyObj x, MyObj y) {
    // If, for example you're working with an int:
    return x.IntProperty.CompareTo(y.IntProperty);

    // If, perhaps, it is a string:
    return string.CompareTo(x.StringProperty, y.StringProperty)
  }
}

The value you return must be negative if x is less then y, 0 if x is equal to y or greater then 0 if x is greater then y.

This can of course be used with things like MyCollection.Sort(new MyComparer()), really handy if you have strange objects.

SQL Null

I am seriously confused by whatever it is that makes SQL (At least PL/SQL and T-SQL) consider null in a completely different way then anything else.

If I write a query

SELECT *
FROM table1
WHERE column1 = 0

Then of course if column1 hasn't been filled yet it won't return anything since null != 0

Sooo, then why is it that this query

SELECT *
FROM table1
WHERE column1 != 1

Won't return anything at all either.

I understand that null is not really like anything else, but to exclude it when looking for something in a certain column seems odd to me, or am I missing something?

My Reflection

The other day I had some trouble with ASP.Net. I was saving a class I'd written into the ViewState (I did this a long time ago, I know now that that might not be the best idea) and it was giving me errors saying that the ViewState was corrupted somwhere around saving it into or loading it from the ViewState.

I had to fix this, but I still needed all the information inside the class. Even though I knew that it was not the right thing to do really and in the end proved to be seriously useless since another measure I took apparently removed the need of saving it in the ViewState altogether.

I did find a solution that worked before the other thing started to take over. I wrote 2 functions, one to save the info in the object into the ViewState and one to load it again.

using System;
using System.Reflection;

namespace My.NameSpace
{
  class MyClass
  {
    private void savetoViewState(MyObj saveobject)
    {
      Type t = saveobject.GetType();
      foreach (PropertyInfo info in t.GetProperties())
      {
        object value = info.GetValue(saveobject, null);
        if (value != null && test.GetType().Namespace == "System")
          ViewSate["myobj_" + info.Name] = value;
      }
    }

    private MyObj loadfromViewState()
    {
      MyObj myObj = new MyObj();
      Type t = myObj.GetType();

      foreach (PropertyInfo info in t.GetProperties())
      {
        object obj = ViewState["myobj_" + info.Name];
        if (obj != null)
          info.SetValue(myObj, obj, null);
      }

      return myObj;
    }
  }

  class MyObj
  {
    public string Name
    {
      get;
      set;
    }

    public int Number
    {
      get;
      set;
    }
  }
}

In the save function we get the type of the object we're working with, because the type class has some very nice reflection functions, among which are GetProperties(), GetMethods(), GetContructors and many more.
We use the GetProperties method to get all the properties and we loop through them in a foreach loop. Now we can examine each property seperately.

We get the value of the property by calling the PropertyInfo.GetValue() method which requires the object from which to get the property (our argument in this case) and an object array of index values, so that you can, I'm guessing, get a or multiple items in an array. The index must be null of you're getting non-indexed properties.

Then we check if our value is null, because if it is we don't need to save it, and we check to see if the namespace of the property's type is System, which in my case made sure that I was only saving properties that were of type System.String or System.Int32 etc and not Some.NameSpace.In.My.Project.

Finally if our property's value gets through these checks, we save it in the ViewState with a prefix to identify it as part of our object.

In the load function we do something very similar. First we instantiate a new instance of our class and we again get the type of it.
Then we loop through all it's properties, much like we did in the save function.
Now, though, we get a value from the ViewState, which should correspond to what we saved in there before. Now if there is a property that we didn't save then getting it from the ViewState will of course result in null, so we check if the value if null. If it's not then we call the PropertyInfo.SetValue() method which needs the instance of the object it must place the value in, then the value that it must place and again like with GetValue() an object array of indexes.

Once we've looped through all the properties, it should again be filled with all the relevant information and we're good to get to work on it again.

This is my first little bit of Reflection that I've written to date. I know it's not much, but since I didn't know if MyObj was going to stay the way it was and I wanted it to work regardless. I also didn't feel like going ViewState["myobj_name"] = myObj.Name; over and over, since the object I was working with had many more properties than this example.

In the line with if (value != null && test.GetType().Namespace == "System") I had just gotten the value of the property, if it had one at all, and then I'm checking to see if the type of that property's namespace equals "System", this is because in the object I was working with also had a few properties that were connected to lazy-loaded database entities, which in turn also had these, and if I wanted to save these then it would have been a serious disaster (Damn how did I ever think that writing an object like that in the ViewState would just work...).

Anyway, it's fun to see how easy a simple reflection function can be. I'd read about it when I studied for my certificate exams and I saw some of it at the Microsoft Dev Days this year, but it always seemed complicated and strange to me. All the more reason to try it out somewhere.

SVN+SSH username trouble in Netbeans 6.5

Haha, I was having trouble with SVN in Netbeans. It was trying to log in with the wrong user. I could checkout fine by editing the tunnel parameters in the checkout window, but after that if I tried updating it'd use my local username instead of the one I use on the server.

After looking around a bit I found the answer!
In the checkout window, when asked for the url of your svn server, add your username to the url twice. so

svn+ssh://username@username@ip.address.of.server/location/of/svn/repository

should do the trick, apparently Netbeans only removes the first username@ from the url. I tested it and it does seem to work.

Quick mail post

Linux has an excellent command: mail, now who can guess what it does?

Anyway, I was searching how to send something with this today even though I've looked at this before, it somehow got screwed up.
We only have mail on our server (and sendmail, but that seems way more complicated) and we need to send an attachment and have a sender address.

After looking around for a while I found this:

uuencode $writefile $readfile |\
mail -s "$subject" $recipient -- -r "$sender"

sorry if you don't like the use of variables in explanations, but this seemed easiest.

$writefile	is the filename as the person recieving the email will see it (can be same as $readfile)
$readfile	is the filename as it is stored on your hard drive
$subject	is of course the subject of the mail you are sending
$recipient	is the email address of the person you're sending it to
$sender	is the email address that others will see in the From: field in their mail

uuencode should encode the file so that it will show as an attachment instead of just binary giberish or plain text, but for me, in thunderbird, this doesn't work.
the '|' of course means that you're using the left command as input for the right one
and mail is the mail command.