Tech Blog

Jay's Technical blog

Cool ScriptManager stuff I missed...

29 May 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

So the last week or so I have been doing some heavy handed UpdatePanel development (stuff where I needed to fix an existing form that needs help to support an UpdatePanel or stuff where I needed to do something special while the page was posting back asyncronously).

In the midst I discovered some cool mechanisms that I missed!

For instance you can determine whether the current request is an async request by doing something like this:

  1: ScriptManager sm = ScriptManager.GetCurrent(Page);
  2:if (sm != null && sm.IsInAsyncPostBack)
  3: {
  4:// do something special here
  5: }

 

The other problem I had was that I needed to emit a startup script that should execute after the async request finished rendering. It turns out that the ScriptManager control has some really nifty static methods. Here’s the example of what I was trying to do:

  1://                                  (control, type,   ScriptID,ScriptToRun, AddScriptTags) 
  2: ScriptManager.RegisterStartupScript(this, GetType(), "someID", "SomeScript", true);

Investigate it for yourself... there’s a lot of handy stuff here that corresponds to the same stuff you can do with the Page’s ClientScript object (with the difference being that ScriptManager’s stuff works during a Async Postback)


Script#: Events/Delegates in an Atlas/MS Ajax style script

22 May 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

First of all if you don’t know what Script# is, it is a C# language variant available in VS2005/2008. The difference is that it can be used to create JavaScript. The compiler produces an assembly (usable in other Script# projects) and a set of JS files (a release and a debug version). Nikhil Kothari (the author) also has 2 script frameworks you can target: Nikhil’s framework, and the "Atlas"/MS Ajax (aka MS ASP.NET Ajax) framework. There are difference in what you can do when using the "Atlas" framework.

Event Limitations

Let me start with a quote from the Script# Dox (regarding limitations in "Atlas" targeted scripts):

"No support for auto-generated event accessors. Auto-generated event accessors require the existence of a Delegate class with Delegate.Combine/Remove semantics, which are not provided
by ASP.NET AJAX. The workaround is to explicitly implement the 2add/remove accessors for events in your code, rather than have the compiler generate it. "

Basically this is saying there are issues with building events in your classes with Script#. It’s not impossible, but it’s not automatic like it is in Nikhil’s Script# (client-side) framework.

Since I recently had to do this and had to search the Internet for a solution (which there is no answer for), I thought it would be good to document how to do it (for both my reference and for others).

How To Add/Remove Events

That comment about needing to create your own add/remove logic is really simple to handle, but your class needs to derive from Sys.Component (or a class like behavior and control which derive from Sys.Component). The code looks like this (In Script#):

  1:// add a handler to an event
  2:publicvoid add_MyEvent(EventHandler fn)
  3: {
  4:this.Events.AddHandler("MyEvent", fn);
  5: }
  6:// remove a handler from an event
  7:publicvoid remove_MyEvent(EventHandler fn)
  8: {
  9:this.Events.AddHandler("MyEvent", fn);
 10: }

The reason we need to derive from Sys.Component is that Sys.Component gives us the Events property. Events is the container for all our events. New ones will be dynamically generated within that container. Let’s see a simple property we can build to easily get the event back when we want to invoke it.

  1:private EventHandler MyEvent
  2: {
  3:     get
  4:     {
  5:return (EventHandler)this.Events.GetHandler("MyEvent");
  6:     }
  7: }

All of this is well documented. The hard part is. Now I have the event how do I call it with Script#? You might start looking for invoke or apply syntax (which I did. But the answer is quite simple. The EventHandler is a function/method that you can call directly like this:

  1: EventHandler evnt = this.MyEvent;
  2: evnt(sender, new EventArgs());

BTW, you can do the same type of thing with delegates... they’re just simp0le functions.

I hope that helps someone...

[I really need to write a fuller post on building Behaviors with Script# (in case you don’t realize Behaviors are the foundation of ASP.NET Ajax Extender Controls).]


ReSharper 4.0 Beta!

22 May 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

I hadn’t seen this mentioned anywhere else. ReSharper 4.0’s Beta has now been released.

This is by far my favorite tool in my arsenal. I find how good of a C# programmer I really am when I have to develop without it.

The latest version has been updated for C# 3.0 (VS 2008 version). I could copy the rest of the feature list, but you can go read yourself. I have been using the EAP bits since right before the Beta Release Candidate and it appears to be really solid with the last couple of drops.


Papa to write Silverlight2 book

16 May 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

My buddy JP (John Papa) is writing a Silverlight2 book. See his blog here and here for more info. JP is known for his DataPoints column in MSDN magazine (and he is an MV, a former co-worker, and former co-blogger... SO, I read his blog).

I found this out a day after I visited the Manning site and purchased to EAP Silverlight2 books. I wish I had known I would have seen what I could do to purchase an early release of JP’s book.

Needless to say I expect John’s book to be really good. I know that he’s an awesome communicator, and has been heavily in this whole XAML space for a while.

I won’t write about my newly-purchased Manning books yet (especially since this is a post where I push John’s book).


Silverlight2 Programming: The Designer Rule

13 May 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

I’m starting a new series on Silverlight2. I am currently building a little SL2 prototype, and as I am learning things I thought I would write them down here.

The first rule deals with working with Designers. It is stated as such.

"Prefer XAML code to CLR/DLR code when it comes building interfaces"

Note the word "prefer" here. That word means "usually", "normally", or "unless there is an exception."

This is best explained by some C# code I saw the other day. It looked something like this:

  1:string ElementX = @"<div class='twocolumndiv'><span class='singlecolumn'>{0}</span><span class='singlecolumn'>{1}</span>";

The problem with the above code is that you’ve embedded it into your code. It’s effectively buried. If someone else needs to change this template to say add a field or to make changes in any manner, they are scanning the code looking for this (provided they know where to look); this will be the cause of much swearing and maligning of your name.

To make matters worse, if you have a web designer you have effectively removed their visibility to this code (maybe this point is made a little sharply; I know some web designers who would be scanning the code as well, but they wouldn’t be happy).

So how does this relate to SilverLight 2? Simple, you should try to avoid instantiate controls on your Silverlight views (pages??) that a designer has no visibility to (in other words, using a UserControl that has an associated XAML is fine, but instantiating a new UserControl and throwing a new layout and a bunch of text boxes should be done with great care... you should know why you did it that way).