Back in my college days, I remember getting an email from Peter with hilarious blunders made in church bulletins.  I don't believe I've laughed harder ever.  Several people in the library came by and asked if I was OK.  Today I got an email from my dad containing a similar subject.  I was prepared to hear the same list of blunders.  To my amazement, they were completely different, so I thought I'd share them:

Bertha Belch, a missionary from Africa, will be speaking tonight at Calvary Methodist. Come hear Bertha Belch all the way from Africa.

The Fasting & Prayer Conference includes meals."

The sermon this morning: "Jesus Walks on the Water." The sermon tonight: "Searching for Jesus."

Our youth basketball team is back in action Wednesday at 8 PM in the recreation hall. Come out and watch us kill Christ the King.

Ladies, don't forget the rummage sale. It's a chance to get rid of those things not worth keeping around the house. Don't forget your husbands.

The peacemaking meeting scheduled for today has been canceled due to a conflict.

Remember in prayer the many who are sick of our community. Smile at someone who is hard to love. Say "Hell" to someone who doesn't care much about you.

Don't let worry kill you off - let the Church help.

Miss Charlene Mason sang "I will not pass this way again," giving obvious pleasure to the congregation.

For those of you who have children and don't know it, we have a nursery downstairs.

Next Thursday there will be tryouts for the choir. They need all the help they can get.

Barbara remains in the hospital and needs blood donors for more transfusions. She is also having trouble sleeping and requests tapes of Pastor Jack's sermons.

The Rector will preach his farewell message after which the choir will sing: "Break Forth Into Joy."

Irving Benson and Jessie Carter were married on October 24 in the church. So ends a friendship that began in their school days.

At the evening service tonight, the sermon topic will be "What Is Hell?" Come early and listen to our choir practice.

Eight new choir robes are currently needed due to the addition of several new members and to the deterioration of some older ones.

Scouts are saving aluminum cans, bottles and other items to be recycled. Proceeds will be used to cripple children.

Please place your donation in the envelope along with the deceased person you want remembered.

The church will host an evening of fine dining, super entertainment and gracious hostility.

Potluck supper Sunday at 5:00 PM - prayer and medication to follow.

This evening at 7 PM there will be a hymn singing in the park across from the Church. Bring a blanket and come prepared to sin.

The pastor would appreciate it if the ladies of the congregation would lend him their electric girdles for the pancake breakfast next Sunday.

Low Self Esteem Support Group will meet Thursday at 7 PM. Please use the back door.

The eighth-graders will be presenting Shakespeare's Hamlet in the Church basement Friday at 7 PM. The congregation is invited to attend this tragedy.

Weight Watchers will meet at 7 PM at the First Presbyterian Church. Please use large double door at the side entrance.

Some ones I can remember from the original email were:

There will be a young mothers Bible study this fall.  All those wishing to be young mothers should meet with the pastor in his private study.

Bean supper tonight in the gym.  Music to follow.

The women of the church invite you to a “cast-off clothing sale“.  The women will be casting off clothing of all kinds

Anyone else remember any?

Clemens has a security patch for dasBlog.

Sheesh another nerd post.  I thought this might be useful information for the community.

If you're using multiple threads in the execution of an ASP.net page, don't count on Response.End() to do what you think it might do.  Looking back it's pretty intuitive, I just didn't think about it.

At work, we have some pages that can take several minutes to execute.  They can pull millions of rows from the database and process them and do all kinds of craziness.  As a result, users don't like to sit around and watch Internet Explorer's progress bar decieve them time and again.  I implemented a progress mechanism to let the user know what is happening.  I went through several iterations before I come up with something really easy to work with.  It's completely transparent to the developer, and allows them to “push” progress messages onto a stack (using the wonderful “using“ statement), which is rendered for the user at an interval during the lifetime of a page.  It preserves the behavior of postbacks and Server.Transfers, but does break redirects if they happen after the progress gets started (which I hardly ever do).

Anyway, the point of the story is to tell you about Response.End.  The progress updating happens on a worker thread from the ThreadPool.  When I implemented it, I thought it would be nice to detect if a user has closed the browser or hit stop.  Then we could save some resources if no one is listening anymore.  So, before updating the progress, I do a Response.IsClientConnected, and if they aren't, I was calling Response.End().  This seemed to work at first, because it does do something, the problem is it doesn't stop what's going on in the main thread.

Reflector (the most useful CLR tool ever) reveals that Response.End() is basically just calling Thread.CurrentThread.Abort(), along with doing some clean-up and such.  Notice the CurrentThread...oops.  All I was doing was ending my progress rendering thread.  Like I said, it makes perfect sense now.

So, what do you do about it?  Well, I'll come up with something.  It shouldn't be too hard, but it will be pretty specific to my situation, so there's no real universal answer, unless Microsoft were to change the implementation so that it was keeping track of the threads and killing the main one, although then my worker threads wouldn't die.  Chances are if you've implemented some kind of multi-threading in your ASP.net pages, you can figure it out.

