Rick Strahl's Web Log

DevConnections Slides and Samples Posted

Rick Strahl — Wed, 18 Nov 2009 12:54:20 GMT

I’ve posted the slides and samples to my DevConnections Sessions for anyone interested. I had a lot of fun with my sessions this time around mainly because the sessions picked were a little off the beaten track (well, the handlers/modules and e-commerce sessions anyway). For those of you that attended I hope you found the sessions useful. For the rest of you – you can check out the slides and samples if you like. Here’s what was covered:

Introduction to jQuery with ASP.NET

This session covered mostly the client side of jQuery demonstrated on a small sample page with a variety of incrementally built up examples of selection and page manipulation. This session also introduces some of the basics of AJAX communication talking to ASP.NET. When I do this session it never turns out exactly the same way and this time around the examples were on the more basic side and purely done with hands on demonstrations rather than walk throughs of more complex examples. Alas this session always feels like it needs another half an hour to get through the full sortiment of functionality. The slides and samples cover a wider variety of topics and there are many examples that demonstrate more advanced operations like interacting with WCF REST services, using client templating and building rich client only windowed interfaces.

Download

Low Level ASP.NET: Handlers and Modules

This session was a look at the ASP.NET pipeline and it discusses some of the ASP.NET base architecture and key components from HttpRuntime on up through the various modules and handlers that make up the ASP.NET/IIS pipeline. This session is fun as there are a number of cool examples that demonstrate the power and flexibility of ASP.NET, but some of the examples were external and interfacing with other technologies so they’re not actually included in the downloadable samples. However, there are still a few cool ones in there – there’s an image resizing handler, an image overlay module that stamps images with Sample if loaded from a certain folder, an OpenID authentication module (which failed during the demo due to the crappy internet connection at DevConnections this year :-}), Response filtering using a generic filter stream component, a generic error handler and a few others. The slides cover a lot of the ASP.NET pipeline flow and various HttpRuntime components.

Download

Electronic Payment Processing in ASP.NET Applications

This session covered the business end and integration of electronic credit card processing and PayPal. A good part of this session deals with what’s involved in payment processing, getting signed up and who you have to deal with for your merchant account. We then took a look at integration of credit card processing via some generic components provided with the session that allow processing using a unified class interface with specific implementations for several of the most common gateway providers including Authorize.NET, PayFlowPro, LinkPoint, BluePay etc. We also briefly looked at PayPal Classic implementation which provides a quick and cheap if not quite as professional mechanism for taking payments online. The samples provide the Credit Card processing wrappers for the various gateway providers as well as a PayPal helper class to generate the PayPal redirect urls as well as helper code for dealing with IPN callbacks.

Download

Hope some of you will find the material useful. Enjoy.

Posted in ASP.NET

Capturing and Transforming ASP.NET Output with Response.Filter

Rick Strahl — Fri, 13 Nov 2009 17:47:39 GMT

During one of my Handlers and Modules session at DevConnections this week one of the attendees asked a question that I didn’t have an immediate answer for. Basically he wanted to capture response output completely and then apply some filtering to the output – effectively injecting some additional content into the page AFTER the page had completely rendered. Specifically the output should be captured from anywhere – not just a page and have this code injected into the page.

Some time ago I posted some code that allows you to capture ASP.NET Page output by overriding the Render() method, capturing the HtmlTextWriter() and reading its content, modifying the rendered data as text then writing it back out. I’ve actually used this approach on a few occasions and it works fine for ASP.NET pages. But this obviously won’t work outside of the Page class environment and it’s not really generic – you have to create a custom page class in order to handle the output capture.

[updated 11/16/2009 – updated ResponseFilterStream implementation and a few additional notes based on comments]

Enter Response.Filter

However, ASP.NET includes a Response.Filter which can be used – well to filter output. Basically Response.Filter is a stream through which the OutputStream is piped back to the Web Server (indirectly). As content is written into the Response object, the filter stream receives the appropriate Stream commands like Write, Flush and Close as well as read operations although for a Response.Filter that’s uncommon to be hit. The Response.Filter can be programmatically replaced at runtime which allows you to effectively intercept all output generation that runs through ASP.NET.

A common Example: Dynamic GZip Encoding

A rather common use of Response.Filter hooking up code based, dynamic GZip compression for requests which is dead simple by applying a GZipStream (or DeflateStream) to Response.Filter. The following generic routines can be used very easily to detect GZip capability of the client and compress response output with a single line of code and a couple of library helper routines:

WebUtils.GZipEncodePage();

which is handled with a few lines of reusable code and a couple of static helper methods:

/// <summary>
///Sets up the current page or handler to use GZip through a Response.Filter
///IMPORTANT:
///You have to call this method before any output is generated!
/// </summary>
public static void GZipEncodePage()
{
    HttpResponse Response = HttpContext.Current.Response;

    if(IsGZipSupported())
    {
        stringAcceptEncoding = HttpContext.Current.Request.Headers["Accept-Encoding"];
        if(AcceptEncoding.Contains("deflate"))
        {
            Response.Filter = newSystem.IO.Compression.DeflateStream(Response.Filter,
                                       System.IO.Compression.CompressionMode.Compress);
            Response.AppendHeader("Content-Encoding", "deflate");
        }
        else
       {
            Response.Filter = newSystem.IO.Compression.GZipStream(Response.Filter,
                                      System.IO.Compression.CompressionMode.Compress);
            Response.AppendHeader("Content-Encoding", "gzip");
        }
    }

    // Allow proxy servers to cache encoded and unencoded versions separately
   Response.AppendHeader("Vary", "Content-Encoding");
}

/// <summary>
/// Determines if GZip is supported
/// </summary>
/// <returns></returns>
public static bool IsGZipSupported()
{
    string AcceptEncoding = HttpContext.Current.Request.Headers["Accept-Encoding"];
    if (!string.IsNullOrEmpty(AcceptEncoding) &&
         (AcceptEncoding.Contains("gzip") || AcceptEncoding.Contains("deflate")))
        return true;
    return false;
}

GZipStream and DeflateStream are streams that are assigned to Response.Filter and by doing so apply the appropriate compression on the active Response.

Response.Filter content is chunked

So to implement a Response.Filter effectively requires only that you implement a custom stream and handle the Write() method to capture Response output as it’s written. At first blush this seems very simple – you capture the output in Write, transform it and write out the transformed content in one pass. And that indeed works for small amounts of content. But you see, the problem is that output is written in small buffer chunks (a little less than 16k it appears) rather than just a single Write() statement into the stream, which makes perfect sense for ASP.NET to stream data back to IIS in smaller chunks to minimize memory usage en route.

Unfortunately this also makes it a more difficult to implement any filtering routines since you don’t directly get access to all of the response content which is problematic especially if those filtering routines require you to look at the ENTIRE response in order to transform or capture the output as is needed for the solution the gentleman in my session asked for.

So in order to address this a slightly different approach is required that basically captures all the Write() buffers passed into a cached stream and then making the stream available only when it’s complete and ready to be flushed.

As I was thinking about the implementation I also started thinking about the few instances when I’ve used Response.Filter implementations. Each time I had to create a new Stream subclass and create my custom functionality but in the end each implementation did the same thing – capturing output and transforming it. I thought there should be an easier way to do this by creating a re-usable Stream class that can handle stream transformations that are common to Response.Filter implementations.

Creating a semi-generic Response Filter Stream Class

What I ended up with is a ResponseFilterStream class that provides a handful of Events that allow you to capture and/or transform Response content. The class implements a subclass of Stream and then overrides Write() and Flush() to handle capturing and transformation operations. By exposing events it’s easy to hook up capture or transformation operations via single focused methods.

ResponseFilterStream exposes the following events:

CaptureStream, CaptureString
Captures the output only and provides either a MemoryStream or String with the final page output. Capture is hooked to the Flush() operation of the stream.
TransformStream, TransformString
Allows you to transform the complete response output with events that receive a MemoryStream or String respectively and can you modify the output then return it back as a return value. The transformed output is then written back out in a single chunk to the response output stream. These events capture all output internally first then write the entire buffer into the response.
TransformWrite, TransformWriteString
Allows you to transform the Response data as it is written in its original chunk size in the Stream’s Write() method. Unlike TransformStream/TransformString which operate on the complete output, these events only see the current chunk of data written. This is more efficient as there’s no caching involved, but can cause problems due to searched content splitting over multiple chunks.

Using this implementation, creating a custom Response.Filter transformation becomes as simple as the following code.

To hook up the Response.Filter using the MemoryStream version event:

ResponseFilterStream filter = new ResponseFilterStream(Response.Filter);
filter.TransformStream += filter_TransformStream;
Response.Filter = filter;

and the event handler to do the transformation:

MemoryStream filter_TransformStream(MemoryStream ms)
{
    Encoding encoding = HttpContext.Current.Response.ContentEncoding;
    
    string output = encoding.GetString(ms.ToArray());

    output = FixPaths(output);
    
    ms = new MemoryStream(output.Length);

    byte[] buffer = encoding.GetBytes(output);
    ms.Write(buffer,0,buffer.Length);

    return ms;
}

private string FixPaths(string output)
{
    string path = HttpContext.Current.Request.ApplicationPath;


    // override root path wonkiness
    if (path == "/")
        path = "";

    output = output.Replace("\"~/", "\"" + path + "/").Replace("'~/", "'" + path + "/");
    return output;
}

The idea of the event handler is that you can do whatever you want to the stream and return back a stream – either the same one that’s been modified or a brand new one – which is then sent back to as the final response.

The above code can be simplified even more by using the string version events which handle the stream to string conversions for you:

ResponseFilterStream filter = new ResponseFilterStream(Response.Filter);
filter.TransformString += filter_TransformString;
Response.Filter = filter;

and the event handler to do the transformation calling the same FixPaths method shown above:

string filter_TransformString(string output)
{
    return FixPaths(output);
}

The events for capturing output and capturing and transforming chunks work in a very similar way. By using events to handle the transformations ResponseFilterStream becomes a reusable component and we don’t have to create a new stream class or subclass an existing Stream based classed.

By the way, the example used here is kind of a cool trick which transforms “~/” expressions inside of the final generated HTML output – even in plain HTML controls not HTML controls – and transforms them into the appropriate application relative path in the same way that ResolveUrl would do.

So you can write plain old HTML like this:

<a href=”~/default.aspx”>Home</a>

and have it turned into:

<a href=”/myVirtual/default.aspx”>Home</a>

without having to use an ASP.NET control like Hyperlink or Image or having to constantly use:

<img src=”<%= ResolveUrl(“~/images/home.gif”) %>” />

in MVC applications (which frankly is one of the most annoying things about MVC especially given the path hell that extension-less and endpoint-less URLs impose).

I can’t take credit for this idea. While discussing the Response.Filter issues on Twitter a hint from Dylan Beattie who pointed me at one of his examples which does something similar. I thought the idea was cool enough to use an example for future demos of Response.Filter functionality in ASP.NET next I time I do the Modules and Handlers talk (which was great fun BTW).

