Jeff Cranford's Blog

Disasters caused by programming errors.

jeffc — Mon, 05 Jun 2006 16:59:00 GMT

Haven't seen this anywhere else....

This is a list of programming errors which ended up causing fairly major disasters (loss of life, billion dollar losses, etc) including an in-depth description of the cause of the error. Puts those "returned licences" that periodically (albeit rarely ;) ) result from my errors in perspective.

http://www.ima.umn.edu/~arnold/disasters/disasters.html

and more here:

http://www5.in.tum.de/~huckle/bugse.html

Great 'retro' web interface.

jeffc — Wed, 22 Mar 2006 13:32:00 GMT

I recently checked out the website for The Raconteurs (a "supergroup" made up of Jack White, Brendon Benson, and two other guys), and they've done their website up in old school terminal style interface (in Flash) complete with keyboard navigation. I like it!

http://www.theraconteurs.com/

Web 2.0 people...don't forget your Ajax prehistory!!!

jeffc — Tue, 07 Mar 2006 17:10:00 GMT

In a short time, Ajax has gone from a little known technology to a full-blown Internet phenomenon. In fact, the term "Ajax" has become so ubiquitous that it has all but encompassed the predecessors to which Ajax owes it's existance. I felt it was important to document the people who carried the torch through the dark ages of callback technology....way back in the day when "Ajax" was known as "remote scripting" and before the XmlHttp object was available in most browsers (forcing callback enthusiasts had to make due with Applet and hidden IFRAME callbacks) .