I'll forever chuckle when I read that title.  Maybe you will too after you read this.

I was aware of the Nullable generic struct in the 2.0 CLR, but I only just now figured out that they've built direct support for it into C# 2.0.  This is awesome!  At work, we currently have a whole bunch of structs that add null support to the value types in the CLR.  So we have NullableSingle, NullableDouble, NullableUInt64, etc.  This helps us incredibly to match the database concept of numbers and such that can have null values.

I've been looking forward to Nullable for some time, but now I'm absolutely ecstatic about the C# support for it.  Using the magic question mark, I can declare a value type to be nullable.  For instance:

bool? hasHairOnHead = false;

Now you get the title joke, right? This means that hasHairOnHead can be set to null, not just through Nullable's HasValue method, but by actually setting it to null:

hasHairOnHead = null;

Freaking awesome, eh?  So now, the Headless Horseman's hasHairOnHead value can more accurately express his status. (OK, it was the first example I thought of).  The same goes for null comparisons and such!

Of course now I'll get confused reading documentation...Is that a question or a nullable type?  Just try to decipher this faq: Why don't nullable relational operators return bool? instead of bool?

That little question mark is going to save me alot of headaches.  Now I just have to wait for it to be out of beta. 

Today is Becky's birthday.  I'll refrain from revealing her age, as that would be detrimental to my health.  (She has a black belt in Kung Fu, you know)

I've been playing with the new membership framework in ASP.net 2.0.  The existence of this, and other nice things like the login controls are fantastic, but it really lacks the polish of other areas of the new framework.  Here's some constructive feedback:

The MembershipProvider looks like a pretty well designed base class, but it should implement more of its interface by default.  For instance, when creating your own provider, you're forced to implement Initialize, which configures the instance for the configuration in the web.config.  Initialize is defined in ProviderBase, but there should be a default implementation in MembershipProvider that at least configures the values for the required properties such as EnablePasswordReset and such.  I ended up using the Reflector to look at the AccessMembershipProvider to implement this method.  Also, the majority of the proeprties should have default implementations as well.

The documentation for implementing a MembershipProvider is also pretty inconsistent.  Some of the methods are supposed to throw exceptions for failures, some of them return booleans for success/failure (which I thought had been deemed not a good idea), and some of them say they should throw exceptions, but also return a boolean.

The MembershipUser class is also pretty good, but its ISerializable implementation is weird.  Deserializing one would leave it in an unusable state since its _Provider field would be uninitialized, and since it's not settable, its useless.

I love the idea and the ease of which you can use the membership concept. (The default “just works”) But to create the “pit of success”, there are some things to address and I hope someone is addressing them.

[UPDATE] Brad Abrams helped me get this feedback to the right people.  Thanks Brad.  It makes me feel really good about the direction of the .NET and Microsoft as a whole to know I can get my feedback to the people who need to hear it.  I may be making incorrect assumptions or drawing the wrong conclusions, but chances are if I am, then others are too.

The HD broadcast of the olympics just started...beautiful.  Just beautiful.

One weird thing though.  The audio keeps jumping from Dolby Digital 3/0 to 2/0 every few minutes.  I'm trying to figure out if it's a reception issue.  Anyone else having trouble?  If not, what are you getting?

[Update] I just went outside and unplugged all my cables except my cable modem and the livingroom connection.  I've got full Dolby Digital 3/2.1 now.  yeah!

The managed API for the windows performance counters is great.  It was just what I needed to track down some memory issues at work, and now I've got real-time information about what's going on.  It's much simpler than trying to use them with the old school api.  However, I need some more guidance on the usage pattern for creating and deleting the categories and counter definitions.  Are those things that should be part of an install/uninstall procedure, or should they be done on startup/exit of the program?  What kind of overhead should I expect in constructing/incrementing/disposing them?  The counters implement IDisposable, which makes me want to dispose them quickly.

Maybe some spelunking with the Reflector will shed some light.  I'll keep you posted.  In the meantime, feel free to share your experiences with performance counters in the CLR.

[Update] Duh.  I ran across System.Diagnostics.PerformanceCounterInstaller the other day.  Looks like that's how you should install them.  I love the installers as well.

I ran across the new web-based MSN Messenger the other day.  I haven't had access to messenger from work in a long time.  The old version didn't work through our firewall, so I developed a local proxy to tunnel the traffic.  Then they started blocking that traffic outbound.  Then they rolled out a crappy customized version of it to collaborate in-house which couldn't go outside the firewall.  But this web-based one works perfectly through the firewall, so I am once again available while at work...within reason of course.

Last night, I upgraded to XP service pack 2.  It went very smoothly.  The new wireless networking support is fantastic.  I can finally unload the annoying software that came with the laptop to manage the networks.

I'm a little dissapointed with the firewall.  It adds a few new features, but still doesn't seems as configurable as I'd like.  We'll see...some more time with it may change my mind.

It was a very simple, smooth install.  I would let any of my family or friends attempt it by themselves, and probably will.