How practical this is is debatable however since there’s definitely some overhead to using a Response.Filter in general and especially on one that caches the output and the re-writes it later. Make sure to test for performance anytime you use Response.Filter hookup and make sure it' doesn’t end up killing perf on you. You’ve been warned :-}.

How does ResponseFilterStream work?

The big win of this implementation IMHO is that it’s a reusable component – so for implementation there’s no new class, no subclassing – you simply attach to an event to implement an event handler method with a straight forward signature to retrieve the stream or string you’re interested in.

The implementation is based on a subclass of Stream as is required in order to handle the Response.Filter requirements. What’s different than other implementations I’ve seen in various places is that it supports capturing output as a whole to allow retrieving the full response output for capture or modification. The exception are the TransformWrite and TransformWrite events which operate only active chunk of data written by the Response.

For captured output, the Write() method captures output into an internal MemoryStream that is cached until writing is complete. So Write() is called when ASP.NET writes to the Response stream, but the filter doesn’t pass on the Write immediately to the filter’s internal stream. The data is cached and only when the Flush() method is called to finalize the Stream’s output do we actually send the cached stream off for transformation (if the events are hooked up) and THEN finally write out the returned content in one big chunk.

Here’s the implementation of ResponseFilterStream:

/// <summary>
/// A semi-generic Stream implementation for Response.Filter with
/// an event interface for handling Content transformations via
/// Stream or String.    
/// <remarks>
/// Use with care for large output as this implementation copies
/// the output into a memory stream and so increases memory usage.
/// </remarks>
/// </summary>    
public class ResponseFilterStream : Stream
{
    /// <summary>
    /// The original stream
    /// </summary>
    Stream _stream;

    /// <summary>
    /// Current position in the original stream
    /// </summary>
    long _position;

    /// <summary>
    /// Stream that original content is read into
    /// and then passed to TransformStream function
    /// </summary>
    MemoryStream _cacheStream = new MemoryStream(5000);

    /// <summary>
    /// Internal pointer that that keeps track of the size
    /// of the cacheStream
    /// </summary>
    int _cachePointer = 0;


    /// <summary>
    /// 
    /// </summary>
    /// <param name="responseStream"></param>
    public ResponseFilterStream(Stream responseStream)
    {
        _stream = responseStream;
    }


    /// <summary>
    /// Determines whether the stream is captured
    /// </summary>
    private bool IsCaptured
    {
        get 
        {

            if (CaptureStream != null || CaptureString != null ||
                TransformStream != null || TransformString != null)
                return true;

            return false;
        }
    }

    /// <summary>
    /// Determines whether the Write method is outputting data immediately
    /// or delaying output until Flush() is fired.
    /// </summary>
    private bool IsOutputDelayed
    {
        get 
        {
            if (TransformStream != null || TransformString != null)
                return true;

            return false;
        }        
    }
    

    /// <summary>
    /// Event that captures Response output and makes it available
    /// as a MemoryStream instance. Output is captured but won't 
    /// affect Response output.
    /// </summary>
    public event Action<MemoryStream> CaptureStream;

    /// <summary>
    /// Event that captures Response output and makes it available
    /// as a string. Output is captured but won't affect Response output.
    /// </summary>
    public event Action<string> CaptureString;

    

    /// <summary>
    /// Event that allows you transform the stream as each chunk of
    /// the output is written in the Write() operation of the stream.
    /// This means that that it's possible/likely that the input 
    /// buffer will not contain the full response output but only
    /// one of potentially many chunks.
    /// 
    /// This event is called as part of the filter stream's Write() 
    /// operation.
    /// </summary>
    public event Func<byte[], byte[]> TransformWrite;


    /// <summary>
    /// Event that allows you to transform the response stream as
    /// each chunk of bytep[] output is written during the stream's write
    /// operation. This means it's possibly/likely that the string
    /// passed to the handler only contains a portion of the full
    /// output. Typical buffer chunks are around 16k a piece.
    /// 
    /// This event is called as part of the stream's Write operation.
    /// </summary>
    public event Func<string, string> TransformWriteString;

    /// <summary>
    /// This event allows capturing and transformation of the entire 
    /// output stream by caching all write operations and delaying final
    /// response output until Flush() is called on the stream.
    /// </summary>
    public event Func<MemoryStream, MemoryStream> TransformStream;

    /// <summary>
    /// Event that can be hooked up to handle Response.Filter
    /// Transformation. Passed a string that you can modify and
    /// return back as a return value. The modified content
    /// will become the final output.
    /// </summary>
    public event Func<string, string> TransformString;


    protected virtual void OnCaptureStream(MemoryStream ms)
    {
        if (CaptureStream != null)
            CaptureStream(ms);
    }


    private void OnCaptureStringInternal(MemoryStream ms)
    {
        if (CaptureString != null)
        {
            string content = HttpContext.Current.Response.ContentEncoding.GetString(ms.ToArray());
            OnCaptureString(content);
        }
    }

    protected virtual void OnCaptureString(string output)
    {
        if (CaptureString != null)
            CaptureString(output);
    }

    protected virtual byte[] OnTransformWrite(byte[] buffer)
    {
        if (TransformWrite != null)
            return TransformWrite(buffer);
        return buffer;
    }

    private byte[] OnTransformWriteStringInternal(byte[] buffer)
    {
        Encoding encoding = HttpContext.Current.Response.ContentEncoding;
        string output = OnTransformWriteString(encoding.GetString(buffer));
        return encoding.GetBytes(output);
    }

    private string OnTransformWriteString(string value)
    {
        if (TransformWriteString != null)
            return TransformWriteString(value);
        return value;
    }


    protected virtual MemoryStream OnTransformCompleteStream(MemoryStream ms)
    {
        if (TransformStream != null)
            return TransformStream(ms);

        return ms;
    }




    /// <summary>
    /// Allows transforming of strings
    /// 
    /// Note this handler is internal and not meant to be overridden
    /// as the TransformString Event has to be hooked up in order
    /// for this handler to even fire to avoid the overhead of string
    /// conversion on every pass through.
    /// </summary>
    /// <param name="responseText"></param>
    /// <returns></returns>
    private string OnTransformCompleteString(string responseText)
    {
        if (TransformString != null)
            TransformString(responseText);

        return responseText;
    }

    /// <summary>
    /// Wrapper method form OnTransformString that handles
    /// stream to string and vice versa conversions
    /// </summary>
    /// <param name="ms"></param>
    /// <returns></returns>
    internal MemoryStream OnTransformCompleteStringInternal(MemoryStream ms)
    {
        if (TransformString == null)
            return ms;

        //string content = ms.GetAsString();
        string content = HttpContext.Current.Response.ContentEncoding.GetString(ms.ToArray());

        content = TransformString(content);
        byte[] buffer = HttpContext.Current.Response.ContentEncoding.GetBytes(content);
        ms = new MemoryStream();
        ms.Write(buffer, 0, buffer.Length);
        //ms.WriteString(content);

        return ms;
    }

    /// <summary>
    /// 
    /// </summary>
    public override bool CanRead
    {
        get { return true; }
    }

    public override bool CanSeek
    {
        get { return true; }
    }
    /// <summary>
    /// 
    /// </summary>
    public override bool CanWrite
    {
        get { return true; }
    }

    /// <summary>
    /// 
    /// </summary>
    public override long Length
    {
        get { return 0; }
    }

    /// <summary>
    /// 
    /// </summary>
    public override long Position
    {
        get { return _position; }
        set { _position = value; }
    }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="offset"></param>
    /// <param name="direction"></param>
    /// <returns></returns>
    public override long Seek(long offset, System.IO.SeekOrigin direction)
    {
        return _stream.Seek(offset, direction);
    }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="length"></param>
    public override void SetLength(long length)
    {
        _stream.SetLength(length);
    }

    /// <summary>
    /// 
    /// </summary>
    public override void Close()
    {
        _stream.Close();
    }

    /// <summary>
    /// Override flush by writing out the cached stream data
    /// </summary>
    public override void Flush()
    {

        if (IsCaptured && _cacheStream.Length > 0)
        {
            // Check for transform implementations
            _cacheStream = OnTransformCompleteStream(_cacheStream);
            _cacheStream = OnTransformCompleteStringInternal(_cacheStream);
            
            OnCaptureStream(_cacheStream);
            OnCaptureStringInternal(_cacheStream);

            // write the stream back out if output was delayed
            if (IsOutputDelayed)
                _stream.Write(_cacheStream.ToArray(), 0, (int)_cacheStream.Length);

            // Clear the cache once we've written it out
            _cacheStream.SetLength(0);
        }

        // default flush behavior
        _stream.Flush();
    }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="buffer"></param>
    /// <param name="offset"></param>
    /// <param name="count"></param>
    /// <returns></returns>
    public override int Read(byte[] buffer, int offset, int count)
    {
        return _stream.Read(buffer, offset, count);
    }


    /// <summary>
    /// Overriden to capture output written by ASP.NET and captured
    /// into a cached stream that is written out later when Flush()
    /// is called.
    /// </summary>
    /// <param name="buffer"></param>
    /// <param name="offset"></param>
    /// <param name="count"></param>
    public override void Write(byte[] buffer, int offset, int count)
    {
        if ( IsCaptured )
        {
            // copy to holding buffer only - we'll write out later
            _cacheStream.Write(buffer, 0, count);
            _cachePointer += count;
        }

        // just transform this buffer
        if (TransformWrite != null)
            buffer = OnTransformWrite(buffer);
        if (TransformWriteString != null)
            buffer = OnTransformWriteStringInternal(buffer);

        if (!IsOutputDelayed)
            _stream.Write(buffer, offset, buffer.Length);
        
    }

}

The key features are the events and corresponding OnXXX methods that handle the event hookups, and the Write() and Flush() methods of the stream implementation. All the rest of the members tend to be plain jane passthrough stream implementation code without much consequence.

I do love the way Action<t> and Func<T> make it so easy to create the event signatures for the various events – sweet.

A few Things to consider

Performance

Response.Filter is not great for performance in general as it adds another layer of indirection to the ASP.NET output pipeline, and this implementation in particular adds a memory hit as it basically duplicates the response output into the cached memory stream which is necessary since you may have to look at the entire response. If you have large pages in particular this can cause potentially serious memory pressure in your server application. So be careful of wholesale adoption of this (or other) Response.Filters. Make sure to do some performance testing to ensure it’s not killing your app’s performance.

Response.Filter works everywhere

A few questions came up in comments and discussion as to capturing ALL output hitting the site and – yes you can definitely do that by assigning a Response.Filter inside of a module. If you do this however you’ll want to be very careful and decide which content you actually want to capture especially in IIS 7 which passes ALL content – including static images/CSS etc. through the ASP.NET pipeline. So it is important to filter only on what you’re looking for – like the page extension or maybe more effectively the Response.ContentType.

Response.Filter Chaining

Originally I thought that filter chaining doesn’t work at all due to a bug in the stream implementation code. But it’s quite possible to assign multiple filters to the Response.Filter property. So the following actually works to both compress the output and apply the transformed content:

WebUtils.GZipEncodePage();

ResponseFilterStream filter = new ResponseFilterStream(Response.Filter);
filter.TransformString += filter_TransformString;
Response.Filter = filter;

