Followers of the IHttpHandler

Half-day talk about ASP.NET Whidbey

Note: this entry has moved.

If you happen to be anywhere near Buenos Aires, Argentina next Thursday  then don’t miss my “Presentación de ASP.NET Whidbey” talk, a 4-full hour talk about what’s new in ASP.NET Whidbey. It should be lots of fun, I promise :-)

Where: Microsoft Argentina HQ

When: 26^th, Feb, 2004 (9AM – 1PM)

You can register online here.

PS. I’ll be speaking in spanish :-O

The Worst Named Operator, Ever

Note: this entry has moved.

Although I try harder and harder to remember of any such misleading operator name used before I can’t find one. Without any doubt, the writers of ECMA-262 (the ECMAScript Language Specification) win the top prize by using the “delete” name for the operator in charge of deleting a property from an object and removing elements from an array.

What exactly were they thinking about when they choose this name?

C’mon guys... you already know there is an operator named delete in other languages with a totally different behavior, don’t you?

remove? removeExpando? removeElement? clearSomething? *Anything* would have been better than delete.

Handling styles in your custom control

Note: this entry has moved.

My previous post didn’t stress enough the main point I was trying to make (I should have entitled it differently I believe). I’m posting again, this time hoping to make it clear.

I already know you can write all kind of hacks (as Cazzu and Jason have suggested in the comments) to actually make the Calendar output the styles you want. But the intention of my previous post was not exactly to show how to overcome Calendar’s current bugs. Note that I didn’t even mentioned the approach we finally took to replace the background color of each day’s cell, which –btw– didn’t required a single line of code (bets are open…).

I was far more interested in showing what the Calendar was doing wrong with the hope that all controls developers out there could learn from this and avoid such a mistake when coding their own controls. So, let’s recap, what was the lesson learned from looking at Calendar’s inner workings?

Never, ever, ever, apply any default styles if a CssClass is specified (you know you don’t want to override the page developer settings with your own defaults).

(Does the bolded text help now?)

Also, the fact that this bug has made its way from v1.0 to Everett and it’s now about to make it to Whidbey troubles me a bit. I know… I know... it’s just the Calendar control (anyone out there using it?) but the fix doesn’t seem to be hard at all so it would be great to see this finally fixed.

Calendar's buggy style handling

Note: this entry has moved.

Antonio, the lead for the graphics design team that’s working on a side project of mine told me today that they weren’t able to get the built-in <asp:Calendar> to work with a css file.

“No problem, let me take a look at it and I will get back to you in 5” was my initial response. After all what can be so difficult about the Calendar? They’re graphics designers with some light training on ASP.NET and not developers, so they must be missing something obvious.

I wrote a simple test page containing a Calendar and included a css file. Ctrl+F5. No luck. The Calendar was rendering whatever it wanted instead of the styles defined in the css file. Revised the aspx file, revised the css. Ctrl+F5. Still no luck.

I google for Calendar’s known bugs but couldn't find much. Moreover, everybody seems to be having the same problems. Time for Reflector.

After a little browsing, I first ended up in Calendar.RenderTitle. In this method a TableCell is being created and applied some default styles:

Afterwards, the ApplyTitleStyle method is called to apply to the cell and containing table the TitleStyle that was declaratively specified in the aspx; it will also assign the CssClass property (if one was specified):

This means that if you have specified in your aspx something like this (which -by the way- makes perfect sense as you’re avoiding the harcoding of styles into the aspx itself):

You’re *really* out of luck. Why? Because BackColor was set to Color.Silver by default and its going to make it to the rendered html:

As you can see the inline style will override our defined myCalendarStyle style and we won’t be able to get our custom background color, never, ever, ever. The only option left is to hardcode it into the aspx:

Now, we get our background color rendered properly:

This is because the previously mentioned ApplyTitleStyle method checked for the specified style and properly applied it to the cell thus overriding the default silver one. Of course this solution is not acceptable unless you’re willing to hardcode styles all over the aspx. Sad.

Even worse is the fact that this bug is not only present in the ApplyTitleStyle method, i.e. the RenderCalendarCell method likes to hardcode a color: black for every rendered cell if no hardcoded color was specified into the aspx. Hello?! I don’t want to hardcode styles into the aspx, that’s why I’m using a css file in the first place!

The morale of the story (and where the bug resides) is:

Don’t ever, ever, ever apply any default styles if a CssClass property is specified. Why? Because that’s rude. I want *my* styles to get rendered and not default ones.

PD1: Of course my initial estimation of 5 minutes to solve the problem was under-estimated by only 300%.

PD2: I just checked the Whidbey bits and this bug is still there :-(