One of the properties of the UpdatePanel is the RenderMode [Block|Inline]. Whether you choose block or inline depends on your user interface needs.

In order for the DHTML framework of the browser to properly find and update the content within the UpdatePanel, it must be rendered as something which can enclose content and have no UI of its own. The logical response to this need is either the <SPAN> or <DIV> tags; which the UpdatePanel can render itself as depending on whether you choose Inline or Block as the RenderMode, respectively. What's the difference? For those that aren't extremely familiar with the <SPAN> or <DIV> tags, it basically comes down to the <DIV> tag acting as more of a division or sub-region to a page, which means that it "blocks" in content (has actual dimensions and can block in content, indent paragraphs, etc.) and the <SPAN> tag is basically the <DIV> tag without this feature.

An example is at hand. The following HTML:

    <b><div style="width:50px">
        This is my sentence, this is my sentence
    </div>
    <span style="width:50px">
        This is my sentence, this is my sentence
    </span></b>

Renders itself as:

This is my sentence, this is my sentence

Within modern browsers (in other words, if yours doesn't display the first one indented, and the second one not indented, then get off Lynx).

http://90statehouse.com/forums/blogs/robertseder/archive/2006/06/04/201.aspx

A fairly concise and good blog post on how to use the template feature of user controls to template'ize them with data that might be inappropriate to pass in as a regular property value:

So, instead of:

<blah property="blah"></blah>

You could do:

<blah>
   <property>   

      ....any content you please....

   </property>
</blah>

Most of us are familiar with this feature from such controls as the Repeater and GridView...but here you see how you can roll your own controls to use this feature.

The mode property on the UpdatePanel basically sets under what conditions, generally, does an UpdatePanel refresh itself. When a page does a complete postback, all UpdatePanels are refreshed. When a page does a partial postback, however, only selected UpdatePanel panels refresh - particularly, those with "Always" set as their Mode. If an UpdatePanel's Mode property is set to "Conditional", then only when a postback request is generated by one of the Panel's triggers, or from a control within the panel, does the Panel refresh.

In summary:

Mode:	Full Postback	Any partial postback	Selected partial postbacks
Conditional	X		X
Always	X	X	X

The thing that got me excited, however, is that somehow within the client framework the code is determining the source of the event and whether it's tied to a particular UpdatePanel. Currently within the "Atlas" framework there is no way to create an UpdateProgress control which acts only under certain circumstances: basically it is on or off, no in between, and it is on or off no matter what originated the partial postback. There might be a clever way to tie the event source and UpateProgress controls together to roll your own solution to this drawback...

...now, granted, the final release to Altas will reportedly have this feature, but it'll be an interesting excercise to do it on my own....

Not a bad little book, you can get it from here.

If you are kind of clueless as to what you can do with the UpdatePanel and would like some fairly practical examples, then I would recommend getting it (it's only, like, ten bucks). You're not going to come away knowing a whole lot about the internals of the UpdatePanel by reading it, but I don't think that was the point of the book from the beginning. I enjoyed reading it, if nothing else it served as reinforcement for various things I had discovered on my own.

...I would recommend it.

If you're involved in the whole podcasting thing (you listen, etc.) you might want to check out this ASP.Net podcast page: http://aspnetpodcast.com/CS11/blogs/.

I just downloaded a new PDF book on the UpdatePanel control for Atlas. Read more about the article/book here. I'll read it tomorrow and give feedback on what I think of it.....(and any new bits of information I may have learned from it).

We have ViewState which maintains stateful information about each control on a page, and we have UpdatePanels which add functionality to a page to postback only part of itself - exactly how is ViewState maintained? The answer is simple - nothing has changed from the old model: to maintain consistency (so that the ViewState isn't corrupted or damaged given that only some of the controls will be updating on a partial postback), the Atlas server-side framework asks every control within a form to render viewstate. The Atlas server framework then simply iterates over the hidden fields generated (_VIEWSTATE is a hidden field), and spits those out into the page.

For example, RenderPageCallback within the ScriptManager class has a chunk of code that looks like this:

Dim form1 As HtmlForm = page1.Form
....
Dim writer1 As New ParserStringWriter
Dim writer2 As New HtmlTextWriter(writer1)
writer1.ParseWrites = True
form1.RenderControl(writer2)
....
Dim pair1 As KeyValuePair(Of String, String)
For Each pair1 In writer1.HiddenFields
   writer.WriteLine("<hiddenField id=""{0}"" value=""{1}"" />", pair1.Key, pair1.Value)
Next

See that we ask for the page Form, we then as the form to render (which asks each of its children to render), and then we iterate over the .HiddenFields of the result and spit each one out. It appears as though the runtime doesn't pick out which controls to render into viewstate and which ones to not, it simply asks them all to render.

..this is something work looking into if you do high-end network stuff.

The basic concept behind this networking pack is that it enables NetDMA (DMA = Direct Memory Access) for network-aware applications - meaning they can access packet information in a shared ring buffer allocated by the network stack itself, software which works with NICs supporting a TOE (TCP Offload Engine) which effectively differs processing and storing of TCP-related bits on the NIC itself (which offloads work from the CPU), and a Receive-side performance scaler which works to evenly spread the load of processing network traffic across multiple processors.