Infinities Loop

Google Chrome - Aw, Snap!

InfinitiesLoop — Thu, 04 Sep 2008 05:32:37 GMT

Plenty of people have already seen this... interesting... error screen in chrome. I wanted to see what a run-away script would do to Chrome. There's always a warning that the script is taking too long, giving you a chance to shut it down. Here's what...(read more)

Visual Studio Tip: Disable F1!

InfinitiesLoop — Fri, 18 Jul 2008 20:35:34 GMT

Lately I've been using a laptop more often than a desktop to work in Visual Studio, and of course like most laptop keyboards, the keys are jammed close together. The most annoying thing I keep doing by mistake is hitting F1 instead of Escape, which of...(read more)

My Latest Work

InfinitiesLoop — Wed, 18 Jun 2008 04:18:48 GMT

Sky Lynn Reed's 0th birthday is 5/15/2008 at 5:44pm, when she weighed 8 pounds, 0 ounces. A nice round binary number. Our first born! There are simply no words to describe the experience. We debated on whether we should have kids for a long time. After...(read more)

Flickering UI From the ASP.NET AJAX Toolkit TabContainer while in an UpdatePanel?

InfinitiesLoop — Wed, 30 Apr 2008 18:57:00 GMT

UPDATE This issue is officially fixed in .NET 3.5 SP1. If you have applied the workaround in this blog post, you no longer need it. But the story of this bug is still rather interesting. UPDATE If you upgrade from Microsoft ASP.NET AJAX Extensions 1.0...(read more)

TRULY Understanding Dynamic Controls by Example

InfinitiesLoop — Wed, 23 Apr 2008 07:53:17 GMT

Many of the comments I've received in the various dynamic controls entries I've written have been questions for help with a specific scenario. A lot of those scenarios are similar. One in particular I keep hearing is something as follows: The user is...(read more)

OnLoad vs. Page_Load vs. Load event

InfinitiesLoop — Tue, 25 Mar 2008 02:32:00 GMT

I get this question a lot for some reason. The more general question is whether it is better to override a virtual method on the page or control in question (OnLoad, OnInit, OnPreRender, etc), or to hook into the corresponding event . For page development...(read more)

TRULY Understanding ViewState, the comment index

InfinitiesLoop — Wed, 20 Feb 2008 05:23:00 GMT

A long time ago I published one of my first blog entries, TRULY Understanding ViewState . And what an experience it has been. It was pretty popular with commenters, so much so I decided to spin off a whole series of articles, TRULY Understanding Dynamic...(read more)

ASP.NET Futures: Intro to the Xaml and Media Controls

InfinitiesLoop — Tue, 13 Nov 2007 01:46:00 GMT

Still relatively unknown, ASP.NET Futures is a nice little add-on to ASP.NET and ASP.NET AJAX that contains some features we want public feedback on. It's a playground in which technology gets to frolic in front of the public's (your) eyes. So why not seize the opportunity to play with the bits and submit your thumbs up, thumbs down?

I thought I'd give an introduction to two of the controls in ASP.NET Futures that I'm most fond of (I've worked on them, so I'm a little bit partial). If you already know about them, excellent, please log in some feedback.

<asp:Xaml runat="server" />

The Xaml control is an integration story between Silverlight and ASP.NET. If you are writing ASP.NET pages that contain Silverlight content, especially if you are also using AJAX features, it's definitely worth a look. Because it's not only an integration of Silverlight and ASP.NET, but between Silverlight and ASP.NET AJAX. It defines a new client-side ajax type, Sys.Preview.UI.Xaml.Control. So, if you are familiar with ASP.NET and with ASP.NET AJAX, this control gives you a logical extension. Just point the control at a XAML resource, and it wraps an ajax type around Silverlight, giving you a familiar and object-oriented asp.net ajax programming model to work with the surface area between the HTML page and the Silverlight plugin instance.

Take a look at a Calculator implemented using the Xaml control.

<asp:Media runat="server" />

I said it is object oriented, and it is. The media control defines another client-side ajax type which derives from the first: Sys.Preview.UI.Xaml.Media.Player. When this type wraps a Silverlight plug-in, it does a lot of work to it, searching within the Xaml document for elements of certain predetermined names like "PlayButton", and makes them more than just a pretty Canvas by adding behavior to them implied by their name. It may seem trivial, but there are a lot of subtle things that must happen to make what is essentially static markup (the xaml) behave like a full-blown media player. Silverlight makes it look pretty. The Media control brings it to life.

Not just a black box

