d20 die roll string parser and roller in C#

[Chris Tavares]

NUnit 2.4.7 was just released, so it's under development. Whether you like the direction NUnit has gone in is a very different question.

VS unit tests and NUnit tests are pretty much on par feature wise. VS has some nice features for testers (like web tests and setting up database stuff) which are completely useless for, and actually interfere with, developer unit testing.

The thing is, VS Unit Tests were designed for testers, not for developers. So it's got tons of stuff about managing and building test lists, storing reports, repeating runs, etc. None of which is anything that's even remotely useful for developer unit tests.

The VS test runner is a little better in 2008, but it's still awkward. If you want a really good unit testing experience, go download from http://www.testdriven.net/ . It's a VS addin that lets you right click on a test class or method, or on anything in the solution explorer, and it'll go out and run the tests. It's the simplest thing that could possibly work, and it works fantastically well.

As for the observer discussion, put me down on the "overkill" side. I'm a big fan of the YAGNI principle: You Ain't Gonna Need It. I've had lots of projects in the past where I've put in generality that "I know I'm going to need!" but ended up not needing at all. The result being carrying around lots of maintenance burden for overly general stuff that wasn't even being used.

Yeah, I'm one of those agile hippy freaks I guess. ;-)

 

[wenoc]

Whoa!
I thought my dieroller had gone and been forgotten as soon as it was bumped off the front page. I guess I was wrong. I'm happy to see someone caught an interest!

Oh, and I know it's Wenoc here and Malar in the original source, but I kinda got stuck with the latter nick since fifteen years ago or so, and it felt so stupid to create a profile with that name on these boards. I'm sure you understand.

 

[FormerlyDickensC]

Thanks for sharing your code to begin with. Share and share alike!

 

[Plane Sailing]

... XAML, using (Data)Triggers and Setters, or Control & DataTemplates.
My advice:
Try to understand how this stuff works as soon as you notice that you write code-behind that directly changes your visual representation (ranging from adding whole visual elements over setting the content of ItemControls to switching Visibility of elements on or off (Hidden/Collapsed).
Off course, before you do that, you need to understand DataBinding and also Converters.
Oh, and understing Resources and ResourceDictionary is also important.

I'm finding some of the things "wow" and then I want to do something myself and I'm thinking "huh?" as I try to work out from various blogs how to do something I want to do. Binding a ListBox to my ObservableCollection object is currently proving more difficult than I've been led to expect by various books!

One of the bits I'm finding frustrating with the XAML side of things is how to debug databinding - if I'm not seeing the data items I'm expecting to see, it seems much more difficult than the old faithful "attach a breakpoint and see what's happening" that you can do with procedural code!

Don't get me wrong - I'm in love with some of the things you can do with triggers, templates, resources and the like It is just sussing out the "right" way of doing things which can be a pain sometimes

Cheers

 

[Mustrum_Ridcully]

I'm finding some of the things "wow" and then I want to do something myself and I'm thinking "huh?" as I try to work out from various blogs how to do something I want to do. Binding a ListBox to my ObservableCollection object is currently proving more difficult than I've been led to expect by various books!

One of the bits I'm finding frustrating with the XAML side of things is how to debug databinding - if I'm not seeing the data items I'm expecting to see, it seems much more difficult than the old faithful "attach a breakpoint and see what's happening" that you can do with procedural code!

Don't get me wrong - I'm in love with some of the things you can do with triggers, templates, resources and the like It is just sussing out the "right" way of doing things which can be a pain sometimes

Cheers

Yes, the debugging often seems to become a lot more difficult. If you're using Visual Studio 2008 and .NET 3.5, it's possible to get the .NET source code for debugging purposes online. (100% legal, but you won't be able to change it, off course.) I haven't tried it yet, since I am still stuck with 2005 and .NET 3.0.

How do you want to bind your ObservableCollection? One of the easiest way to do it is to expose the ObservableCollection as a (possibly dependency) property on your control.
You can now use a syntax like this

ItemsSource={Binding ElementName=ControlWithDesiredProperty, Path=ItemCollectionPropertyName}

This would assume that you're naming your control in the XAML with x:Name=ControlWithDesiredProperty
(x being your "http://schemas.microsoft.com/winfx/2006/xaml" namespace.)


If you go deeper into templating, you will probably use TemplateBinding and RelativeSources in your bindings, and will do without using elementnames. Instead of using the ElementName, you can also set the DataContext to that element (if you have multiple bindings to the same element, this will probably clear up the code...)

What usually isn't enough is just setting the ItemsSource property to your desired collection (in code) if you expect the collection itself to be replaced often. (If you use change its contents, it will work fine).

 

[Plane Sailing]

How do you want to bind your ObservableCollection? One of the easiest way to do it is to expose the ObservableCollection as a (possibly dependency) property on your control.
You can now use a syntax like this

ItemsSource={Binding ElementName=ControlWithDesiredProperty, Path=ItemCollectionPropertyName}

This would assume that you're naming your control in the XAML with x:Name=ControlWithDesiredProperty
(x being your "http://schemas.microsoft.com/winfx/2006/xaml" namespace.)


If you go deeper into templating, you will probably use TemplateBinding and RelativeSources in your bindings, and will do without using elementnames. Instead of using the ElementName, you can also set the DataContext to that element (if you have multiple bindings to the same element, this will probably clear up the code...)

What usually isn't enough is just setting the ItemsSource property to your desired collection (in code) if you expect the collection itself to be replaced often. (If you use change its contents, it will work fine).

The approach I'm attempting to use at the moment is putting in windows.resources an ObjectDataSource as follows

<ObjectDataProvider x:Key="CreaturesDS"  ObjectType="classes:Creatures" MethodName="Load">
    <ObjectDataProvider.MethodParameters>
        <system:String>creatures.xml</system:String>
    </ObjectDataProvider.MethodParameters>
</ObjectDataProvider>

and then I create a CollectionViewSource which I bind my objects to. Well, that's the theory anyway, but I've not got that working properly yet!

I've had great success with XmlDataSource and two-way binding to an external xml file, which has made populating my critters xml very easy now.

(Oh yes - I've found that VS2008 will send run time errors to the Output window when debugging, which can be helpful - even if I miss my breakpoints and examining variables!)

Cheers

 

[Mustrum_Ridcully]

I'd really love to give you some useful comments here, but I haven't done anything with the
ObjectDataProvider or ObjectDataSource classes yet. And I feel like I might have missed something important or useful. But maybe not, I am not sure how or where I could use it. (We're using XML, but never display it directly...)
Maybe I get some experimenting done another time, but my hopes are slim.

Or did you figure it out yourself already? Inquiring minds demand to know!