However the following does not work resulting in invalid content encoding errors:

ResponseFilterStream filter = new ResponseFilterStream(Response.Filter);
filter.TransformString += filter_TransformString;
Response.Filter = filter;

WebUtils.GZipEncodePage();

In other words multiple Response filters can work together but it depends entirely on the implementation whether they can be chained or in which order they can be chained. In this case running the GZip/Deflate stream filters apparently relies on the original content length of the output and chokes when the content is modified. But if attaching the compression first it works fine as unintuitive as that may seem.

Resources

Posted in ASP.NET

$.fadeTo/fadeOut() operations on Table Rows in IE fail

Rick Strahl — Mon, 09 Nov 2009 08:20:25 GMT

Here’s a a small problem that one of customers ran into a few days ago: He was playing around with some of the sample code I’ve put out for one of my simple jQuery demos which deals with providing a simple pulse behavior plug-in:

$.fn.pulse = function(time) {
    if (!time)
        time = 2000;

    // *** this == jQuery object that contains selections
    $(this).fadeTo(time, 0.20,
                        function() {                    
                            $(this).fadeTo(time, 1);
                        });

    return this;
}

it’s a very simplistic plug-in and it works fine for simple pulse animations. However he ran into a problem where it didn’t work when working with tables – specifically pulsing a table row in Internet Explorer. Works fine in FireFox and Chrome, but IE not so much. It also works just fine in IE as long as you don’t try it on tables or table rows specifically. Applying against something like this (an ASP.NET GridView):

var sel =
    $("#gdEntries>tbody>tr")
            .not(":first-child")  // no header
            .not(":last-child")   // no footer
            .filter(":even")
            .addClass("gridalternate");

// *** Demonstrate simple plugin
sel.pulse(2000);

fails in IE. No pulsing happens in any version of IE. After some additional experimentation with single rows and various ways of selecting each and still failing, I’ve come to the conclusion that the various fade operations in jQuery simply won’t work correctly in IE (any version). So even something as ‘elemental’ as this:

var el = $("#gdEntries>tbody>tr").get(0);
$(el).fadeOut(2000);

is not working correctly. The item will stick around for 2 seconds and then magically disappear.

Likewise:

sel.hide().fadeIn(5000);

also doesn’t fade in although the items become immediately visible in IE. Go figure that behavior out.

Thanks to a tweet from red_square and a link he provided here is a grid that explains what works and doesn’t in IE (and most last gen browsers) regarding opacity:

http://www.quirksmode.org/js/opacity.html

It appears from this link that table and row elements can’t be made opaque, but td elements can. This means for the row selections I can force each of the td elements to be selected and then pulse all of those. Once you have the rows it’s easy to explicitly select all the columns in those rows with .find(“td”). Aha the following actually works:

var sel =
    $("#gdEntries>tbody>tr")
            .not(":first-child")  // no header
            .not(":last-child")   // no footer
            .filter(":even")
            .addClass("gridalternate");

// *** Demonstrate simple plugin
sel.find("td").pulse(2000);

A little unintuitive that, but it works.

Stay away from <table> and <tr> Fades

The moral of the story is – stay away from TR, TH and TABLE fades and opacity. If you have to do it on tables use the columns instead and if necessary use .find(“td”) on your row(s) selector to grab all the columns.

I’ve been surprised by this uhm relevation, since I use fadeOut in almost every one of my applications for deletion of items and row deletions from grids are not uncommon especially in older apps. But it turns out that fadeOut actually works in terms of behavior: It removes the item when the timeout’s done and because the fade is relatively short lived and I don’t extensively test IE code any more I just never noticed that the fade wasn’t happening.

Note – this behavior or rather lack thereof appears to be specific to table table,tr,th elements. I see no problems with other elements like <div> and <li> items.

Chalk this one up to another of IE’s shortcomings.

Incidentally I’m not the only one who has failed to address this in my simplistic plug-in: The jquery-ui pulsate effect also fails on the table rows in the same way.

sel.effect("pulsate", { times: 3 }, 2000);

and it also works with the same workaround. If you’re already using jquery-ui definitely use this version of the plugin which provides a few more options…

Bottom line: be careful with table based fade operations and remember that if you do need to fade – fade on columns.

Posted in jQuery

ClientIDMode in ASP.NET 4.0

Rick Strahl — Sat, 07 Nov 2009 23:58:03 GMT

One of the more anticipated features of ASP.NET 4.0 – at least for me - is the new ClientIDMode property, which can be used to force controls to generate clean Client IDs that don’t follow ASP.NET’s munged NamingContainer ID conventions. To be clear, NamingContainer IDs are necessary for complex controls and pages that nest many things inside of a single context, but for most application level Web design scenarios those munged IDs get in the way and don’t provide a lot of value.

The munged IDs affect all sorts of development scenarios from design and CSS styling where ID haven’t been predictable for #id styling:

#ctl00_content_txtName 
{
    font-weight: bold;
}

vs the more expected:

#txtName
{
    font-weight: bold;
}

And even more so there’s the whole nightmare of ClientIds in script pages where code like this:

    <script type="text/javascript">
        var txtName = $("<%= txtName.ClientID %>");
        var txtTitle = $("[id$=_txtTitle]");
    </script>

or some other pre-generation code is necessary to get client id’s properly referenced in script code.

ClientIDMode

In prior versions of ASP.NET you had to live with the problem or work around with various hacks. In ASP.NET 4.0 things get a little easier via the new ClientIDMode property which allows you to specify exactly how a ClientID is generated.

The idea is simple: you get a new ClientIDMode property on all ASP.NET controls which can be set either at the actual control or somewhere up the NamingContainer chain. If the ClientIDMode property is not set on a control it inherits the setting from the nearest NamingContainer with the exception of the <asp:Content> placeholder which doesn’t participate in ClientIDMode processing (bummer!).

This means if you choose to you can set ClientIDMode on the Page level and it will trickle down into all the child controls on the page, but a custom naming container like a User Control can still override the ClientIDMode to enforce it’s naming container requirements. It’ll be interesting to see how much existing code might break based on this inheritance scheme as custom controls may lose controls over their ClientID naming if the ClientIDMode property isn’t set explicitly.

Anyway let’s take a look at a very simple example and how the ClientIDMode property affects the ID rendering. Imagine you have a page that uses a master page and is set up like this:

<%@PageTitle=""Language="C#"MasterPageFile="~/Site.Master"AutoEventWireup="true"
       CodeBehind="WebForm2.aspx.cs"
       Inherits="WebApplication1.WebForm2"
        ClientIDMode="Predictable"
%>
<asp:ContentID="content"ContentPlaceHolderID="content"runat="server"ClientIDMode="Static" >
    <asp:TextBox runat="server"ID="txtName"ClientIDMode="Static" />
</asp:Content>

Here’s what the various values for the txtName property can look like:

AutoID

This is the existing behavior in ASP.NET 1.x-3.x where full naming container munging takes place.

<input name="ctl00$content$txtName" type="text" id="ctl00_content_txtName" />

In Beta 2 this is the default value for the Page. According to the latest VS 2010 documentation however, the default behavior by release time will be Predictable.

Static
This option forces the control’s ClientID to use its ID value directly. No naming container naming at all is applied and you end up with clean client ids:

<inputname="ctl00$content$txtName"type="text"id="txtName" />

This option is what most of us want to use, but you have to be clear on that this can potentially cause conflicts with other control on the page. If there are several instances of the same naming container (several instances of the same user control for example) there can easily be a client ID naming conflict. It’s basically up to you to decide whether this is a problem or not.

Note that if you assign Static to a Databound control like a list child controls in templates do not get unique IDs either, so for list controls where you rely on unique Id for child controls you’ll probably want to use Predictable rather than Static. More on this a little later when I discuss ClientIDRowSuffix.

Predictable

The previous two values are pretty self-explanatory. Predictable however, requires some explanation. To me at least it's not in the least bit predictable :-}.
MSDN defines this enum value as follows:

This algorithm is used for controls that are in data-bound controls. The ClientID value is generated by concatenating the ClientID value of the parent naming container with the ID value of the control. If the control is a data-bound control that generates multiple rows, the value of the data field specified in the ClientIDRowSuffix property is added at the end. For the GridView control, multiple data fields can be specified. If the ClientIDRowSuffix property is blank, a sequential number is added at the end instead of a data-field value. Each segment is separated by an underscore character (_).

The key that makes this value a bit confusing is that it relies on the parent NamingContainer’s ClientID to build it’s own client ID value. Which effectively means that the value is not predictable at all but rather very tightly coupled to the parent naming container’s ClientIDMode setting.

For our simple textbox example, if the ClientIDMode property of the parent naming container (Page in this case) is set to “Predictable” you’ll get this:

<input name="ctl00$content$txtName" type="text" id="content_txtName" />

which gives a name that walk up to the currently active naming container (the MasterPage content container) and starts the name from there downward. Think of this as a semi unique name that’s guaranteed unique only for the naming container.

If on the other hand the Page is set to “AutoID” you get with Predicable on txtName:

<input name="ctl00$content$txtName" type="text" id="ctl00_content_txtName" />

The latter is effectively the same as if you specified AutoID in this scenario because it inherits the AutoID naming from the Page and Content control of the page. But again – predictable behavior always depends on the parent naming container and how it generates its id so the ID may not always be exactly the same as the AutoID generated value because somewhere in the NamingContainer chain the ClientIDMode setting may be set to a different value. For example if you had another naming container in the middle that was set to Static you’d end up effectively with an ID that starts with the NamingContainers' ID rather than the whole ctl000_content munging.

The most common use however for Predictable will be for DataBound controls, which results in a each data bound item to get a unique ClientID.

Predictable is useful, but only if all naming containers down the chain use this setting. Otherwise you’re right back to the munged Ids that are pretty unpredictable.

Inherit

The final setting is Inherit which is the default for all controls except Page (AFAIK). This means that controls by default inherit the naming container’s ClientIDMode setting.

Inheritance

The explicit values are pretty obvious in what they do and when they are applied to individual controls. AutoID is classic behavior, Static is what we want in typical client centric apps, and Predictable is what you typically will want to use for list controls and anything that has possible naming conflicts.

Things get a little more tricky with inheritance of these settings. Specicfically the ClientIDMode property inherits from a NamingContainer down. Unlike most other ASP.NET hierarchy inheritance the ClientIDMode inheritance is based on the NamingContainer not on the Parent Container.

What this means is that if you set ClientIDMode="Static" on a Page or MasterPage all controls inherit that settings:

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" 
         CodeBehind="WebForm2.aspx.cs" Inherits="WebApplication1.WebForm2"  
         ClientIDMode="Static" %>

If you don’t set the ClientIDMode on any other controls the entire page will use Static. Any UserControls can override the setting but all controls will use this setting.

Now imagine I do:

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true"
CodeBehind="WebForm2.aspx.cs" Inherits="WebApplication1.WebForm2"
ClientIDMode="Predictable" %>

and I’m running inside of a master page and I put in a block of controls like this:

    <asp:Panel runat="server"  ClientIDMode="Static">
        This is a test:
        <asp:TextBox runat="server" ID="txtName" />
        <asp:Button ID="btnSubmit" runat="server" Text="Go"  />
    </asp:Panel>

