Now that the RC for ASP.NET Ajax is out, we're just around the bend from release. Thank goodness.

So I downloaded the RC and the control toolkit and started playing with the slider, since I would like to use it for a project. Unfortunately, it took me a while to figure out how to hook up clients-side javascript events to the slider. A forum post finally solved my problem. I figured I would share the solution.

            
Sys.Application.add_load(application_Load);

function application_Load()
{
    var behavior = $find('funkyBehaviorId');
    
    //$find('funkyBehaviorId').add_valueChanged(function() { onDoSomething(); });
    //$find('funkyBehaviorId').add_valueChanged(onDoSomething);
    //$find('funkyBehaviorId').get_events().addHandler("valueChanged", onDoSomething);
    
    //behavior.add_valueChanged(function() { onDoSomething(); });
    //behavior.add_valueChanged(onDoSomething);
    behavior.get_events().addHandler("valueChanged", onDoSomething);
}

function onDoSomething(sender, e)
{
    var div = $get('showMeSomething');
    var textbox = $get('_sliderTarget');

    div.innerHTML = "" + textbox.value + "";
}

<asp:Panel runat="server" ID="hi">
    <asp:TextBox ID="_slider" runat="server" />
    <toolkit:SliderExtender runat="server" TargetControlID="_slider" BehaviorID="funkyBehaviorId" ID="_sliderExtender" BoundControlID="_sliderTarget">
    </toolkit:SliderExtender>
</asp:Panel>

<asp:TextBox runat="server" ID="_sliderTarget" />

<div id="showMeSomething"></div>

All of the lines in the application load method work. They are all just variations on the same theme. Use whatever style you like. Use the $find method to find the sliderextender based on its behavior id, and attach to some events. The key that I didn't figure out for quite a while was to hook up to the slider extender via behavior id, not to its id or the id of the target. Once I found that out, everything went pretty smoothly.

Tomorrow, Wed Dec 20th 2006, CNN will be airing a special called "After Jesus: The First Christians". More info here. Looks interesting. We'll see how it turns out.

Thanks to Scot McKnight for the heads up.

Yay! I can't wait to get started with it. You can download it from the MS website for ASP.NET Ajax. They are, as of this posting apparently, updating the website. Five minutes ago the images still said Beta 2. Now they say RC :)

Interesting little note over on ThreatsWatch.org (by my own family middle-eastern language and politics expert, my brother Kirk) on Iraqi response to the Iraq Study Group report that came recently.

For all you Star Wars fans out there: Lucas in Love.

So I finally got my first volumes of the published Oxyrhynchus papyri today. This is the last of my birthday presents to roll in.

I got volumes 4 (published 1904) and 12 (published 1916), both for only $9.98 + shipping from here. Prices range from $9.98 to $132. I decided to go for a couple of the cheaper volumes for reasons of personal fiscal responsibility.

So what odd stuff do you find in these? Well, these volumes are published versions of papyri that span the lifetime of Koine/Hellenistic Greek, roughly 300 BC to 300 AD, give or take some years. Oxyrhynchus is a city somewhat close to the Nile in Egypt. Most documents are normal, everyday kinds of documents, like private letters, shopping lists, official declarations, and legal documents. In such cases their provenance is usually Oxyrhynchus, because there would be no reason to disseminate someone's shopping list.

For some documents this is not the case. Volume 4 contains various theological fragments. You can find noncanonical sayings of Jesus, a portion of the Septuagint (POxy 656), a very significant portion of Hebrews (POxy 657, aka P13), and a fragment describing a pagan sacrifice around 250 AD. You will also find fragments of Pindar, Aristotle, Livy (this one in Latin, which is unusual; most everything is in Greek), et al.

And, of course, they all come with handy translations and notes. If this is up your alley, order them from the link above for the seller. They were quite a bit slower than Amazon, even with basic shipping.

This isn't as obvious as I would have liked for it to have been, but here is how you make a label autosize and wrap appropriately for the text assigned to it when the label is in a Windows Forms FlowLayoutPanel. Set the following properties as you see below:

• Anchor: Top|Bottom|Left|Right
• AutoSize: True
• Dock:None

I found the solution here. Works great.

So I decided to sign up as an Amazon Associate and also create an aStore.

With the Amazon Associate program you can link to Amazon about books from your site and, if someone buys the book, you get somewhere between 4% and 8.5% commission on the purchase. Not bad.