When you watch video on a web page, you probably don't expect much in the way of interaction between the video and the page. The video is like a rich island in the middle of boring HTML, and never the twain shall meet. Even the orientation of the video is pretty much fixed -- ever seen a movie playing on a webpage at at 15 degree angle? I haven't. I'm not sure I want to, but I sure haven't!

But it doesn't have to be that way... The media control exposes some pretty cool client-side APIs in the form of properties and events that allow for some really interesting interaction between the media and the rest of the page. asp:Media... Tearing down walls!

Take a look at some of the cool things you can do with it.

Not just for fun, either

The Media control can work with any Xaml. It's very forgiving with which Xaml elements it requires, too. What? Your Xaml doesn't have a MuteButton? Ok, no problem. But it does have a WizzyWigDoSomethingButton -- well, it doesn't know what that is, but a client-side type you create that derives from the media player's client side type knows what to do with it.

The only element required is the MediaElement. Yeah you kind of need that one...

You get the picture. But what most people don't know, even those who use it, is that the client-side code that drives the Media control has already appeared in many places. So many, in fact, that if you've seen video playing in Silverlight, you've probably executed the code. The code was joint developed and is shared by the Expression Encoder product, which allows you to export videos to html for execution in Silverlight. It too creates nice media player functionality in Silverlight... and it does it using the exact same code the Media control uses. Well, the namespace is different. But that's it.

Here are some examples of sites using the Media control's client-side ajax type. Note how vastly different they look and behave -- a testament to Silverlight and this control.

Halo 3 on MSN
The Silverlight Learning Videos
Silverlight on Microsoft.com
The Channel 8 and Channel 9 Video Players
(hear about this one here. Favorite quote, "It seems almost too easy...")
James Clarke's Weblog

So there you have it. If you want to play video or audio on your site using Silverlight, and you don't want to implement an entire media player UI from scratch, have a look-see.

EDIT: Hey, my first post tagged "Silverlight". Expect more in the future.

Migraine m = (Migraine) DiagnosisFactory.Diagnose(pain)

InfinitiesLoop — Tue, 06 Nov 2007 02:51:00 GMT

I've struggled with pretty bad headaches probably ever since high school. They come and go with intensity and frequency. Sometimes I think I have them figured out. Eat right, and before I get starving, get enough sleep, and they usually leave me alone. But stressful times, like long business trips or big presentations, or other matters, can easily prompt one. I've grown so used to them that I always make sure I have a supply of Excedrin nearby. There's a bottle at home, up and down stairs, at work, even in the car for those unexpected times. I even have family members be sure to have a stock if I know I'll be visiting for an extended period of time.

For whatever reason, Excedrin seems to be the only thing that helps. Nothing else even touches my headaches. But sometimes, on rare occasions, even Excedrin fails. Today was one of those times.

Bad enough that I finally went to a doctor about it (I was lucky to get a walk-in appointment). After describing all my symptoms, sure enough, these Excedrin-immune headaches are the migraine variety.

If you've had a migraine, I need not explain how terrible they are. If you're one of the lucky ones who don't get them, well, for me they on par with a really bad hangover.

There are lots of options these days for dealing with them. The key is preventing them by understanding what triggers them for you. I've lived with them all my life so far because they crept up on me. I never thought they were migraines because descriptions I read of them seem much more severe than what I have. Indeed I do seem to be luckier than most migraine sufferers -- they are bad, but not so bad that I must lock myself in a dark room for two days. Just thought I'd share my experience -- I'm sure lots of you can relate!

Perhaps this is one sub-conscious reason why I prefer The Dark Side of Visual Studio. The bright light of the normal color scheme is just too overpowering.

Understanding what Page.RegisterRequiresPostBack does

InfinitiesLoop — Thu, 25 Oct 2007 17:35:00 GMT

I recently received a comment in my Truly Understanding ViewState article about the "ArrayList of controls in the control hierarchy that need to be explicitly invoked by the page class during the raise postback event stage of the life cycle." Such is the 3rd entry in the master Triplet that makes up ViewState as a whole.

It was a very excellent question, and in some quick searches I don't see any really clear topics dedicated to answering it, so I decided to answer it with a blog post rather than bury it at the bottom of 100 comments. You can read the comment here.

Page.RegisterRequiresPostBack

To understand why this method is needed, lets walk through what happens when you use an ImageButton.

When you click on an html element of the <input type=image> variety, what is added to the form collection sent to the server is not what a normal button sends. A normal button sends the key/value pair "id=value". But an image submit sends "id.x=##&id.y=##". It sends 2 values, the x and y coordinates of the location of the image you clicked.