Quick what should you see? Unfortunately not what I would have expected – although it’s true to what the documentation advertises. The block above renders into:

<div>
    This is a test:
    <input name="ctl00$content$txtName" type="text" id="content_txtName" />
    <input type="submit" name="ctl00$content$btnSubmit" value="Go" id="content_btnSubmit" />
</div>

What’s happening here is that even though we specified Static naming on the Panel (which is not a NamingContainer) Predictable naming is used which runs up to the nearest naming container – in this case the Master Page Content control and using that as its base for the name. If I want those controls to render with clean ids I need to explicitly mark the controls to use Static:

    <asp:Panel runat="server"  ClientIDMode="Static">
        This is a test:
        <asp:TextBox runat="server" ID="txtName" ClientIDMode="Static" />
        <asp:Button ID="btnSubmit" runat="server" Text="Go" ClientIDMode="Static" />
    </asp:Panel>

or by changing the Page’s ClientIDMode to Static:

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" 
        CodeBehind="WebForm2.aspx.cs" Inherits="WebApplication1.WebForm2"  
        ClientIDMode="Static" %>

With either of those in place I now get:

<div id="Panel1">
        This is a test:
        <input name="ctl00$content$txtName" type="text" id="txtName" />
        <input type="submit" name="ctl00$content$btnSubmit" value="Go" id="btnSubmit" />    
</div>

Notice that when page level ClientIDMode="Static" the <div> tag now renders with an explicit ID which is rather inconsistent (it’s not there if I just have ClientIDMode=”Static” on the Panel alone).

Note that you unfortunately cannot use an <asp:Content> control and specify the ClientIDMode like this:

<asp:Content ID="content" ContentPlaceHolderID="content" runat="server" ClientIDMode="Static">

This has no effect on the controls contained inside of the Content container which still inherit the ClientIDMode from Page in this case. This is really annoying because the Content container certainly is part of the naming container hierarchy that is reflected in the ClientIDName for Predictable and AutoId.

There’s a way around this by using:

Static on the List Control
Predictable on all of the Child controls

This looks like this:

    <asp:GridView runat="server" ID="gvProducts" AutoGenerateColumns="false"
                  ClientIDMode="Static" ClientIDRowSuffix="id"  
                  DataSourceID="xmlDataSource" 
                   >  
                  <Columns>
                    <asp:TemplateField> 
                        <ItemTemplate>
                            <asp:Label runat="server" id="txtTitle" Text='<%# Eval("title") %>' 
                                       ClientIDMode="Predictable"/>
                        </ItemTemplate>
                    </asp:TemplateField>
                    <asp:TemplateField> 
                        <ItemTemplate>
                        <asp:Label runat="server" id="txtId" Text='<%# Eval("id") %>' 
                                   ClientIDMode="Predictable" />
                        </ItemTemplate>
                    </asp:TemplateField>

                  </Columns>  
    </asp:GridView>

which results in:

<table cellspacing="0" rules="all" border="1" id="Table2" style="border-collapse:collapse;">
    <tr>
        <th scope="col">&nbsp;</th><th scope="col">&nbsp;</th>
    </tr><tr>
        <td>
                    <span id="txtTitle_32">West Wind West Wind Web Toolkit</span>
                </td><td>
                <span id="txtId_32">32</span>
                </td>
    </tr>
</table>

This does produce what I would consider a desirable result although I had hoped that using Static on the list control without any further formatting would have produced this result. Unfortunately the Predictable setting on each of the child controls is required to get the clean ids into the child controls.

ClientIDRowSuffix

Another feature of the ClientID improvements in ASP.NET 4.0 is the ClientIDRowSuffix which can be applied to DataBound/List controls. I used it above in the grid to have the enumerated client id of the child controls use the value of an Id field from the database as the enumeration value. This setting basically determines how ID values for template controls in databound controls are generated, but it requires that the ClientIDMode is set to Predictable. It produces:

id="txtTitle_32"

where the _32 in this case comes from the Id of the data source which is nice than only using sequentially numbered values in previous versions of ASP.NET which were often worthless in client situations. Using an actual data value that can be looked retrieved on the client and sent back on an Ajax callback makes these IDs much more useful.

Wouldn’t it be nice if Client Row Ids could be generated?

What would be even nicer is that the generated ‘rows’ of a data bound control could optionally generate ids. In most Ajax situations the row level ID is really what’s useful – selections of rows for deletion, editing and updating always require an ID even if there are no child controls, but ASP.NET doesn’t provide an easy mechanism for embedding row ids. It sure would be get output like this:

    <tr id="content_gvProducts_33">
        ...
    </tr>

This can be done with code in a GridView (and other list controls) with ItemCreated events it’s quite a pain to do this. For example for the gridview I’m using with a simple XmlDataSource control I have to do this:

protected void gvProducts_RowCreated(object sender, GridViewRowEventArgs e)
{
    object dataItem = e.Row.DataItem;

    if (dataItem != null)
    {
        XPathNavigator nav = ((IXPathNavigable)dataItem).CreateNavigator();
        if (nav != null)
            e.Row.Attributes.Add("id", this.gvProducts.ID + "_" + nav.GetAttribute("id",""));
    }
}

to produce output like this:

which is anything but intuitive for such a common scenario (although this IS a bit easier to grab the data if you use Entity list or DataTable binding).

Data List Controls and Static Produces Invalid HTML

One more note: Using Static on list controls with child controls and NOT using Predictable for child controls is problematic as it will generate static IDs for ALL template items:

    <table cellspacing="0" rules="all" border="1" id="Table1" style="border-collapse:collapse;">
        <tr>
            <th scope="col">&nbsp;</th><th scope="col">&nbsp;</th>
        </tr><tr>
            <td>
                            <span id="txtTitle">West Wind West Wind Web Toolkit</span>
                        </td><td>
                        <span id="txtId">32</span>
                        </td>
        </tr><tr>
            <td>
                            <span id="txtTitle">West Wind West Wind Web Store</span>
                        </td><td>
                        <span id="txtId">33</span>
                        </td>
        </tr>
    </table>

This is invalid HTML since there are multiple controls with the same id attribute on the page which is clearly undesirable. To fix this remember to use Predictable on any of the child controls.

Or better yet stay away from server controls altogether in template columns – stick to plain HTML controls and use AJAX to update values to the server more interactively. :-}

How should we use ClientIDMode?

I suspect it’s going to take some time to figure out all the little nuances of the new ClientIDMode features. At the very least the Static option on individual controls allows you to explicitly force controls to use the name you want it to and that’s a win any way you look at it.

For now I think the following is what I want to use in typical page scenarios in my applications:

Add ClientIDMode="Static" to each Page (or in web.config’s <pages> setting)
Add ClientIDMode="Predictable" explicitly to each List Control Children in Databound Template
Override explicitly to Predictable where naming conflicts are a problem and to AutoId for the extreme edge case
For Control Development leave at default behavior if possible (ie. Inherit from parent)
Override only when necessary and preferrably on individual subcontrols

Also for now I think it’s a good idea to EXPLICITLY specify a ClientIDMode on each page (or in your project) or explicitly declare the value in your web.config file:

<pages clientIDMode="Static" />

to ensure you get a predictable setting since the current Beta 2 implementation and the documentation are at odds of what the default value actually is.

It’s funny to think that such simple functionality should cause such complex workarounds and dependent behaviors but I suspect with a consistent regimen of CLientIDMode settings you can achieve output that works for any scenario. Time will tell.

Posted in ASP.NET JavaScript

Ambiguous References in DefaultWsdlHelpGenerator.aspx

Rick Strahl — Tue, 03 Nov 2009 01:52:22 GMT

