Skip to content

net

  • in net, geek
  • 1 min read

LFSLib 0.11b

Two bug fixes.

  • OutSim was broken.. missing the Roll member
  • OutGauge and OutSim would not work right if there was no ID defined in the LFS config, since the packets would be 4 bytes smaller each.

Also added an OutSim form to the Tester app.

As usual, docs, sources, etc. can be found here

  • in net, geek
  • 1 min read

New LiveForSpeed Lib v0.10b, refactored

Ok, 0.10b of my lib for Live For Speed is out, but it was refactored quite a bit, so it's not a drop-in replacement.

The refactoring was done in order to let the InSim library receive and handle OutSim and OutGauge events. InSim, OutSim and OutGauge are now all part of one library. The OutSim and OutGauge protocols can be used either via their own standalone handlers or received directly via the InSimHandler.

Here are the breaking changes when switching to this revsion:

  • Renamed namespace LiveForSpeed.* to FullMotion.LiveForSpeed.* so as to not monopolize the LiveForSpeed root namespace.
  • Moved LibVersion to FullMotion.LiveForSpeed.LibVersion
  • Renamed LibVersion.SERIAL to LibVersion.INSIM_SERIAL

As usual, docs, sources, etc. can be found here

  • in net
  • 1 min read

configSource attribute

I've been using the new tag for .NET 2.0 to store my DB config. I used to just have a custom handler for it before. But hey, it's built in, let's use it. Now i'm putting NUnit in a bunch of projects so they all need to have app.config files. But i don't want them to each have a copy of the strings. Just means sooner or later things get screwed up. Not to mention that having the config file in the source control tree means that my local config gets checked in and i have to modify them on every machine to match environments.

For and my own config handlers, I always had a file attribute to externalize them into a central configuration space. Except doesn't have file, only configSource. At first glimpse it looks like the same thing. Sure, it adds some cool stuff, like being able to reload on change, which file couldn't. But the price you pay is that the new file has to be in the same directory or a subdirectory. So much for using one config for multiple apps. I may be overlooking something, but I can't really find any good reference on the subject.

  • in net
  • 2 min read

Exposing child objects

Consider a business object that has a list of child objects. Let's assume that the parent has to do some housekeeping operations when children are added or removed, and also has some rules what children are legal to add.

Before delving into various solutions using collections, let's consider the problem of ownership of the data returned from an object.

While the access scenario of

foreach( FooChild child in Foo.Children)
{
}

is the desirable one, there is no stopping someone from doing

FooChildren[] children = Foo.Children;

and then carrying the collection around. Of course, the moment the collection changes inside Foo, the child collection retrieved is invalid, since it was an array and not re-sizable. Would that violate your expectations? I generally consider Properties to be Accessors, i.e. you get the value used by the object, not some clone for you to manipulate without affecting the originating data. And the above scenario would violate that expectation.

So are Properties really an object's data and results retrieved from a method such as GetChildren data for you to manipulate without an expectation of changing the data in the originating object? If not, can the rules governing retrieved data be expressed in code, or is this type of contract something that is only going to be communicated through documentation?

If we proceed that the expectation is that once you get a collection back from a property it's still associated with the parent we get behavior similar to Xml Nodes. That solution would look something like this:

foo.Children.Add(new FooChild());

Pre-C# 2.0, you'd have to create your own strong-typed collection object for the children. If you do this more than a couple times, that's a lot of repeated code, what with all IEnumerable requirements. But it does provide you the added benefit that you could define events for the parent to be notified when things happened, so it could execute its constraint logic, which an untyped arraylist would not.

In 2.0, the whole thing could be done with an ICollection or, even better, an IList. But you'd still have to write that generic class yourself because (AFAIK) there are no implementations that have events to notify you when the collection changes. All things considered, though, this promotes much better re-use and a cleaner interface.

Or is there a better pattern to follow that i've not touched on?

  • in net
  • 1 min read

VS.NET 2k5 final and Nullable types

Got the official release installed and had to make a couple of changes to my nullable code that was written against Beta 2. All good, though. It was just taking out hacky crap that branched on INullableType in generics code. Glad to see that nullable types are null when boxed now. Way to go CLR team!

However, the ADO.NET stuff isn't quite there yet. But at this point it's not so much a nullable type thing instead a matter that DBNull just isn't null, so you can't just cast a return value to a .NET type. Still makes writing typed DB interfaces a bit annoying. But with generics, it's at least worlds better than it was before.

  • in net
  • 2 min read

Nullable Types and ADO.NET don't like each other

Hopefully this will quickly be proven to be out of date, but at least as of the June CTP of C# 2.0, nullable types are not welcome by SqlParameter objects. This strikes me as extremely odd. Personally, I thought the whole reason to add nullable types to C# 2.0 is to finally get rid of the Value Type/Database Type disconnect over null values.

The biggest frustration building type-safe database interfaces has always been that value types cannot be null, but any column in a database can be null. I should stop here and also point out that 99% of the time columns in database are marked as "allow null" when they shouldn't. A column should only allow null if that null has a special meaning. Half the time people just use null to mean 0 for ints and then you get a lovely mix of 0 and null in there that means the same to business logic, but you have to treat watch out for when you run your reports against that table. Don't use null, unless you mean it! But I digress...

Type-safe database interfaces want to pull datatypes from the DB as their native types. So an int in the DB shoud be an int in code. But what do you do when that int allows null, to mark an unset value for example? Do you create a magic number like 0 that means null? Do you store it as object internally after all and throw exceptions when someone tries to access the null value? None of the solutions are all that appetizing.

Then C# 2.0 introduced nullable types. Value types that could have a null value. Yay, the disconnect has been plugged! Or so I should until i tried executing my first SqlCommand that had an SqlParameter with a nullable int passed in. It promptly threw an invalid cast exception.

So for the time being, at least, I get to do a fun little dance of checking for is INullableValue and then casting the value to INullableValue so I can check HasValue and use Value to get the underlying type. We'll see what happens with the release version of Visual Studio 2005 in December.

  • in net
  • 1 min read

VS.NET 2003 to 2005

I recently started playing with VS.NET 2005 Beta 2, mostly because I wanted to see the Class Designer in action. The first, pleasant surprise was that it co-exists peacefully with VS.NET 2003. I was afraid i might hose my daily dev environment with this experiment, but it seems to be ok. Haven't tried ASP.NET yet, since the switch, but i hear that IIS is the one bone of contention with peaceful co-existence.

But enough about the pleasantries. Converting some work projects, i came across a C# language change that I'm not sure is a change or a fix for a bug. Either way it makes me change my code...

namespace ConsoleTester
{
    public class Base
    {
        protected Base()
        {
        }

        protected Base(string x)
        {
        }
    }

    public class Child : Base
    {
        private Child()
        {
        }

        public Base MakeBase()
        {
            return new Base("foo");
        }
    }
}

This works in C# 1.0, but in C# 2.0 i get Cannot access protected member 'ConsoleTester.Base.Base()' via a qualifier of type 'ConsoleTester.Base'; the qualifier must be of type 'ConsoleTester.Child' (or derived from it). So is this a change in the spec, a bug in 1.0 or a bug in 2.0?

  • in net
  • 1 min read

String Formatting in C

I google this every time, i need to put a float inside of a String.Format() call. Never found a good reference, so i made a note to the place i got the answer from.

Those days are over! Steve Tibett has an excellent article on the subject

Update: Updated the link, as Steve Tibbet's blog software changed and with it the url.