The aStore is similar. It is a place where you can list and categorize books. If someone buys a book through your aStore, then you get some commission. Both seem like nice programs.

My aStore has books that I have liked in tech and Greek and would recommend, and lists of books that I find interesting but have not yet read.

I like books a lot. It is the main type of adornment in my study. When some people or sad about something they eat ice cream or chocolate. I either eat a steak or buy a book...or both.

So I was running FxCop on a library today and it decided to flag a problem, exposing List<T> publicly outside of a class. The recommendation was to use Collection<T>. The reasoning was sound, but there is something in the documentation that needs to be cleared up.

Just so you know, the reason is that List<T> is not really designed for inheritance. It can be inherited from (I have done that), but doing so has less value than inheriting from Collection<T>. Collection<T> has four protected virtuals, ClearItems (called by Clear), InsertItem (called by Add and Insert), RemoveItem (called by Remove and RemoveAt), and SetItem (called by the indexer set). If, for some reason, you were using List<T> and needed to change how any of these very essential methods of the collection work, you are up a creek without a paddle. Collection<T> uses List<T> internally and does basically nothing that List<T> does not do. It just allows for more flexibility. And in a public API, that is very important.

The solution listed in the msdn documentation for this, in my opinion, needs to be changed a little. It says the following: "To fix a violation of this rule, change the System.Collections.Generic.List type to one of the generic collections designed for inheritance." This is true, but I think you probably need to go further. And I think this further step is implied, though not clearly stated. Instead of exposing Collection<T>, expose a class which inherits from Collection<T>. If you want extensibility you cannot extend Collection<T> without inheriting from it. So, if you have a class called "Foo", don't expose Collection<Foo> but FooCollection, which would inherit from Collection<Foo>.

Now, if you don't do this, you are still not in huge trouble. Let's say you expose Collection<Foo>, somebody uses it, and then you change it to a FooCollection. Everything should still compile and run fine. The runtime will cast FooCollection to Collection<Foo> without a problem. But that is not the ideal. Expose FooCollection initially and you stand less of a chance of confusing the consumers of your API.

I just posted reviews for two books. If you are perhaps interested in a book called The Genius of Language, check it out. I have spoken of Lean Software Development: An Agile Toolkit before, but my official review is up now and can be read here.

A few things caught my attention today:

First, a joke. What if Microsoft made cars? Thanks Kirbli.

Second, an interesting post On Writing Maintainable Code.

So in an attempt to look deep into the bowels of the UpdatePanel of ASP.NET Ajax, I decided to employ one of my favorite geek tools, Reflector. Reflector has a nice interface, but Visual Studio's is a little better, so I tried out one of the addins that actually dumps the decompiled dll into text files. I ended up using this one. It actually creates the class library and pulled the javascript files out of the Microsoft.Web.Extensions library. Pretty cool.

But it didn't work perfectly. If you want to do the same, be prepared to deal with some issues.

1. Private classes aren't handled well. This is actually a problem with Reflector, not with the plugin. Only two classes (that I could find) used them, so those had to be manually fixed.
2. Enums were decompiled as their integer values. C# will not implicitly cast an int to an enum, so all of those ints had to be cast.
3. Properties where not properly decompiled, but that's not a surprise. As you .NET geeks surely know, properties are syntactic sugar, and are compiled in IL to get_ and set_ methods. These showed up in the decompiled C# code, and had to be changed to properties manually.
4. Ref and out were often switched.

After fixing a little over four hundred syntax errors, everything was fine :). It actually went pretty quickly, since most things fell into the above four categories, and those are easy to fix.

Now I have the MS ASP.NET Ajax library in code files.

So the plugin works pretty well, though things could be improved.

The meeting tonight is on Watir. Information about this meeting of the North Dallas .NET User Group can be found here. If you're a geek like me and live in the area, maybe I'll see you there...

It can be found here. I am not as impressed as I would have liked to have been. I would like a nice time tracking/project management tool. I figured this would not have worked as a project management tool, but even for a time tracker I just found it unsatisfying.

I created a sample project, some users, etc. I started entering time. What struck me as odd is that I can't see where you can ever say a task is complete. That just seems like it would obviously belong in something like this.

Anyway, it is a starter kit, so it's not supposed to be too fancy. But I would have expected more.

We are switching a project I'm working on from a custom logging solution to the one built into the Enterprise Library, the "Logging Application Block". This is nice, because it means we can get rid of quite a bit of custom code (that's code we no longer have to debug or maintain). The logging application block is very well done as far as I can tell thus far. It makes it very easy to configure logging without having to change code.