Here’s a little oddball issue I ran into today that hosed – during a demo of course – all the existing ASMX Web Services text pages in one of my applications. The error that occurred resulted in a yellow screen of death when accessing the ASMX service directly (http://localhost/wwstore/services/WebStoreConsumerService.asmx):

CS0104: 'DataBinder' is an ambiguous reference between 'Westwind.Web.Controls.DataBinder' and 'System.Web.UI.DataBinder'

The issue here is caused by the fact that I have a component in Westwind.Web.Controls.DataBinder that apparently conflicts with the System.Web.UI.DataBinder. You would think that the separate namespaces should isolate me from problems like this, but unfortunately here the overlapping names ram heads due to the use of a static method call of DataBinder.Eval().

The problem is that the DataBinder.Eval() is a static method call so there’s never an instance created to qualify exactly which type is to be used. Both System.Web.UI and Westwind.Web.Controls are in scope, the former because it’s automatically included as a namespace, the latter because it’s added explicitly in the <pages><namespaces> section of Web.Config:

    <pages>
      <namespaces>
        <add namespace="Westwind.Web" />
        <add namespace="Westwind.Web.Controls" />
        <add namespace="Westwind.Utilities" />
        <add namespace="Westwind.WebStore" />
      </namespaces>
      <controls>
        <add assembly="Westwind.Web" namespace="Westwind.Web.Controls" tagPrefix="ww" />
      </controls>
    </pages>

which automatically includes the namespace into the page.

The result is that that the DataBinder.Eval() can’t be resolved properly by the compiler – it doesn’t know which DataBinder should be used. Actually it’d be nice if the compiler was smart enough to check for the actual method Eval before throwing the error. Since my component doesn’t have a static Eval method (or any static members for that matter) it seems that the compiler should be able to prioritize the call.

Ironically this error would not be an issue if this was anything but a framework provided page which is:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\DefaultWsdlHelpGenerator.aspx

To fix the problem is easy enough by changing all the .NET 1.x DataBinder.Eval() calls with:

<%# System.Web.UI.DataBinder.Eval(Container.DataItem, "Value.Documentation") %>

<%# Eval("Value.Documentation") %>

Replacing all DataBinder.Eval instances with either code fixes the problem, but of course it only does so on my machine(s) – still a problem for anybody else.

In the end there are few solutions that can be used to work around this problem – none really satisfying. The easiest and the one I actually ended up with is by removing the Westwind.Web.Controls namespace from the global ASP.NET namespace list:

      <namespaces>
        <add namespace="Westwind.Web" />
        <!--<add namespace="Westwind.Web.Controls" />-->
        <add namespace="Westwind.Utilities" />
        <add namespace="Westwind.WebStore" />
      </namespaces>

It turns out that this works just fine in my case because the Westwind.Web.Controls namespace isn’t used much in Web page code. A while back I thankfully refactored all the utility and control code into separate namespaces, so the need for the Controls namespace is not used much if at all.

The other option I was at first considering to get around this was to put the control into a separate namespace (ie. Westwind.Web.Controls.DataBinding) which certainly would have worked but this causes a number of problems when adding page register commands into the page. The following wouldn’t work:

<%@ Register Assembly="Westwind.Web" Namespace="Westwind.Web.Controls" TagPrefix="ww" %>

unless I also add:

<%@ Register Assembly="Westwind.Web" Namespace="Westwind.Web.Controls.DataBinding" TagPrefix="ww" %>

IOW, changing a lot of pages potentially.

Finally another solution is to add web.config file into the folder with the Web Service(s) and explicitly exclude the offending namespace(s):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web>
    <pages>
      <namespaces>        
        <remove namespace="Westwind.Web.Controls"/>
      </namespaces>
    </pages>
  </system.web>
</configuration>

This assumes you isolate the Web Services into a separate folder.

This is obviously a very isolated incident and situation, but it’s easy to get tripped up by this. Ideally I think that the generic .NET code in DefaultWsdlHelpGenerator.aspx was namespace safe by explicitly prefixing namespaces in static method calls.

There goes another couple of hours of sleuthing to find a solution. <shrug>

Posted in ASP.NET Web Services

No JavaScript IntelliSense in VS 2010 Beta 2? Reset your Settings

Rick Strahl — Thu, 22 Oct 2009 21:52:05 GMT

When I installed Visual Studio 2010 a couple of days ago I was really disappointed to see that JavaScript Intellisense failed to work completely in the new install. No workey in .js files, or ASPX pages inside of script blocks. After some back and forth with folks on the ASPInsiders list and the product teams it looks like there is an issue somewhere with the default settings that get set when Visual Studio 2010 first installs.

This doesn’t affect all installs, but there were handful in a small group of folks, so this is likely going to hit a few of you trying out Visual Studio 2010 as well.

To get Intellisense to work again, thanks to a tip from Luis Abreu, I ended up resetting my Visual Studio settings (Tools | Import and Export Settings):

then go ahead and reset to your preferred default profile (I typically choose the C# profile over the Web profile). This may seem counter intuitive immediately after a new install since I hadn’t changed any settings yet, but the reset did the trick.

And voila, Intellisense in JavaScript is back.

I suspect this has something to do with VS 2010 importing some existing VS 2008 settings, so even if you don’t have problems in VS 2010 it might be a good idea to actually reset all settings just to make sure there’s a clean slate to start with.

Hope this helps out some of you.

Other JavaScript Editor Thoughts

One nice feature that will be quite useful is support for CodeSnippet Expansion in JavaScript, which means you can automate common tasks with keyboard expansions. Since there’s no CodeRush for VS 2010 yet and I keep typing my CR shortcuts out of habit, I guess I’m going to fix up some my more common shortcuts as code snippets (especially for ASP.NET snippets). The main reason I didn’t use Code Snippets extensively in the past is because there was no support for ASP.NET and JavaScript but now there’s much less of an excuse. While I still prefer the ease and flexibility with which you can create new shortcuts in CodeRush, the VS Code Snippet functionality is relatively nice and easy and it’s built in and easily portable to other VS installations.

jQuery support (with the –vsdoc.js extension files) is now also baked in VS 2010 – jQuery Intellisense just works out of the box and it seems that Intellisense is much more snappy. No more long delays before it works even in large script files and quicker IS pop ups while typing. The JavaScript Intellisense engine (according to release notes) has been reworked to be more flexible and supposedly faster because of it and this first quick checks seem to confirm that.

There are also some improvements in the code formatting behavior which in the past drove me batty with its inconsistent Indenting, re-indenting, outdenting etc. It appears that now the editor gets the intended behavior right most of the time – the result is the auto-format is a heck of a lot less jumpy than it used to be. In a few tests of a script heavy app I’m working on the auto-indenting with often nested jQuery code ended up working predictably and not jumpy as in 2008. Not exactly a new feature but I’m just glad to see this working much better the way it’s supposed to.

Unfortunately the JavaScript editor’s improvements in general are rather minor. There’s still no code navigation of any kind (no function list drop down or class/function/navigator) which IMHO is the biggest shortcoming of the VS JavaScript editor. Disappointed as there was some discussion that this was a coming feature for the VS 2010 editor. Anything beyond Ctrl-F to find code inside of the JS editor would be useful.

Also Refactoring inside of JavaScript surely would be nice. At the very least renaming support is something I wish for in many occasions. Basic function extraction would be useful too as well as block optimization refactorings, but renaming really is the one I would like more than anything.

Anyway, it looks like minor improvements at this point and let’s hold out hope there may still be additional improvements by the time VS 2010 ships.

Posted in JavaScript Visual Studio

A generic way to find ASP.NET ClientIDs with jQuery

Rick Strahl — Thu, 15 Oct 2009 09:04:15 GMT

I’ve been using a small hack to deal with the ASP.NET naming container morass that is so prevalent in client side development with ASP.NET. Particularly in Master Pages all server control IDs are basically munged because the master page place holders are naming containers.

To recap – the problem is that if you are dealing with something as simple as this:

<div class="contentcontainer"  runat="server" id="PageContent">
    <h2>Stock Quote Lookup</h2>
    
    <div class="labelheader" style="margin-top: 20px;">Enter a stock symbol:</div>
    <asp:TextBox runat="server" ID="txtSymbol"  /> 
    <input type="button" id="btnGetQuote" value="Go" />
    
    <div id="divStockWrapper">
        <div id="divStockDetail">        
        </div>
        <img id="imgStockChart"  />
    </div>
</div>

inside of master page or even a container or user control you end up generating HTML output that looks something like this:

<div class="contentcontainer" id="ctl00_MainContent_PageContent">
    <h2>Stock Quote Lookup</h2>
    
    <div style="margin-top: 20px;" class="labelheader">Enter a stock symbol:</div>
    <input type="text" id="ctl00_MainContent_txtSymbol" 
                       name="ctl00$MainContent$txtSymbol" /> 
    <input type="button" value="Go" id="btnGetQuote"/>
    
    <div id="divStockWrapper">
        <div id="divStockDetail">        
        </div>
        <img id="imgStockChart"/>
    </div>
</div>

Notice the ctl00_MainContent prefixes that are added to the server controls that point to the master page and content container respectively. You get those nice and un-friendly ASP.NET naming container generated ids that are a bitch to use in client side code. You don’t want to use these generated names directly because they can easily change if you rename any of the IDs down the chain – if you change the content placeholder’s id so will the id and your script code might break because of it. Not a good idea to use those ids directly.

Now if you want to access this client code you have to jump through a few hoops. A few common ways to access these values with jQuery look like this:

$("#<%= txtSymbol.ClientID %>")

or slightly better more generic approach that stores all client IDs in an object globally:

var ids = { 
    txtSymbol: "#<%= txtSymbol.ClientID %>",
    PageContent: "#<%= PageContainer.ClientID %>"
}
// to use it any where in code:
$("#" + ids.txtSymbol)

The latter also partially gets around the main problem with ClientIDs in that they only work in ASPX pages not external .js files. The latter approach lets you declare only the id definitions in the main page, but the IDs can be globally accessed even in a .js file.

I also posted about a ScriptVariables component that can automate this object creation on the server as part of a component (ScriptVariables component and updated code) so you don’t have to manually map all of the client ids – the component can do it automatically (as well as a few other things like passing any values into JavaScript explicitly with proper formatting ). With this component you have a couple of lines on the server (anywhere in a Page):

ScriptVariables scriptVars = new ScriptVariables(Page, "serverVars");
scriptVars.AddClientIds(Form, true);

which generates a serverVars variable into the client. You can then use the ids like so:

$("#" + serverVars.txtSymboldId)

All of these workarounds are pretty ugly though.

A better Solution

A solution I’ve been using a lot lately is by taking advantage of jQuery itself. We can search for Ids directly from JavaScript since there’s a pretty simple pattern to clientID – at least when dealing with non-repeating values.

Remember a typical client ID that isn’t in a list control of some sort looks something like this:

ctl00_MainContent_txtSymbol

which is actually fairly easy to find with jQuery:

alert( $("[id$=_txtSymbol]").attr("id"));

You can use that directly in your JS code from anywhere that works for most situations, but while it’s not exactly complicated you still have to remember what the format of these controls looks like and how to do an attribute search. It also doesn’t deal with the case where a control might just exist on a page without a master/naming container. How many times have you created a client code page that started out as standalone page and then you later added a Master Page only to find out most of your script code is broken due to the invalid IDs? I know I have.

Knowing the above though it’s easy enough to create a small routine that returns us a jQuery object based on only the id:

function $$(id, context) {
    var el = $("#" + id, context);
    if (el.length < 1)
        el = $("[id$=_" + id + "]", context);
    return el;
}

This code uses jQuery to first do a plain ID search and the behavior of the function is the same as the native jQuery constructor except for the specific selector implementation that only finds IDs. Just as with jQuery you can pass in a relative selector context ( a jQuery object or DOM Element) that limits the search to children of that elements’ level in the DOM hierarchy.

If the function finds a direct match on the ID that’s returned. If not it checks to see if a context was passed. A context is the container context and if passed the search here is limited to that specific container and its immediate children. This is meant to make it easier to isolate naming containers in case there is a possibility of overlapping names so you can drill into a specific user control for example.

So in simple usage to select my ctl00_MainContent_txtSymbol value both of the following work:

alert( $$("txtSymbol").attr("id") );

Or if I want to be specific about the container:

alert( $$("txtSymbol",$("#wrapper")).attr("id") );

This is a low impact approach to dealing with client ids that is easy to type and understand. Obviously you can name this function anything you chose – the $$ just seemed like a good choice to me that doesn’t conflict with anything that jQuery isn’t already conflicting with :-}. I suppose it would also be possible to create a special selector operator in jQuery for this, but I think I actually like the single function implementation better even though it lives outside of jQuery.

Please realize that this won’t address all scenarios where naming container variables might be involved. Specifically this function only deals with the simple ASP.NET variable case – it doesn’t deal with list controls that output sequentially numbered ids, but then that’s not really been an issue for me. I don’t think one often searches for list items by ID directly – they are usually accessed by event behavior or iteration – rarely directly by ID.

Single controls however - I constantly access to get or set values on and manipulate items. While I get more and more away from using server controls at all there are still plenty of times when naming container naming ends up in markup and this makes using these controls a no-brainer.

Performance

Also realize that doing attribute selector searches are fairly slow (but then ‘slow’ is relative). If you have very large documents with lots of elements and you’re doing many lookups using this function you may run into slow performance issues. If that’s the case using the original concept of a global variable that holds all the ids – either manually created or via the ScriptVariables component from the West Wind Web Toolkit – to get better performance. Because that approach uses direct element ids it’s very efficient as ID lookups in a document are among the fastest lookups the DOM can perform.

So as usual there are trade-offs – you’re trading convenience over performance with the $$() function I showed here.

I hope some of you find this simple solution useful.

Posted in jQuery

LINQ to SQL, Lazy Loading and Prefetching

Rick Strahl — Mon, 12 Oct 2009 09:56:53 GMT

LINQ to SQL by default loads related entities and entity sets by using Lazy Loading. Which means if you retrieve a list of entities in a query that references other entities these other entities are not actually loaded unless you physically access them. Lazy loading is quite useful in some scenarios – typically when you load up individual instances for display purposes in simple record based UIs, but it can be a real problem when displaying list based data that needs to have access to related data. In related list scenarios it’s quite easy to have a list that has 100 records displayed on a page to fire off 100 hundred child queries to retrieve the related data – clearly in most cases that’s quite undesirable.

Lets look at an example, from my Time Trakker sample application for the LINQ to SQL business layer.

In my Time Trakker app I have time entries that can be queried. An entry has a related project and customer which in turn can be referenced through the project:

So if I have an EntryEntity I can get a project with Entry.ProjectEntity and a customer with Entry.ProjectEntity.CustomerEntity. So far so good.

Now in my businesslayer I have a routine that basically allows me to query this model for a timesheet report by passing in a bunch of report parameters via a parameter object like so:

public IQueryable<EntryEntity> GetTimeSheetByClient(TimesheetReportParameters parms)
{                        
    IQueryable<EntryEntity> result =
        from entry in Context.EntryEntities
        where entry.TimeIn >= parms.FromDate && 
              entry.TimeIn < parms.ToDate.Date.AddDays(1) &&
              entry.PunchedOut &&
              parms.Companies.Contains(entry.CustomerPk)
        orderby entry.ProjectEntity.Customer.Company, entry.ProjectEntity.ProjectName, entry.TimeIn 
        select entry;

    if (parms.BillType == "Unbilled")
        result = result.Where(e => !e.Billed);
    else if (parms.BillType == "Billed")
        result = result.Where(e => e.Billed);
    
    return result;
}

The parameter object has things like a date range, which type of entries to retrieve and so on which are applied against the mode in the query consecutively. This incremental building up of queries using Linq’s fluent language interface is one of my favorite LINQ features. The result of this query is then returned as an IQueryable<EntryEntity>.

When I retrieve this list of entries in the ASP.NET front end I end up databinding it and then binding to the data inside of a ListView control. The data used is mostly from the Entry Entity but there’s also some data displayed from the customer and project. Here’s what the html based report looks like:

Notice the headers which include the customer name and project name which come from related entities.

Now when the report runs it loads the report like this:

protected void ProcessReport()
  {            
      this.ReportParameters.Companies.Clear();

      foreach (ListItem item in this.lstCustomers.Items)
      {
          if (item.Selected)
              this.ReportParameters.Companies.Add(int.Parse(item.Value));
      }

      this.DataBinder.Unbind();

      if (this.DataBinder.BindingErrors.Count  > 0)
      {
          this.ErrorDisplay.ShowError(this.DataBinder.BindingErrors.ToHtml(), "Please correct the following");
          return;
      }

      IQueryable<EntryEntity> entries = this.Entry.GetTimeSheetByClient(this.ReportParameters);

      // We'll dynamically load the ReportView User Control View, bind it then render
      TimeSheetReport rep = this.LoadControl("~/Reports/TimeSheetReport.ascx") as TimeSheetReport;
      rep.BindData(entries, this.ReportParameters);

      this.RenderReport(rep);
}

then the actual binding in the report to the listview the TimeSheetReport control:

public void BindData(IQueryable query, object parameters)
{
    this.Parameters = parameters as TimesheetReportParameters;

    this.entryList= (query as IQueryable<EntryEntity>).ToList();

    this.lstReport.DataSource = this.entryList; 
    this.lstReport.DataBind();            
}

And finally the data is actually bound:

<asp:ListView runat="server" id="lstReport" ItemPlaceholderID="layoutContainer"  >
<LayoutTemplate>    
    <div id="layoutContainer" runat="server" />
</LayoutTemplate>
<ItemTemplate>    
    
    <%# this.RenderProjectGroupHeader(Container.DataItem as EntryEntity) %>
    <div class="itemcontainer">    
    <div class="itemheader"><%# Eval("Title") %>   </div>    
    <table width="90%" cellpadding="5">
    <tr>
    <td valign="top" style="width:120px;"><small><%# TimeUtils.ShortDateString((DateTime) Eval("TimeIn"),true) %><br />
    <%# TimeUtils.ShortDateString((DateTime) Eval("TimeOut"),true) %></small></td>
    <td valign="top"><%# Eval("Description") %></td>
    <td valign="top" style="width: 70px;"><%# TimeUtils.FractionalHoursToString( (decimal) Eval("TotalHours"), "{0}h {1}min" ) %></td>
    </tr>
    </table>        
    </div>
    <%# this.RenderProjectFooter(Container) %>    
</ItemTemplate>
</asp:ListView>

The main data displayed for each entry all comes from the Entry entity and that’s fine. However there RenderProjectGroupHeader() method figures out whether the group changed and based on this needs to access the Customer and Project information.

        protected string RenderProjectGroupHeader(EntryEntity  entry)
        {
            string output = "";

            // if the project name has changed render a group as a <div> header
            if (entry.ProjectEntity.ProjectName != lastProjectName)
            {
                lastProjectName = entry.ProjectEntity.ProjectName;
                
                // *** New project add hours for first time
                this.groupTotalHours = entry.TotalHours;

                string html = string.Format(
@"<div class='groupheader'>
    <div style='float:right'><small>{0}</small></div>
    {1}
</div>
", entry.ProjectEntity.Customer.Company, entry.ProjectEntity.ProjectName);

                return html;
            }
            else
                this.groupTotalHours += entry.TotalHours;
            
            this.grandtotalHours += entry.TotalHours;

            return output;
        }

And here you can see the child entities being accessed.

Now the report works fine with this code. But if you actually look at this SQL generated for this report you’ll find that this query causes a flurry of activity against the server:

It turns out that each access to the ProjectEntity and CustomerEntity object causes a separate query to the server (shown) for the first time a particular Project or Entity is referenced. This means for each project in the application there will be two additional queries hitting the server so if I show 20 projects I’ll hit the database 40 extra times. That’s lazy loading for you and it’s usually a problem in list based displays like this. It can be much worse if EVERY row you display requires one or more related entities.

Working around Lazy Loading in LINQ to SQL

LINQ to SQL loads related entities and entity sets using lazy loading. Oddly you can’t override this behavior either in the model – even though you can delay load individual properties (like large text, image or XML fields). So everything always lazy loads.

DataLoadOptions for Prefetching

There’s a mechanism that allows you to specify prefetching using the DataLoadOptions which looks like this when applied GetTimeSheetByClient():

public IQueryable<EntryEntity> GetTimeSheetByClient(TimesheetReportParameters parms)
{            
    DataLoadOptions options = new DataLoadOptions();
    options.LoadWith<EntryEntity>(c => c.ProjectEntity);
    options.LoadWith<ProjectEntity>(p => p.Customer);
    this.Context.LoadOptions = options;

    IQueryable<EntryEntity> result =
        from entry in Context.EntryEntities
        where entry.TimeIn >= parms.FromDate && 
              entry.TimeIn < parms.ToDate.Date.AddDays(1) &&
              entry.PunchedOut &&
              parms.Companies.Contains(entry.CustomerPk)
        orderby entry.ProjectEntity.Customer.Company, entry.ProjectEntity.ProjectName, entry.TimeIn 
        select entry;

    if (parms.BillType == "Unbilled")
        result = result.Where(e => !e.Billed);
    else if (parms.BillType == "Billed")
        result = result.Where(e => e.Billed);
    
    return result;
}

This works and results in one large SQL statement that preloads the customer and project child entities.

However, this approach is problematic in a number of ways if you’re like me using a persistent data context. In my applications I scope a data context to a business object, so multiple operations may be performed against a single data context instance. If you have more than one operation that’s called and setting the DataLoad options it’s easy to clobber the settings on this object. A common problem when you have a persistent object like the DataContext and with L2S it’s difficult to get away from storing the context in some sort of persistent mechanism as it’s a connected ORM.

The fact that the options are tied to the DataContext rather than the query itself also makes it much more difficult to customize the query externally depending on the usage of the result. I often pass out an iQueryable and allow customization of the result set. Outside of the business layer the DataContext and therefore the options are not available and so it can’t be set externally.

Finally the DataOptions are tied to full related entities. If you just want to preload a property or two (like ProjectName and Company in our example here) you’re out of luck. DataOptions only deal with full entities.

Using Projection to Force Pre-Fetching

But there’s another way to write your queries differently to effectively force LINQ to SQL to prefetch by using projection in the Select clause of the LINQ statement. Basically the idea is to project the related entities or simple properties at the top level of the returned result to force the data to be denormalized and so becomes effectively preloaded.

So back to the example, if I want to load both the Project and Customer instances completely I can force the query to project into a type like this:

public class ReportEntryItem
{
    public EntryEntity Entry {get; set;}
    public CustomerEntity Customer {get;set;}
    public ProjectEntity Project { get; set; }
}

I’m using an explicit type declaration here rather than an anonymous type because the helper methods of the report rely on an entity instance to retrieve customer and project information and an Anonymous object would not allow access of properties beyond the declared query scope. The explicit object gives me a strongly typed object I can pass around the report UI methods without resorting to Reflection. If you don’t pass the returned result around and bind it immediately the explicit type is not required which is one less thing to declare.

With the new type in place, BindData then changes the query code to look like this:

List<EntryEntity> entryList;
public voidBindData(IQueryable query, objectparameters)
{
    this.Parameters = parameters asTimesheetReportParameters;

    var q = query asIQueryable<EntryEntity>;

    // denormalize the list so we minimize related queries
   var res = from entry in q
              select newReportEntryItem
              {
                  Entry = entry,
                  Project = entry.ProjectEntity,
                  Customer = entry.ProjectEntity.Customer
              };

    // in this case we want a List<T> so we can lazy load more data
   this.entryList = res.ToList();

    this.lstReport.DataSource = this.entryList;
}

Now when the ToList() executes I get a single denormalized and very large record for each row that includes the data for Entry, Customer and Project in the generated SQL:

exec sp_executesql N'SELECT [t0].[Pk], [t0].[CustomerPk], [t0].[ProjectPk], [t0].[InvoicePk], 
[t0].[UserPk], [t0].[Title], [t0].[Description], [t0].[TimeIn], [t0].[TimeOut], [t0].[PunchedOut], 
[t0].[Qty], [t0].[Rate], [t0].[TotalHours], [t0].[ItemTotal], [t0].[Taxable], [t0].[Billed], 
[t0].[Imported], [t0].[Xml], [t0].[tversion], [t3].[test], [t3].[Pk] AS [Pk2], [t3].[LastName], 
[t3].[FirstName], [t3].[Company], [t3].[Address], [t3].[City], [t3].[State], [t3].[Zip], 
[t3].[Country], [t3].[CountryId], [t3].[Phone], [t3].[Email], [t3].[Fax], [t3].[Notes], 
[t3].[Entered], [t3].[Updated], [t3].[LastOrder], [t3].[BillingRate], [t3].[Xml] AS [Xml2], 
[t3].[tversion] AS [tversion2], [t1].[Pk] AS [Pk3], [t1].[CustomerPk] AS [CustomerPk2], 
[t1].[ProjectName], [t1].[Entered] AS [Entered2], [t1].[StartDate], [t1].[EndDate], 
[t1].[Status], [t1].[tversion] AS [tversion3]
FROM [dbo].[Entries] AS [t0]
INNER JOIN [dbo].[Projects] AS [t1] ON [t1].[Pk] = [t0].[ProjectPk]
LEFT OUTER JOIN (
    SELECT 1 AS [test], [t2].[Pk], [t2].[LastName], [t2].[FirstName], [t2].[Company], [t2].[Address], [t2].[City], [t2].[State], [t2].[Zip], [t2].[Country], [t2].[CountryId], [t2].[Phone], [t2].[Email], [t2].[Fax], [t2].[Notes], [t2].[Entered], [t2].[Updated], [t2].[LastOrder], [t2].[BillingRate], [t2].[Xml], [t2].[tversion]
    FROM [dbo].[Customers] AS [t2]
    ) AS [t3] ON [t3].[Pk] = [t1].[CustomerPk]
WHERE (NOT ([t0].[Billed] = 1)) AND ([t0].[TimeIn] >= @p0) AND ([t0].[TimeIn] < @p1) AND ([t0].[PunchedOut] = 1) AND ([t0].[CustomerPk] IN (@p2, @p3, @p4, @p5, @p6, @p7, @p8, @p9, @p10, @p11, @p12, @p13, @p14, @p15, @p16, @p17, @p18))
ORDER BY [t3].[Company], [t1].[ProjectName], [t0].[TimeIn]',N'@p0 datetime,@p1 datetime,@p2 int,@p3 int,@p4 int,@p5 int,@p6 int,@p7 int,@p8 int,@p9 int,@p10 int,@p11 int,@p12 int,@p13 int,@p14 int,@p15 int,@p16 int,@p17 int,@p18 int',@p0='2009-01-09 00:00:00',@p1='2009-10-10 00:00:00',@p2=25,@p3=2,@p4=40,@p5=41,@p6=42,@p7=15,@p8=26,@p9=45,@p10=44,@p11=16,@p12=3,@p13=24,@p14=23,@p15=4,@p16=43,@p17=39,@p18=1

Denormalized alright, but what this does is effectively provides the necessary data for all Entry, Project and Customer entities to be completely filled.

For the ListViewItem template this means that individual controls now bind to Entity.Field:

<div class="itemheader"><%# Eval("Entity.Title") %></div>

instead of just binding to the Title before. I can also directly access the project now without reloading:

incidentally the following also works now without another trip to the database:

To demonstrate in the example, the report header function now receives the report item as a parameter and gets a repItem.Entry from it. Otherwise there are no changes in that code from before:

protected string RenderProjectGroupHeader(ReportEntryItem  repItem)
{
    string output = "";
    EntryEntity entry = repItem.Entry;

    // if the project name has changed render a group as a <div> header
    if (entry.ProjectEntity.ProjectName != lastProjectName)
    {
        lastProjectName = entry.ProjectEntity.ProjectName;
        
        // *** New project add hours for first time
        this.groupTotalHours = entry.TotalHours;

        string html = string.Format(
@"<div class='groupheader'>
<div style='float:right'><small>{0}</small></div>
{1}
</div>
", entry.ProjectEntity.Customer.Company, entry.ProjectEntity.ProjectName);

        return html;
    }
    else
        this.groupTotalHours += entry.TotalHours;
    
    this.grandtotalHours += entry.TotalHours;

    return output;
}

Note that I can still bind to entry.ProjectEntity.ProjectName and this works without another trip to the database because the Project entity was preloaded in the repItem.Project property. This the same instance that’s referenced in entry.ProjectEntity just as repItem.CustomerEntity is the same entry.ProjectEntity.CustomerEntity.

By including the Customer and Project entities as projected values in the query we’ve forced them to preload and we've reduced 40 queries to just a single (but large and redundant) query.

Watch what you Load

This example loads the full customer and project entities, but realistically we only need the Company and ProjectName fields from the respective related tables. If you know up front you only need a few of the fields in a table it’s more efficient to load just that data in the projection which has roughly the same effect. Again this is easier if you can use an anonymous type, otherwise the projected type instance has to reflect this layout.

The following is quite a bit more efficient than retrieving the full entities:

var res = from entry in q
 select new ReportEntryItem
 {
     Entry = entry,
     ProjectName = entry.ProjectEntity.ProjectName,
     Company = entry.ProjectEntity.CustomerEntity.Company
 };

because it reduces the amount of field data for each row of SQL result data significantly.

You have to be careful with this though – in the above scenario if I access entry.Entry.ProjectEntity.CustomerEntity.Address I will end up lazy loading both the Project and Customer records from the database. In this instance only the ProjectName and Company were retrieved, not the entire entities. IOW, if you pull just a few fields of related entities make sure you stick to using only those fields and leave the actual related entities alone.

To Lazy Load or Not to Lazy Load

Arguably LINQ to SQL’s lazy loading functionality behavior without override ability is not exactly intuitive, but it’s not terribly complex to force it to return pre-loaded data either. It does require some foresight as switching between lazy loaded and pre-loaded entities effectively requires some code changes to reflect the project type’s structure. It would be much nicer if there was syntax that would let you specify a prefetch path right on the query (something I really like about llblGen’s LINQ implementation).

Also keep in mind that lazy loading isn’t always bad so this isn’t something that should be done on every query. Denormalized data retrieves a lot of repetitive data so you’re often sacrificing data on the wire for fewer round trips to the database. In many situations – especially record level CRUD operations – lazy loading is usually a great way to go. Even small list based displays might not suffer severely from many requests to retrieve data vs. running a single query to retrieve the data you need. Also keep in mind that child items don’t necessarily load for EACH and every row, but only the first time a particular instance is loaded, whereas a denormalized query ALWAYS retrieves the related data for every row. So a list with a lot of repeated related data may not actually access the database as often as you might thing. It’s a tradeoff and experimentation is required to see what works best in each situation. But with a little bit of extra work you can make L2S do what you need it to.

Posted in LINQ CSharp

Application that won’t Pin to Taskbar in Windows 7

Rick Strahl — Thu, 08 Oct 2009 09:02:57 GMT

Ok, so I have one of my applications (Html Help Builder) that will not pin to the taskbar in Windows 7. This is an application I’ve created and have full control over in terms of build, but I can’t figure out why it will not pin to the Windows 7 taskbar. All other applications pin just fine, but this particular one will not pin or be dragged onto the taskbar. Not from a running application, not from a dragged shortcut or by using the context menu to pin it to the taskbar. The Task menu that pops up has nothing more than a Close this Application on it instead of the usual pin options.

Notice that this looks very different from a typical application which shows the actual application instance(s) running plus the Pin this program to taskbar:

I also have this application hooked to a shortcut on the desktop and the desktop shortcut also doesn’t have a Pin to taskbar option like all other icons.

As far as I know there’s nothing particularly special about this application. It’s an EXE launched from either a shortcut or directly from Explorer and it just will not pin. Since this is a distributed application I also installed it on another machine with exactly the same result. The context menu has no pinning options and I can drag the shortcut onto the taskbar either.

This is an old FoxPro based application that uses the Visual FoxPro 9.0sp2 runtimes. Now some of you will jump on that and say “Aha!” – but that’s not it. I have several other applications that are configured pretty much in the same way – and they run fine and have perfectly fine pinning options. In fact the second screen shot you see is another FoxPro EXE application run off a shortcut. And it appears to be working just fine.

So it appears it’s something inside the application that is causing this to occur.

It’s the Filename, Stupid!

So imagine that prior to this section I posted about 10 bullets of things I’d tried that didn’t work to solicit some feedback, when I ran across a Technet post with another guy who had an application named documentation.exe that didn’t work. It was explained to him that there are a few ‘reserved’ words for EXE names that are treated special. documenation.exe was a bad name – and bad names don’t get proper taskbar representation. Bad exe – go stand in the corner!

Windows has a few reserved names that include things like Documentation, Help, Setup, Readme etc. that are not pinned to the taskbar. These are exceptions in Windows (sorry, I couldn’t find a link that provides a complete list).

I dismissed that Technet post initially when I ran into it because the name of my EXE is pretty unique: wwhelp.exe. Not exactly a name you would expect to be on any sort of exception list. But it turns out the rules in Windows aren’t exact matches, but it looks for anything that contains these names. So anything that contains the word Help in the EXE name is considered a special item (presumably a help file).

So I renamed my file to HlpBuilder.exe and lo and behold – I get my Pin to taskbar back and all windows show up on the task context menu. It gets even better though. If I rename the EXE I do get the Pin to taskbar option, but if I create a shortcut and name it West Wind Html Html Help Builder the shortcut again has no Pin to taskbar option and I can’t drag it to the taskbar. Apparently if the reserved word appears in the text of the shortcut it too is limited in functionality.

Where is this Limitation coming from?

These ‘restricted’ values are determined by a registry key at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileAssociation\AddRemoveNames

with these default values:

Documentation;Help;Install;More Info;Readme;Read me;Read First;Setup;Support;What's New;Remove

Man, how retarded is that? If an EXE file contains any of these reserved words it won’t pin? If the Shortcut Text contains one of these reserved words it won’t pin and generally work incorrectly? Really? Why have an arbitrary exception like that? That’s making an awful lot of assumptions and this is likely to break a number of application and they’re standard Windows behavior. This is an EPIC design failure on Microsoft’s part.

It looks like my only alternative is to rename the main EXE. I’m not really married to wwhelp.exe (how old skool of me – uh, this app is going on 15 years)Unfortunately it’s not quite as simple as that. There are update routines in a separate application that have the filename hard coded (and which doesn’t update at customers) and since the EXE is a COM server it needs to be re-registered. An EXE change basically requires a full reinstallation of the product instead of the normal update process I use. But I don’t know what to do about the shortcut. I can’t just erase Help from the name of the shortcut since it’s the freaking product brand name.

So as a vendor what do I do? Hack the registry during installation and modify that string, remove Help from the list? That’s evil mucking with user settings, but what other options are there?

<sigh> It’s never easy on the Windows platform is it? How I hate building desktop apps these days, but this is one app that wouldn’t work well as a Web UI unfortunately.

Posted in Vista Windows

Fun with Func<T,TResult> Delegates, Events and Async Operations

Rick Strahl — Mon, 05 Oct 2009 08:38:32 GMT

Func<T> has been in .NET for a while, but with the arrival of LINQ it’s moved into the limelight as main performer that makes Lambda expressions work. Func<T> is basically a generic delegate that makes it extremely easy to create all sorts of custom delegate signatures without having to explicitly implement the delegates separately.

Events

How often have you lamented the fact that you have to create a custom delegate for an event that needs to fire a method that uses non-typical event arguments? Traditionally you had to create the method and also create a delegate that matched the signature which is a bit verbose at best. Typical event setup code looks something like this:

public event delInvoiceCalculation CalculateTax;
public delegate decimal delInvoiceCalculation(wws_Invoice invoice);
       
public virtual decimal OnCalculateTax(wws_Invoice invoice)
{
    var calcTax = CalculateTax;
    if (calcTax != null)   
        return calcTax(invoice);

    return invoice.Tax;
}

You have to declare a separate delegate and provide the appropriate signature to match the event function that should be called.

Using Func<T> this code can be made a bit cleaner by removing the extra delegate. Here’s another implementation for a similar method using the same signature but using Func<T> or more specifically in this example, Func<T,TResult>

public event Func<wws_Invoice,decimal> CalculateHandling;
public virtual decimal OnCalculateHandling(wws_Invoice invoice)
{
    // TODO: provide logic here
    var calcHandling = CalculateHandling;
    if (calcHandling != null)
        return calcHandling(invoice);

    return Entity.Handling;
}

Func<T> simplifies the event signature a bit by removing the explicit delegate declaration and instead using the generic Func<T,TResult> implementation that allows you to create a custom delegate signature directly on the event. Not only does it save a little bit of code typing, but I also find this easier to see what’s going because it is more explicit in a single statement compared the first snippet where delegate and event declaration are separate (and often completely separated physically because the delegate is reused by multiple events).

Func<T> is a generic function signature/delegate and it works by implementing a delegate by way of its generic parameters. The last generic parameter provided is always the type of the return value (decimal above). Any preceeding generic parameters (up to 4 in Func<T>’s overloads) become the types of input parameters. In this case my signature is for Func<T,TResult> where T is my invoice entity and TResult is bool.

In this respect:

Func<wws_Invoice,decimal>

is equivalent to:

public delegate decimal delInvoiceCalculation(wws_Invoice invoice);

except it doesn’t have to be explicitly declared.

Func<T> in LINQ

Delegates are generally easy to understand but it’s one of those features we don’t use all that often and so it’s easy to forget how they work and what we need them for. Well we know LINQ is full of them – most LINQ operators like .Where() and OrderBy() and Select() to name a few all rely on Func<T> signatures for Lambda expressions. Between Func<T> delegate signatures and lamda expressions statements like this:

Context.wws_Items.Where( itm => itm.Sku == sku );

become possible and quite readable once you get over the initial weirdness of the => operator. What you’re looking at in the Where clause is actually an implemenation of Func<T,bool>:

The input parameter is the the enumerable type (wws_Item from the List<wws_Item> and the return value is bool. The return value is inferred by the compiler and so only the input parameter is used (itm =>) in the lambda expression’s left side. Func<T> is a key feature to make LINQ workable using terse code.

Note that if you use LINQ to SQL or LINQ to Entities Func<T> based parameters to any LINQ commands require an Expression wrapper that wraps the Func<T> expression. This is because these tools delay executing the expressions until a later point in time when the expressions are parsed into some other format (SQL command, Entity SQL or whatever the expression engine uses).

This actually tripped me up yesterday and was what got me on to writing up this content. In my business layer I have basic CRUD operations including the ability to load entities without running a full LINQ command. There’s a base implementation that takes a LINQ expression as a parameter that is passed to a LINQ .Where() method that executes the actual query. At first I passed a Func<T> argument but I quickly found out that this doesn’t actually work – the result from the LINQ to SQL query always returned null. The reason: It’s not an expression that was passed but just a predicate.

I had to make sure the method was declared correctly using an Expression and the correct code that works looks like this:

protected virtual TEntity LoadBase(Expression<Func<TEntity, bool>> whereClauseLambda)
{
    SetError();

    try
    {
        TContext context = Context;

        // If disconnected we'll create a new context
        if (Options.TrackingMode == TrackingMode.Disconnected)
            context = CreateContext();

        Entity = Context.GetTable<TEntity>().Where(whereClauseLambda).SingleOrDefault();

        if (Entity != null)
            OnLoaded(Entity);                

        return Entity;
    }
    catch (InvalidOperationException)
    {
        // Handles errors where an invalid Id was passed, but SQL is valid
        SetError("Couldn't load entity - invalid key provided.");
        Entity = null;
        return null;
    }
    catch (Exception ex)
    {
        // handles any other sql errors                
        Entity = null;
        SetError(ex);
    }

    return null;
}

This makes it super easy to create custom load methods that all use the common LoadBase method and so inherit its behavior. in most cases it becomes as trivial as this:

/// <summary>
/// Loads an individual item by sku
/// </summary>
/// <param name="sku"></param>
/// <returns></returns>
public wws_Item LoadBySku(string sku)
{
    return this.LoadBase(itm => itm.Sku == sku);
}

which is pretty nice and consistent.

Easy Async

Here’s another useful example of how Func<T> can make life a lot easier. For example, kicking off an async delegate with Func<T> becomes a single line operation which makes it a snap to turn just about any operation into an async operation like this async update routine:

public void LogSnippetViewAsync(string snippetId, string ipAddress, string userAgent)
{
    Func<string, string, string, bool> del = this.LogSnippetView;
    del.BeginInvoke(snippetId, ipAddress, userAgent, null, null);
}

public bool LogSnippetView(string snippetId, string ipAddress, string userAgent)
{
    if (string.IsNullOrEmpty(userAgent))
        return false;

    userAgent = userAgent.ToLower();

    if (!(userAgent.Contains("mozilla") || !userAgent.StartsWith("safari") ||
        !userAgent.StartsWith("blackberry") || !userAgent.StartsWith("t-mobile") ||
        !userAgent.StartsWith("htc") || !userAgent.StartsWith("opera")))
        return false;

    this.Context.LogSnippetClick(snippetId, ipAddress); // stored proc

    return true;
}

Here’s Func<T1,T2,T3,TResult> is used to specify 3 parameters (3 strings) and a return value of bool. del is the Delegate declaration and we’re pointing it at the LogSnippetView method to execute. Then BeginInvoke is called to asynchronously launch the method so it runs in the background on a thread pool thread.

Again, using Func<T> avoids having to explicitly declare a delegate separately and instead you can directly declare the delegate signature via Func<T> inline which is easier to read and understand – at least to me.

Sometimes it’s the little things that make life easier and Func<T> is one of those.

Posted in CSharp LINQ

Lookbehind in Regex searches

Rick Strahl — Sat, 03 Oct 2009 09:03:20 GMT

I’ve said it before – Regex is not one of my strengths and although I use Regex expression quite frequently in code I’m in fear (literally) of using longer Regex expressions, fully expecting to look at my own Regex code and not remember what it does10 minutes later :-}. Ok, not quite so bad, but not completely off the mark.

Today I had what is a fairly simple problem – I needed to match a JSON string and check for invalid quote characters in the string. For example:

JSON String: \"that has legal nested quotes\" and "illegal nested quotes" embedded in it

(leading and ending JSON quote marks are trimmed out prior to matching)

Basically what I needed to do is match the quotes around the illegal string to determine if the string is invalid JSON. This is somewhat tricky because the rule is to basically find double-quote characters that are NOT preceded by a slash.

The solution to this is quite easy – once you know about a feature called Lookbehind – that basically lets you match or not match a group and not include the content in the match expression. Lookbehind uses (?<=) to match or (?<!) expression followed by actual text or Regex values to match inside of the parenthesis. The negating Lookbehind basically allows you to find a string if the lookbehind expression is NOT found. Exactly what I need above for my JSON string – I need to match all qutoes that are NOT preceeded by a slash.

Using Lookbehind the solution to matching the illegal quotes is as simple as:

($<!\\)"

Ah the beauty of terseness. Nice and self-describing, n’est pas? NOT. Here’s a more visual view in RegexBuddy which is my preferred tool for Regex testing:

As you can see the the legal quotes preceded by the slashes are not matched which is as it should be.

In my .NET code that parses a JSON string (as part of full JSON parser) here’s the routine that uses the Regex expression:

private static Regex FindUnquotedStringRegEx = new Regex(@"(?<!\\)""");

/// <summary>
/// Parses a JSON string into a string value
/// </summary>
/// <param name="value"></param>
/// <returns></returns>
public string ParseString(string value)
{                                    
    // actual value of null is not valid for 
    if (value == null)
        throw new ArgumentException(Resources.ERROR_INVALID_JSON_STRING);

    // null as a string is a valid value for a string
    if (value == "null")
        return null; 
    
    // Has to be at least 2 chars long and bracketed in quotes
    if (value.Length < 2 || (!value.StartsWith("\"") || !value.EndsWith("\"")))
        throw new ArgumentException(Resources.ERROR_INVALID_JSON_STRING);
    
    if (value == "\"\"")
        return string.Empty;
    
    // strip off leading and trailing quote chars
    value = value.Substring(1, value.Length - 2);
    
    // Check for strings NOT preceeded by a backslah - invalid
    if (FindUnquotedStringRegEx.IsMatch(value))
        throw new ArgumentException(Resources.ERROR_INVALID_JSON_STRING);

    // Escape the double escape characters in json ('real' backslash)  temporarily to alternate chars
    const string ESCAPE_ESCAPECHARS = @"^#^#";

    value = value.Replace(@"\\", ESCAPE_ESCAPECHARS);

    value = value.Replace(@"\r", "\r");
    value = value.Replace(@"\n", "\n");
    value = value.Replace(@"\""", "\"");            
    value = value.Replace(@"\t", "\t");
    value = value.Replace(@"\b", "\b");
    value = value.Replace(@"\f", "\f");

    if (value.Contains("\\u"))
        value = Regex.Replace(value, @"\\u....",
                              new MatchEvaluator(this.UnicodeEscapeMatchEvaluator));

    // Convert escaped characters back to the actual backslash char 
    value = value.Replace(ESCAPE_ESCAPECHARS, "\\");

    return value;
}

And it works.

I’ve never really used Lookbehind before (gulp) and when I popped out a question regarding the matches I was looking for earlier today on Twitter several folks were very helpful in pointing me in the right direction. Thanks to lumbarius who got the expression and a link to find out more.

I dug out my trusty copy of O’Reilly’s Mastering RegEx Expressions out today and did a little more reading on the topic.

Mastering Regular Expressions
by Jeffrey Friedl
O'Reilly Media, Inc. (August 8, 2006)

Read more...

I’ve certainly read through that section on Lookahead and Lookbehind before but at the time it really didn’t mean much and certainly didn’t sink in, but now with a little context behind it I think… I think… I can maybe retain this for more than 10 minutes. And if not I have this blog post to help me remember. If I can remember the blog post – Arrgh… where does it stop?

Posted in CSharp RegEx

Debugger Visualizers not working in ASP.NET Medium Trust

Rick Strahl — Thu, 24 Sep 2009 07:48:07 GMT

So imagine you are running your ASP.NET application’s in medium trust and you want to access a debugger visualizer like this:

by clicking on the little search icon in the debugger tooltip, you run into a message like this:

The application you are debugging has insufficient privileges to allow the use of custom visualizers

or more visually here failing with a DataTable visualizer:

Ah yes, see the documentation. I know I should have read that one page pamphlet Microsoft ships for documentation with ASP.NET. Right.

The problem is that the application needs to run in Full trust in order to use debugger visualizers. This can be changed in Web.config by making sure that the trust key :

<system.web>
  <trust level="Full" />
</system.web>

is set to Full trust.

Debugger visualizers can come from many sources so the security environment for the visualizers is different than than main debugger and as such it requires explicit permissions to execute.

Be careful with these settings though. For production sites it’s recommended you run in Medium trust, so if you change settings in your local config file remember not to send them up to the server. Better yet, change the settings only while you need it for debugging and then set it back.

I run into this frequently because I try to set up my Web sites during development with Medium trust if I can to see all the places when and if I run into problems. So I often end up having to change that switch temporarily for debugging and then setting it back when I’m done with this task.

Posted in ASP.NET Visual Studio