Easily refresh an UpdatePanel, using JavaScript [Encosia]

Seems that I occasionally need to trigger the postback on an UpdatePanel, and invariably I forget between usages.

Since this particular post from Encosia has saved my bacon on more than one occasion, I shall share it here (and for my own future benefit):

Easily refresh an UpdatePanel, using JavaScript | Encosia:

I’ve noticed a lot of discussion lately regarding methods to refresh an UpdatePanel via client script. This is very easy on the server side, of course. You can just call UpdatePanel.Update(). However, on the client side, the most common solutions I’ve been seeing just don’t feel right. Many will advise you to use a hidden button control inside the UpdatePanel, manipulated via button.click(), to trigger a partial postback of the UpdatePanel. While it does work, I never have been able to get past the kludgey nature of that solution.

In a nutshell, we can use the __doPostBack() method:

Luckily, there’s an easy method for triggering a postback targeted at the UpdatePanel: __doPostBack().

As long as the event target of a __doPostBack() call is an async trigger of an UpdatePanel, the ASP.NET AJAX framework will intercept the postback and fire a partial postback instead. For purposes of demonstration, I’m going to add that to the OnClick event of the container div:

<div id="Container" onclick="__doPostBack('UpdatePanel1', '');">

Now, clicking anywhere in the UpdatePanel will trigger a partial postback, targeting the UpdatePanel. Since partial postbacks follow the full page lifecycle, this will fire UpdatePanel1_Load and update the Label’s text.

Setting Session Variables in ASP.NET from JavaScript

Someone on the ASP.NET forums asked how to set session variables in JavaScript. The answers given ranged from “totally wrong” to “rather misleading” or “marginally helpful”.

So in a nutshell, yes, you can totally do it. Not only will you be able to do it, you will love doing it after you get used to the process of getting it set up.

Here’s the recipe for success:

  • Add an ASP.NET AJAX ScriptManager to your page.
  • Create a simple ASMX Web service using Visual Studio.
  • Uncomment the Attribute directly above the class definition that reads [System.Web.Script.Services.ScriptService] to enable ASP.NET AJAX to see your web methods.
  • Create a method to get or update data in your session, and make sure the Attribute above the web method reads [WebMethod(EnableSession = true)] so you can have access to the session via your web service method.
  • Add a <Services> section to your ScriptManager.
  • In the <Services> section add a <ServiceReference> element with the Path attribute set to the path of your .asmx page.

OK, so that enables the ability to access your session from the client side.

But here’s the really awesome part:  if you include a reference to the web service in your .js file like so:

///<reference path=”~/MyServices/MyService.asmx” />

…you will get IntelliSense in the JavaScript for your web service methods! it’s very cool.

So then you just call your web service methods like you would any other JavaScript function. It’s totally easy and almost magical. It’s one of my favorite features of ASP.NET AJAX.

Solved a problem with an Visual Studio 2008 “Source control provider could not be found” error…

I had run into this problem before.

Setup

  1. I have my Visual Studio 2008 options set to reload the previously loaded solution on startup.
  2. I use Subversion.
  3. I use AnkhSVN as my SVN provider in Visual Studio 2008.

Problem
If I launched Visual Studio 2008 with a particular solution loaded when I last closed VS, I would receive a “Source control provider could not be found” error.

However… if I just launched it via double-clicking on the .SLN file in my file system, no error!!!

Weird.

OK – so I did a quick diff on a solution that I knew worked fine. Both had the expected source control provider information embedded:

SccProjectName = "Svn"
SccAuxPath = "Svn"
SccLocalPath = "Svn"
SccProvider = "SubversionScc"

However there was a difference.

The solution that did not generate the error message also contained the following block in the “Global” section:

GlobalSection(SubversionScc) = preSolution
    Svn-Managed = True
    Manager = AnkhSVN - Subversion Support for Visual Studio
EndGlobalSection

Which somehow got generated in one solution, but not the one causing problems. Once I copied the block from one solution to the other, the error message ceased to be shown on launch of VS2008.

Running a javascript function after UpdatePanel.Update()

Found this forum post to be very helpful and I think I may employ this more often when doing UpdatePanel related messaging-when-done…

Run a javascript function after UpdatePanel.Update() – ASP.NET Forums:

You should call the method in this way:

ScriptManager.RegisterStartupScript(this.Page, this.GetType(), “MyScriptName”, “<script type=’text/javascript’>functionToCall(‘hello world’);</script>”, false);

The problem could be the fact that you are using this instead of this.Page. Also instead language=’javascript’ you can use type=’text/javascript’.

All I know is that when I launched the script properly passing this.Page it worked properly. I had derived from Page to a custom base page, so maybe that had something to do with it.

Additionally, I refined it just a bit by building the script dynamically in a string and then passing that instead of just a literal in the static method call.

One more improvement I was considering is to embed this as a method on my aforementioned customized base page. Then i can just pass a name and the script to the method, and I won’t have to worry about the messy details every time.

ASP.NET Logging to the Visual Studio Output Window with log4net

OK this one has been baffling me for a long time but I just ignored it. We have been using the open source logging library log4net for a long time, and for the most part it was working fine. But the one thing that I wanted to do but could never get working was logging to what my brain wanted to call “The Console,” AKA (to me) the Output window in Visual Studio.

I tried using the log4net appenders ConsoleAppender and ColoredConsoleAppender, to no avail. Turns out there’s a different appender that works with the Output window, and it’s not ConsoleAppender.

The appender in question is TraceAppender!

So here’s a little snippet of XML from my web.config files that handles output to the Output window (basically the same markup as appears on the log4net examples page):

  </log4net>
    <appender name="TraceAppender" type="log4net.Appender.TraceAppender">
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%d [%t] %-5p %c %m%n"/>
      </layout>
    </appender>
    <root>
      <level value="ALL"/>
      <appender-ref ref="TraceAppender"/>
    </root>
  </log4net>

To those familiar with the way the log4net section looks in your web.config this will make sense, but the key concept is that, per the log4net documentation, “Events are written using the System.Diagnostics.Trace.Write(string,string) method” — and it turns out that one of the listeners is the Output window!

A colleague of mine and I were very confused by all this (I’m glad I wansn’t alone in that feeling either!), but we were both very glad to figure this one out.

Thanks go to Google (of course), and this post on the SharpDevelop forums.