Because we do have a particular way of logging that doesn't fit exactly into what the app block does, I did have to create a custom trace listener. But even with that I was able to remove several hundred lines of unnecessary code.

I think there are really three main advantages for going this route. First, the logging is completely configuration file based, and in the app.config. This is excellent, because QA and our deployment team to change the logging for debugging's sake without having to have development mess with it.

Second, when you use a solution like this you have a much better chance of pulling off consistency across groups. If everyone is using the same logging solution, then everyone knows what to expect and what to do when they need to deal with any aspect of logging.

Third, as it was said above, it requires less code. Granted, it is probable that the enterprise library team did not write the application blocks without defects. There may be some bugs in the logging application block. But I can guarantee that their code was more extensively tested than our internal code. I trust it quite a bit more.

A temptation that we programmers can easily fall into is the desire to over-architect and write code we don't really need to write. I have that same temptation. I like programming. I like flexing my programming muscles. And sure, we all program extraneous things to learn more about our craft. That's very important. But as professionals, we need to think about what needs to be created, not necessarily what we want to create. We're lucky when those are the same. But when they are not, we shouldn't pretend that they are.

Now, a little nitty-gritty. There are a few important sections in the configuration of the logging application block. <listeners /> is the section where you define what listeners you want to use, whether that is a built in listener like the file or event log listener, or a custom listener. These are the things that "listen" for logging requests, and log appropriately.

The <formatters /> section is a little more boring, but can be useful for formatting the log messages.

The use of the <specialSources /> section is not immediately obvious, and took a little digging, and this posting was helpful. Essentially, the listeners listed here are used when the typical logging fails, and something needs to be logged about that.

The most important section is the <categorySources /> section. That is where you route different categories of log messages to different sources. For example, you can log "information" log requests to the event log, and "errors" to a database log. You can route things to email, a message queue, a text file, or a custom trace listener. If you want to go the custom route, you can maybe send an instant message or an sms message.

It is the last bit that I find most useful. Because it is configuration file based, anybody can change what goes to where anytime they want to, and no code needs to be touched. What a good idea that was...

If you want more information, I recommend reading the documentation and checking out this series of posts. That link is to part 4 in a 4-part series since it is only the last part that has links to all the other parts in the series.

So a couple weeks ago we received some coupons in the mail for the Carson and Barnes circus. I don't ever remember going to the circus (maybe I did when I was really young...I'll have to ask my mom), so I thought this would be fun.

First, it was really small. It was held in a small rodeo arena in Mesquite. Are all circuses as small as this one? Unfortunately, I have no frame of reference.

Second, it was fairly pricey. As I expected, you get coupons to get in fairly cheaply so they can gouge you on pony rides, the bounce house, elephant rides, over-prices mediocre food, and little toy trinkets. The whole fam got in for $20. But we spent quite a bit inside on little things. We bought two flashy lighty things for the kids. One of them stopped working within about 10 minutes.

Third, unlike what they say, it is not fun for the whole family. Abigail (2) was pretty enthralled. It took a while for Jonathan (4) to get impressed. After about 10 minutes of the show he said he was ready to go. We stuck around a while and he eventually started enjoying himself. But for adults...well...calling it lame would be by association an insult to everything which has to this point been called lame. There was so much obviously fake sponteneity. It took about 10 minutes for the "acrobats" and such to actually do something that I didn't think I could do. That's pretty bad. I'm uncoordinated, a slight bit overweight, clumsy, and relatively weak. And I have no experience in gymnastics. The trapeze artists fell once. That was kinda funny.

The supreme act of lame circus-ing was the "volunteer" horse rider. A guy came out to the middle ring and rode standing on the back of two horses. They made a big todo about calling out a volunteer from the audience. The volunteer tried to get up on the horses and fell, and swung around by the safety harness that was attached. In shame she walked off, only to be goaded into doing it again by the ringmaster and the crowd. This time she actually climbed up the horses, but eventually fell off again. Then we saw the trickery. In mid-swing her pants fell off and she was wearing her gymnast-circus-leotard thingy underneath. SHE WASN'T EVEN A VOLUNTEER! That was just the last straw...

If you have really young kids, they might enjoy it. Otherwise, don't waste your time.

On Wednesday it was pretty warm. 70's, maybe even 80's. On Thursday, it looked like this:

Yes, that's right. My son is mowing the lawn in 20 something degree weather.