Microsoft Remote Scripting for ASP (yes, I already have waxed poetic about Microsoft's place in Ajax history)
Brent Ashley's JSRS (http://www.ashleyit.com/rs/main.htm). Quite possibly the most important pre-Ajax callback site.
Thycotic Remote Scripting library (http://www.thycotic.com/dotnet_remotescripting_client.html). Based on Brent Ashley's work, and the first non-MS attempt at a server library to manage "callbacks/remote scripting/Ajax/insert your buzzword here".

If I've forgotten anyone (which I'm sure is quite possible), please let me know.

And, not to be too self serving (well...ok...maybe a little self-serving), the "Ajax" library I wrote (PowerWEB LiveControls for ASP.NET) predated "Ajax" by 6 months.

Google Base and hypocricy

jeffc — Thu, 17 Nov 2005 15:50:00 GMT

Ok, I realize this is my second straight blog about the unfair treatment Microsoft receives from the media & public. However, I feel compelled to point out the hypocricy.

Recently, Google Base (a free ad posting service) went public, and in doing so, continued their recent trend of abusing "standards" that Microsoft has traditionally been accused of violating, but without the usual backlash Microsoft receives.

"Borrowing" ideas pioneered by other companies (since 1995, craigslist.org has gained a large following pushing forward a "grass roots" approach to web sales, marketing, and communication)
Using their dominance of the market to crush smaller, weaker competition (good luck craigslist)
Changing standards

Yeah, before you ask, I'm biased. Anyway, back to coding.

The most innovative browser, please step forward (...not so fast FireFox)

jeffc — Wed, 26 Oct 2005 23:35:00 GMT

Wow! Its mind boggling sometimes how quickly misinformation can spread across the web...especially when said information has an anti-Microsoft sentiment.

Recently, a customer sent my company an article entitled "New Web Software a Challenge to Microsoft" (http://news.yahoo.com/s/ap/20051023/ap_on_hi_te/software_on_the_web). Within 24 hours, this article had spread to thousands of sites, including the CNN home page.

For those that haven't read it yet, I must warn you before you do. Don't bother with the grain of salt...go ahead and eat a whole box of it. For those who are interested, let me summarize. Essentially, the article states that Ajax provides a level of application responsiveness not seen before on the web. This application responsiveness makes it possible to port applications which mimic traditional Microsoft "powerhouse" applications such as Office in functionality to the web. This, in turn, is a threat to Microsoft. To quote one of the article's sources, product manager Alexei White, "[Ajax] definitely supports a Microsoft exit strategy". While I agree that Ajax is a good way to create extremely responsive web applications, I certainly disagree that this is in any way a negative development for Microsoft.

Before I go on, I must point out that the article has several glaring technical inaccuracies and terminology confusions which make it rather clear that the writer is writing from more of a layman perspective. These technical inaccuracies are ultimately forgivable. After all, in the software industry (and especially Ajax), the difference between accurate and inaccurate is subtle and often confused by seasoned developers. However, even this aside, what can not be left alone is the inference that Ajax represents a "threat" to Microsoft.

In reference to Ajax, one point has to be made (and is only briefly mentioned in the article). The history/development of "Ajax" is nearly completely thanks to Microsoft. To illustrate this, let's examine the history of Ajax (source: my recollection combined with some USENET archive searches...ok not exactly hard evidence but anyone is welcome to point out any inaccuracies they find :).

Major milestones in the life of "Ajax"

1997 - Microsoft releases a development methodology called "remote scripting". (By the way, there is VERY LITTLE DIFFERENCE between Ajax and remote scripting, which was created almost 9 YEARS PRIOR to Ajax. They both involve making an out-of-band request to a webserver to acquire some small part of data for the purpose of client-side use. The initial Microsoft library used a Java Applet as the object which made the asynchronous request. Also around this time, some clever developers figured out a way to do a similar out-of-band request using a hidden IFRAME element).
1999 - Microsoft, seeing the limitations in tying the "remote scripting" technology to a dying & insecure technology (Java Applets) introduces the XmlHttpRequest object in IE5 as a future replacement for it. In 6 years, this is to become one of the major callback workhorses in most Ajax libraries.
2000 - Mozilla becomes the second major browser engine to support this technology by adding their version of the XmlHttpRequest object.
2001 - Microsoft uses "remote scripting" techniques in Outlook Web Access (4 years before Gmail).
2005 - In February, Gmail and Google Maps begin to enter the public consciousness as hugely successful applications.
2005 - A few weeks following this, the developer of the applications coins the acronym "Ajax" for the underlying technology of these applications.
2005 - Opera finally adds XmlHttp support as a result of the success of Gmail and Google Maps.

One is hard pressed to find many examples of where this technology wasn't pushed forward by Microsoft. In fact, Microsoft often pushed this technology to the derision of the Internet populace in general. When remote scripting was introduced, there were complaints of security holes, proprietary technology, etc. When they introduced the XmlHttp object, the same complaints resurfaced, as well as allegations of being more concerned about introducing new technology than properly implementing W3C standards. (http://en.wikipedia.org/wiki/Features_of_Internet_Explorer).

Now that we have traced the historic milestones up to today, I could see how one could accept this brief history and still say "Well, they may have pioneered what became Ajax, but they did not capitalize on it TODAY and, much like Frankenstein's monster, it now stands poised to destroy them." (Ok, forgive the literary license I took there. You get the idea).

Well, that's a fair point, if it were true. Unfortunately, it isn't. The brief history written above highlights a calculated plan by Microsoft to achieve exactly what we are seeing right now with Ajax. For the past 10 years, while thousands of companies have come and gone, Microsoft was truly shaping the course of the world wide web by changing the browser from a simple text renderer to a complex application host. How do we know this was their intention? Well, Bill Gates said it himself in 1999 (http://www.microsoft.com/billgates/speeches/09-15devdays.asp).

"But at the heart of this is a new generation of applications, applications that run on a server, but take advantage of the rich capabilities of all the PCs and other devices that are out there. And Microsoft's success has always been keyed off of providing developers with tools to build the best applications. And so, in this new age of Internet applications, we're taking all of our developer pieces, and advancing them to make it as easy as possible to build these applications."
~ Sept 1999

And now that the "revolution" is started, no company is in better position to capitalize on these types of applications:

Ajax applications, since they are counter to the typical HTTP request/response protocol, can be extremely complex to write. Microsoft has put forward the only serious development platform (Visual Studio .NET) to create this level of application.
ASP.NET 2.0 provides built-in "Ajax" support to any server control created in the library.
With Atlas, Microsoft has created a sophisticated Ajax framework implementation.

So, while these new companies fight to capitalize on a market (Office) that Microsoft dominated for the past 15 years, Microsoft has been busy laying the groundwork for what will be the next generation of Internet innovations. Ajax is no threat to Office or Microsoft in general. There are free Office suites out there (OpenOffice) and a myriad of free web-based Word & Excel equivalents and yet Office still does very well. To quote Scott Guthrie in the aforementioned article:

"Ultimately when you want to write a word processing document or manage a large spreadsheet, you are going to want the capabilities ... that are very difficult to provide on the Web today."

Design-time server control persistence.

jeffc — Thu, 29 Sep 2005 21:16:00 GMT

Usually, I am curious about any aspect of web development, but design-time WebForm stuff I am pretty happy to be ignorant of unless absolutely necessary. Well, that happened today, and since I couldn't find much info on this particular subject, I thought I would share for anyone else who has this problem.

The problem was basically this. When a property of our server control was modified at design-time, tons of extra, non-changed properties were persisted as server tag attributes as well. As an example, take my fake control Blah which has three properties.

Blah.Color1 (type: System.Drawing.Color, default value: Color.Empty)
Blah.Color2 (type: System.Drawing.Color, default value: Color.Empty)
Blah.Color3 (type: System.Drawing.Color, default value: Color.Empty)

If, in the designer, I changed Color1 to Color.Red, my server tag might persist like so:

<cc1:Blah id="Blah1" runat="server" Color1="Red" Color2="" Color3="" />

when it should have persisted like so:

<cc1:Blah id="Blah1" runat="server" Color1="Red" />

Yes, the difference is trivial, and won't hurt execution at all, but it is annoying, and does cause a bit of additional, redundant code to execute...especially in the case of my actual control, where this was occurring for 50+ attributes.

The actual class that performs the translation of set properties to persisted server tags is the ControlPersister class in the System.Web.UI.Design namespace (in ASP.NET 1.1 and previous versions anyway...see below for 2.0). To simplify a bit, the design time execution invokes the static ControlPersister.PersistControl method, which takes care of querying the properties of the control, using the specified TypeConverter and PersistenceMode attribute for each propery to construct the string representation. You can even call this yourself, for example:

   TextBox tb = new TextBox();
   tb.ID = "mytextbox";
   tb.BackColor = Color.Red;
   string controlText = System.Web.UI.Design.ControlPersister.PersistControl(tb);
   System.Diagnostics.Debug.WriteLine(controlText);

outputs "<System.Web.UI.WebControls.TextBox runat="server" BackColor="Red" ID="mytextbox"></System.Web.UI.WebControls.TextBox>" as one might expect.

So, what decides which properties are persisted as attributes? Playing around a bit with the ControlPersister class, I began to get a better idea of the behavior. For my specific case, there were two major property attributes that controlled whether or not ControlPersister includes the property's value in the persisted text.

DesignerSerializationVisibilityAttribute - When set to Hidden, the property is never included in tag persistence.
DefaultValueAttribute - When the value of the property differs from what is specified here, it is included in tag persisted..

Adding this to the knowledge about tag persistence that I already had, namely:

PersistenceModeAttribute - Controls if the property is persisted as a top level attribute or an inner node.
ParseChildrenAttribute - Determines whether nested tags are treated as properties or child controls.
PersistChildrenAttribute - Defines whether or not to persist children at design time.

and eventually I resolved the situation.

For ASP.NET 2.0, it looks like this changes a bit. Some of the ControlPersister.PersistControl overloads are removed, and it uses the internal ControlsSerializer class to perform the grunt work....but generally the attributes mentioned above still behave the same way (as far as I know at least...someone let me know if I'm off base here).

Creating a dynamic ProgressBar server control

jeffc — Mon, 19 Sep 2005 13:55:00 GMT

I wrote this for an ASP.NET portal, but they didn't use it. So, to the blog it goes.

A progress bar…in a web application?

Sure, it’s possible. In fact, progress bars have been in use for about as long as server-side programming has existed. Typically, however, these are meta-refresh based progress bars. These are the progress bars that use the tag to send a request to the server every X seconds to get the updated visual representation of the bar. Sure, it works, but results in a “white out” screen refresh (which looks clunky) and does not allow “interactive” progress (meaning that the progress bar can be modified in server-side code and it is immediately displayed in the browser without a refresh). It IS possible to achieve this effect however, by leveraging the “old school” ASP Response.Write() method.

Most Microsoft web developers are familiar with the Response.Write() method, which adds data to the response stream. This method has been superseded for most functionality in ASP.NET, but we will revive it for our progress bar. The great thing about using Response.Write() is it causes the data to be sent immediately to the browser (unless Response.Buffer is true, in which case Response.Flush() has to be called as well to force the data to be sent immediately to the browser). This is not the case when using common ASP.NET techniques (such as Label.Text = “hello”;), in which case the data is not sent to the client until the rendering part of the Page execution cycle, when RenderContents is recursively called on all child controls.

So, how is it Response.Write() used? First, on a postback, a long process that requires progress is started. Then, the initial progress bar structure is sent to the client using Response.Write, but the response is not terminated. Each time the progress bar needs to be extended, a bit of javascript is sent to the browser to extend the bar. When the long process is complete, the response is finally terminated. The result is a single loooooooooooooooooong response.

Creating the server control

The server control, since it provides a user interface, will derive from the .NET Framework class System.Web.UI.WebControls.WebControl. This base class will provide extended UI support for our control such as design time behavior, style support, etc.

using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.ComponentModel;
using System.Drawing;
using System.Text;

namespace Blah
{
    public class ProgressBar : System.Web.UI.WebControls.WebControl
   {
   }
}

Following the standard Windows forms ProgressBar, it will only add three properties onto the properties derived from WebControl.

• Minimum – The minimum value of the progress bar (typically 0)
• Maximum – The maximum value of the progress bar
• Value – The current value of the Progress

The Minimum and Maximum properties are pretty simple, just saving/restoring the value to/from ViewState in the get/set accessor.

public int Minimum
{
   get
  {
     object o = ViewState["minimum"];
     return (o == null) ? 0 : (int)o;
  }
set
{
     ViewState["minimum"] = value;
   }
}

public int Maximum
{
   get
   {
      object o = ViewState["maximum"];
      return (o == null) ? 100 : (int)o;
    }
    set
    {
       ViewState["maximum"] = value;
    }
}

The Value property is a little more complex. Since the user will be setting this property in their code, and expecting the visual update to occur immediately in the browser, special action is required when the property is set.

This special action is as follows. On the first set of the property, the basic progress bar structure is drawn. The _ProgressBarDrawn flag controls this. Then, on each subsequent set, the progress bar is visually updated. When complete, the Value property should look something like the following:

// Flag to monitor whether the progress bar has been drawn
private bool _ProgressBarDrawn = false;

public int Value
{
   get
   {
      object o = ViewState["value"];
      return (o == null) ? 0 : (int)o;
    }
    set
    {
       ViewState["value"] = value;
       if(!_ProgressBarDrawn)
          DrawProgressBar();
       UpdateProgress();
     }
}

So, what is in the DrawProgressBar() and UpdateProgress() functions? The DrawProgressBar() function is only called once per request (thus the previously discussed flag) to write out the initial progress bar structure. This content is immediately sent to the browser to be displayed.

private void DrawProgressBar()
{
    Page.Response.Write("<html><body>");
   Page.Response.Write(ControlStyle.ToString());
   Page.Response.Write("<div id='divProgress' ");
   Page.Response.Write("style='WIDTH:" + GetAdjustedValue() + ";");
   Page.Response.Write("HEIGHT:" + Height.ToString() + ";");
   Page.Response.Write("BACKGROUND-COLOR:" + ColorTranslator.ToHtml(BackColor) + "'>");
   Page.Response.Write("</div>");

   // Flush the output to the browser if required.
   if(this.Page.Response.Buffer) this.Page.Response.Flush();

// Set the flag so the progress bar is not redrawn
_ProgressBarDrawn = true;

}

The UpdateProgress() function is called each time Value is set to write out some JavaScript to change the width of the div element created above to the current value. This is also flushed immediately to the browser.

private void UpdateProgress()
{
    // Write out the JavaScript to extend the bar.
   Page.Response.Write("<script language='JavaScript'>\r\n");
    Page.Response.Write("document.getElementById('divProgress').style.width = '" + GetAdjustedValue() + "';\r\n");
   Page.Response.Write("</scr");
   Page.Response.Write("ipt>\r\n");

// Flush the output to the browser.
if(this.Page.Response.Buffer) this.Page.Response.Flush();
}

As you can see, both of these functions call a helper function called GetAdjustedValue(). This simply returns the proper value to use for the current progress bar width based on Value, Width, Maximum, and Minimum.

private Unit GetAdjustedValue()
{
   int range = Maximum - Minimum;
   double ratio = (((double)Value)/((double)range));
   int adjustedValue = (int)(Width.Value * ratio);
   return new Unit(adjustedValue);
}

Anything else? Yep, we have to override the Render method to suppress the default ASP.NET rendering of the control. Since we are doing our own rendering at run time (when the Value property is set, above), the ASP.NET rendering is redundant, and will seriously mess up the UI.

protected override void Render(HtmlTextWriter writer)
{
}

Why can’t we just render all of the HTML within the Render() method (or RenderContents() method)? Well, as explained above, the progress bar updates visually each time Value is set, so the appropriate JavaScript needs to be sent immediately when Value is set. The Render method is not invoked by the ASP.NET runtime until much later in page cycle, so it is too late to send the HTML at that time. Yes, this is a hack and outside of the expected ASP.NET Page Cycle, but by nature a ProgressBar is contrary to a typical HTTP request/response cycle.

That’s it. Once all of the above properties and methods are in your server control class, you’re done. Compile the server control dll.

Testing the server control

Now create a simple little ASP.NET app to test the control. First create a new WebForm in your favorite development environment, and drag an instance of our control on the form (note, you will not see a visual representation of the control on the design surface, as we did not associate a Designer with the control class. More on this in the “Extending the server control” section below). Also, add a standard ASP.NET button to the WebForm. In the Page.Load event, add the following code to configure the progress bar.

private void Page_Load(object sender, System.EventArgs e)
{
   // Configure the ProgressBar
   ProgressBar1.Minimum = 0;
   ProgressBar1.Maximum = 100;
   ProgressBar1.BackColor = Color.Blue;
   ProgressBar1.Height = new Unit(20);
   ProgressBar1.Width = new Unit(200);
}

Also, within the Button.Click event, add the following code to test the progress. Typically you would do something that would require actual progress (such as a file transfer, database query, webservice call, etc). To keep this sample simple, we will simply loop 100 times, pausing each iteration to simulate some process that takes time.

private void Button1_Click(object sender, System.EventArgs e)
{
    // Simulate a process that requires progress
    for(int i=0; i<100; i++)
   {
      // Set the ProgressBar.Value
     ProgressBar1.Value = i;
      System.Threading.Thread.Sleep(20);
   }
}

Compile and run. Click the button. You should see some progress happening!

Why, when I set other style properties (such as BorderColor, etc) it doesn’t show up?

Recall how non-standard rendering techniques were used each time the Value property was set. If we were using the standard technique of putting all of the rendering code within the RenderContents() method, style attributes would be automatically applied (but the dynamic, interactive progress would no longer work). Since we are replacing the built-in rendering logic with our own, we have to also write the logic to handle style application. This is demonstrated in the DrawProgressBar() method, when BackColor, Height, and Width are used to set up the initial progress bar. It would be just as easy to check if BorderColor (and other style properties) were set and modify the rendered HTML to account for these properties.

Extending the server control.

For the sake of brevity, this server control code is kept as simple as possible. However, with a couple of additions (using the techniques demonstrated above) a professional quality product could be achieved.

• As mentioned in the section above, write the logic to account for all WebControl styles (BackColor, BorderColor, CssClass, etc).
• Create a ControlDesigner class so you can provide a better design-time representation of the control.
• Add a Text property containing text that can be updated in real time just like the Value property.
• Add a “segmented progress” mode in addition to the “smooth progress” mode.

Server Control to Server Control data sharing

jeffc — Tue, 19 Jul 2005 20:44:00 GMT

Recently, I had to implement an in-page communication system between custom server controls. Essentially, all controls had to have access to a shared property at any point in the Page life cycle INCLUDING design-time. So, when this shared property changes for one control, all other controls must reflect the same value. There are three basic scenarios to be concerned with when implementing server control to server control communication.

So, to simpify things, lets just say my server control (called “MyControl”) has a property called “Blah“ which, when set, has to update the “Blah“ properties of all other “MyControls“ on the page.

At run time - post Page_Load:

This is the simplest scenario. After Page_Load, the page control heirarchy has been constructed, so any control can easily access another control either by transversing the Parent/Controls property, or by simply using FindControl.

public object Blah
{
   get
   {
      return ViewState["Blah"];
   }
   set
   {
      ViewState["Blah"] = value;

      // Now update all controls on the Page
      // This code assumes that Page_Load has already executed, so the control heirarchy has been constructed.
      ArrayList controls = GetAllControls(this, null);
      foreach(Control c in controls)
         ((MyControl)c).Blah = value;
   }
}

private ArrayList GetAllControls(Control startControl, ArrayList controls)
{
   if(controls == null) controls = new ArrayList();
   foreach(Control c in startControl.Controls)
   {
      // Add the control if it is the same type
      if(c is MyControl && (!c.Equals(this)))
         controls.Add(c);
      GetAllControls(c, controls);
   }
   return controls;
}

Using this technique, as long as the control heirarchy has been created, one could easily find all appropriate controls on the Page, and update the shared member when needed.

At run time - pre Page_Load:

This scenario is a little more difficult, as the page control heirarchy has not been constructed, so the above technique wouldn't work. No control on the Page has guarenteed access to any other control on the Page. However, one could use the Page.Context object, which exists for the lifetime of each control, to store the shared value for Blah. The only technical hurdle is that the server control does not have access to the Page.Context, as it is Protected. You could get around this by using reflection.

public object Blah
{
   get
   {
      // Get the Page context using Reflection
      HttpContext context = (HttpContext)Page.GetType().GetProperty("Context", (BindingFlags)36).GetValue(Page, null);
      return context.Items["Blah"];
   }
   set
   {
      // Get the Page context using Reflection
      HttpContext context = (HttpContext)Page.GetType().GetProperty("Context", (BindingFlags)36).GetValue(Page, null);
      context.Items["Blah"] = value;
   }
}

Now, all of the MyControls on the Page are reading/writing to the same value, so there is no reason to do the explicit update like in the first example. In fact, since this technique works both in pre-Page_Load and post-Page_Load, it more or less supercedes technique #1. So we can just use it instead.

At design time:

This is the most difficult scenario to deal with, as Page.Context is null at design-time, so the above technique won't work. However, Page.ViewState is not null, so shared items can be stored there. And, because these items are only stored in ViewState during design time, the values wont be persisted to the actual ViewState when the page is executed.

public object Blah
{
   get
   {
      // Get the Page context using Reflection
      HttpContext context = (HttpContext)Page.GetType().GetProperty("Context", (BindingFlags)36).GetValue(Page, null);

      // Check if context is not null
      if(context != null) return context.Items["Blah"];

      // Context is null, it must be design time.
      // Get the Page ViewState using Reflection
      StateBag viewState = (StateBag)Page.GetType().GetProperty("ViewState", (BindingFlags)36).GetValue(Page, null);
      return viewState["Blah"];
   }
   set
   {
      // Get the Page context using Reflection
      HttpContext context = (HttpContext)Page.GetType().GetProperty("Context", (BindingFlags)36).GetValue(Page, null);

      // Check if context is not null
      if(context != null) context.Items["Blah"] = value;

      // Context is null, it must be design time.
      // Get the Page ViewState using Reflection
      StateBag viewState = (StateBag)Page.GetType().GetProperty("ViewState", (BindingFlags)36).GetValue(Page, null);
      viewState["Blah"] = value;
   }
}

Not a perfect solution. For one, ViewState persistence is lost with the final example, so that has to be dealt with...but that's easy enough and the goal has been met.

Pushing callback technology to the limit. LivePaint (Part I).

jeffc — Fri, 10 Jun 2005 21:48:00 GMT

I wanted to try to see how close to “real-time” my company's “callback-enabled“ LiveControls could come in terms of communication with the server. It occurred to me that a cross-browser web paint application would be a great test of this feature. Here were the specs of the test application:

Must be cross browser compatible (basically just IE and Firefox for the purposes of this test).
Must be ran across the Internet (it is too easy to do across a local network) without extensive lagging.
User can draw on the canvas with the pencil.
User can switch colors.

Yeah, a pretty simple paint app, but enough to test. I felt that this would be a perfect test because (1) It would have to use the MouseMove event, which is probably the most often raised client-side event (although I have no stats to back this statement up) and (2) because even the slightest lag whatsoever would be detectable by the user. To my knowledge, there is no current application which is able to achieve all of the above using cross browser DHTML. I did find one fantastic JavaScript library which is able to draw shapes such as ovals and other curves at http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm. The developer used a pretty ingenious strategy of using 1 X 1 DIV elements to represent pixels (and even went so far as to join consecutive DIVS where possible to reduce the number of client side HTML elements used). Unfortunately, this strategy is too “client-heavy“ to make an effective paint program.

Here is a description of the basic architecture:

A LiveImage comprises the canvas.
The mousemove event over the image accumulates mouse coords.
A LiveTimer periodically updates the server with the new mouse coord data (60 milliseconds is the default I used)
Within the LiveTimer.Tick event, a new canvas .gif file is created from the mouse coord data using System.Drawing namespace and stored in the Session.
The LiveImage.ImageUrl property is set to the new url.
An HttpHandler receives the request for the new image.
The image is retrieved from the session and streamed back out to the browser.

So, how successful was I? You tell me (although you probably could guess I wasn't terribly successful since this blog post is titled “LivePaint Part I“). An online version can be reached at http://www.dart.com/livepaint/canvas.aspx. If you want to see the code, it can be downloaded from http://www.dart.com/livepaint/livepaint.zip (you also need the PowerWEB LiveControls for ASP.NET developers kit available at http://www.dart.com/powerweb/livecontrols.asp to run the sample)

I see two problems with my sample so far:

Since the line is not a bezier curve, but a non-related plotting of pixels, the line looks choppy and often has gaps.
There is a very noticeable lag.

So, expect LivePaint Part II very shortly. I'll keep working through this until I get some decent results.

Swag at Tech-Ed 2005!

jeffc — Thu, 09 Jun 2005 11:18:00 GMT

What happens to us when we get into a conference setting? Here I am, a grown adult, father, husband, going up to another adult and meekly saying "Hey, what do you have to do to get one of those weeble-wobble business card holders?".

One company had a large stage on which a gentleman was giving a presentation. Periodically, he would pause and prompt the audience, to which they would yell something like "Kill Spam Dead!" (or something like that). I'm sure when designing this promo, they envisioned riotous mobs...fists pumping in the air, screaming "KILL SPAM DEAD!". Unfortunately, the actual effect was three or so of the audience, mumbling the phrase at a scarcely audible level.

Another booth was giving away 1 dollar bills for badge scans. I happened to walk by this booth while talking with a Microsoft guy. He said to the guy running the booth "No thanks, I don't reach out for money." I had to agree. I mean, if a dollar fell from the sky and happened to land in my hand, I certainly wouldn't throw it away, but definitely not worth the effort of getting scanned and getting the whole sales spiel.

There were two pieces of swag that I actually did want. One was a "Hitchhiker's Guide style" t-shirt from Red-Gate (by the way, their ANTS code profiler is a really great product). I managed to get one of these. The other was a Microsoft shirt with the Linux penguin being shot "shooting gallery" style. Unfortunately, they ran out of this one...so no luck for me :(

[Added June 9]

Well, spoke too soon. I happened to mention the “KILL SPAM DEAD” guy to our company CEO, and he ended up using the idea at his presentation at the Partner's Theater. Not sure if he had better results than the Spam guy though.

JavaScript on demand!

jeffc — Thu, 09 Jun 2005 01:17:00 GMT

A few months ago, my company released a new product (LiveControls for ASP.NET) that we periodically find a new use for that was not in the original design. To save you a trip to the website, this product is a suite of server controls which use callback technology to raise events on the server. Within the event, you can set properties on other LiveControls on the page, which is converted to JavaScript and shipped back to the client where it is executed. As a result, the request and response are significantly smaller, the DOM does not need to be recreated on the client-side with each request, and there is no UI disruption. Think of it as an AJAX where you don't have to write any JavaScript whatsoever.

So today at Tech-Ed, my boss coined the phrase “JavaScript on demand” as one of the selling points while describing our product. It hadn't occurred to me prior to this point (I was much more interested in the speed and seamlessness of the UI updates). Basically, when the page initially loads, it contains no JavaScript whatsoever. As the user interacts with the page, and JavaScript is needed to perform some DHTML magic, the intrepid callback mechanism is transparently sent to the server to retrieve ONLY the JavaScript required, and it is immediately executed.

Feeling in a metaphoric mood, I threw out this gem. “The current system is like when a plumber comes to your house to fix your sink, and first empties the entire contents of the van into a big pile the kitchen. He looks at the sink, grabs a wrench, and fixes the sink, whereas with our product the plumber only brings the wrench out of the van.“

Well, not 100% accurate (I don't think I've ever said “whereas“ in conversation) but the general gist. Anyway, it really uncovered a powerful feature I hadn't thought of. The page interaction is as efficient as possible... with faster downloads (since no unneeded JavaScript is sent to the user) and less client resource consumption (since it doesn't have to parse and cache a large JavaScript file). Of course I was always aware of this happening, I hadn't considered it purely from a client-side resource consumption aspect.

Anyway, from now on I'll just pretend that this was in the design of the product since day 1.