This means the KEY of the submission will not match the ID of the control. Normally, ASP.NET matches keys to their control IDs, and is able to find the control directly with FindControl() (which also has the indirect effect of calling EnsureChildControls). But it won't find a control named "id.x" or "id.y", so that ImageButton will never be notified of the postback data it generated.

All is not lost! RegisterRequiresPostBack comes the rescue. It tells asp.net to notify the control of postback data regardless of whether the form collection contains an entry for it. ImageButton can now happily look for "id.x" and "id.y" in the form data, and raise its click event if it is found.

Now why is there a list of controls that call RegisterRequiresPostBack in ViewState of all places? Because when you call RegisterRequiresPostBack, you're doing so for the next request not the current one. You're saying, "when what I'm rendering right now is posted back, I want to be notified." So ASP.NET needs to maintain the list of controls in ViewState so it can do so on the next request.

Some people have complained that even when they disable ViewState for the entire page, they see ViewState in their page. This is one of the reasons for that. It is simply required for the controls to function, it cannot be turned off.

The humble CheckBox

Another control the calls RegisterRequiresPostBack is the humble CheckBox control. When you post a form, any checked checkboxes are added to the form collection with "id=value". However, and quite unfortunately if you ask me, unchecked checkboxes add NOTHING to the form collection.

Ok -- so a CheckBox knows it is checked if its post data key exists, and unchecked if it is missing, right? Nope, sorry, that simply won't do. What would happen to a checkbox that is first created during a postback? For example, a checkbox within a databound control that has just been databound? How does that CheckBox know whether it is unchecked or has just been born into the world, err, page? The only way to know the difference is RegisterRequiresPostBack. If not for that, all checkboxes first created during postbacks would always start off unchecked, even if they were databound or declared to be checked.

Homework

Open up reflector and find the Page.RegisterRequiresPostBack method. Use the analyzer to find all the controls that call it. Try to understand why each of them needs it. I assure you, they all have good but distinct reasons.

Response.Redirect into a new window (with Extension Methods)

InfinitiesLoop — Tue, 25 Sep 2007 18:01:00 GMT

This question comes up from time to time, to time. If you understand how redirects work, then you also know it is "not possible" to redirect into a new window, because a redirect on the server causes a special HTTP response to be sent to the users browser, the client. The browsers native implementation interprets the special response code and sends the user off to the destination. There's no built-in mechanism or standard for specifying a new window.

The only way to open a new window is for it to be initiated on the client side, whether it be through script or clicking on a link.

So the solution always proposed to this problem is to instead write out some script that opens the window, rather than using Response.Redirect:

<script type="text/javascript">

    window.open("foo.aspx");

</script>

Ok... so first you lecture me about how it is "not possible", and then you give me the code that makes it possible. Why can't I just redirect to a new window -- I don't care how HTTP works or client this or server that. There's obviously a solution, so why do I have to worry about it?

(The make-believe developers in my head are always quite temperamental)

It's easy enough to write a little helper that abstracts the details away from us... while we're at it, we might as well add 'target' and 'windowFeatures' parameters. If we're going to open the new window with script, why not let you use all of the window.open parameters? For example, with 'windowFeatures' you can specify whether the new window should have a menu bar, and what its width and height are.

public static class ResponseHelper {

    public static void Redirect(string url, string target, string windowFeatures) {

        HttpContext context = HttpContext.Current;

        if ((String.IsNullOrEmpty(target) ||

            target.Equals("_self", StringComparison.OrdinalIgnoreCase)) &&

            String.IsNullOrEmpty(windowFeatures)) {

            context.Response.Redirect(url);

        else {

            Page page = (Page)context.Handler;

            if (page == null) {

                throw new InvalidOperationException(

                    "Cannot redirect to new window outside Page context.");

            url = page.ResolveClientUrl(url);

            string script;

            if (!String.IsNullOrEmpty(windowFeatures)) {

                script = @"window.open(""{0}"", ""{1}"", ""{2}"");";

            else {

                script = @"window.open(""{0}"", ""{1}"");";

            script = String.Format(script, url, target, windowFeatures);

            ScriptManager.RegisterStartupScript(page,

                typeof(Page),

                "Redirect",

                script,

                true);

Now you just call ResponseHelper.Redirect, and it figures out how to honor your wishes. If you don't specify a target or you specify the target to be "_self", then you must mean to redirect within the current window, so a regular Response.Redirect occurs. If you specify a different target, like "_blank", or if you specify window features, then you want to redirect to a new window, and we write out the appropriate script.

One nice side effect of this "do you really need a new window?" detection is that it's dynamic. Say the destination you redirect to is configurable by some administrator. Now they can decide whether it opens in a new window or not. If they don't want it to they can specify blank or _self as the target.

Disclaimers:

Note: If you use it outside the context of a Page request, you can't redirect to a new window. The reason is the need to call the ResolveClientUrl method on Page, which I can't do if there is no Page. I could have just built my own version of that method, but it's more involved than you might think to do it right. So if you need to use this from an HttpHandler other than a Page, you are on your own.

Note: Beware of popup blockers.

Note: Obviously when you are redirecting to a new window, the current window will still be hanging around. Normally redirects abort the current request -- no further processing occurs. But for these redirects, processing continues, since we still have to serve the response for the current window (which also happens to contain the script to open the new window, so it is important that it completes).

Extension Methods

Recently, Eilon and Bertrand blogged about a novel use of some C# 3.0 features. Eilon posed the question, "Have you come up with a novel way to use a new language feature that you'd like to share?". Well here you go.

Extension Methods are a new feature in C# 3.0 (you'll need it for the rest of the article). They allow you to add methods to existing types, imported via a 'using' statement. I've seen a lot of debate over their use -- whether they are bad or good. Well -- I don't know, I don't really want to be involved in that debate. But I do know that in some scenarios they seem to fit perfectly. Like all language tools, you should use it sparingly and only when appropriate. I believe even the dreaded GOTO statement, which yes, exists in C#, has its place (I wasn't a believer originally, but some old coworkers of mine convinced me (Bob!)).

In this case, an extension method seems to work well. In general, whenever you find yourself writing a static Helper class whose only purpose in life is to help use the APIs of another type, it's probably a great candidate for extension methods. Especially if the first parameter to all those methods is the type you're trying to help with -- or if the methods always grabs the instance through some static API (like HttpContext.Current) or instantiates a new one.

By rewriting our ResponseHelper to use extension methods...

public static class ResponseHelper {

    public static void Redirect(this HttpResponse response,

        string url,

        string target,

        string windowFeatures) {

        if ((String.IsNullOrEmpty(target) ||

            target.Equals("_self", StringComparison.OrdinalIgnoreCase)) &&

            String.IsNullOrEmpty(windowFeatures)) {

            response.Redirect(url);

        else {

            Page page = (Page)HttpContext.Current.Handler;

            if (page == null) {

                throw new InvalidOperationException(

                    "Cannot redirect to new window outside Page context.");

            url = page.ResolveClientUrl(url);

            string script;

            if (!String.IsNullOrEmpty(windowFeatures)) {

                script = @"window.open(""{0}"", ""{1}"", ""{2}"");";

            else {

                script = @"window.open(""{0}"", ""{1}"");";

            script = String.Format(script, url, target, windowFeatures);

            ScriptManager.RegisterStartupScript(page,

                typeof(Page),

                "Redirect",

                script,

                true);

Note the 'this' keyword in the first parameter. Now whenever we include the namespace this class is defined within, we get a nice override on the actual Response object.

Simply including a 'using' to a namespace is what gets extensions methods to show up. So it's probably a good idea to keep extension methods isolated to their own namespaces, lest someone get more than they bargained for when they use your namespace.

Also worth noting is that this is still a static API, so you can use it the traditional way, too. You just have to pass in the Response object as the first parameter.

And to see it in action...

Response.Redirect("popup.aspx", "_blank", "menubar=0,width=100,height=100");

Rendering ASP.NET Controls out of place

InfinitiesLoop — Wed, 19 Sep 2007 15:00:00 GMT

Two posts back I discussed a technique you can use to render controls in an order other than how they are physically arranged in the control tree. A reader, Winston Fassett, posted a comment asking for some advice on how to get a control to render into...(read more)

Inline Script inside an ASP.NET AJAX UpdatePanel

InfinitiesLoop — Mon, 17 Sep 2007 23:29:00 GMT

When you wrap content with an UpdatePanel, it pretty much takes care of everything for you. But it can't do absolutely everything... Take for example some inline script: < p > Some html before the script </ p > < script type = "text/javascript...(read more)

Rendering ASP.NET Controls out of order

InfinitiesLoop — Fri, 07 Sep 2007 22:48:00 GMT

I receive a lot of comments and emails stemming from my series of articles on understanding the nuances of dealing with dynamic controls . It's interesting that so many of these requests revolve around very similar problems. One such theme is where you...(read more)

TRULY Understanding Dynamic Controls (Part 4)

InfinitiesLoop — Tue, 04 Sep 2007 23:50:00 GMT

Part 4 of my series on Truly Understanding Dynamic Controls in ASP.NET. This part covers two of the major scenarios in which you may be loading controls or user controls dynamically, and some of the posting, viewstate, and ID related issues you have probably ran into....(read more)