The UpdateProgress control is a very handy control meant for use in conjunction with an ASP.NET UpdatePanel. The UpdatePanel is an ajax control that makes it very easy to update part of a page using an ajax postback rather than a full postback. This avoids page flicker and also leaves the page not in a postback state, that is, a subsequent refresh of the browser won't force a postback. The UpdateProgress control is desinged to make it easy to show some markup while the update is happening to give the user a visible cue that something is happening. So a typical trick is to show an animated working indicator something like this 

So you would add the UpdateProgress control inside the UpdatePanel something like this:

<asp:Button ID="btnSavePreferences" runat="server" />
<asp:UpdateProgress ID="progress1" runat="server" AssociatedUpdatePanelID="UpdatePanel1">
<ProgressTemplate>
<img src='<%= Page.ResolveUrl("~/Data/SiteImages/indicators/indicator1.gif") %>' alt=' ' />
</ProgressTemplate>
</asp:UpdateProgress>

The Problem - Block Rendering instead of Inline Rendering

The problem is that the UpdateProgress control renders as a div element which is a block element rather than an inline element, so instead of rendering the indicator right next to your button, it renders it below your button on a new line. In some cases that may be ok, but if you really want the indicator to just be right next to the button it's a problem. I came across this situation recently in my work on mojoPortal and I really wanted to show the indicator in the same line as the button, it gave a bad effect for the indicator to jump below the button. So I did some searching on the internet and found a number of people complaining about this problem and a few less than satisfactory suggestions for solving it.

• A post on the ASP.NET Forums
• ASP.NET Resources post - suggested a way to make it render in the middle rather than below but not really what I was after.
• The last comment on the above post suggested using !Important in the css to force inline rendering. I'm not sure if that really works because the javscript associated with the UpdateProgress sets it to block when it shows the content. Also, the !Important is not used by IE 6 unless in standards compliant mode which is not the default and not commonly used in IE 6.
• James Van Klink suggested another solution, of wrapping the UpdateProgress inside a span and use absolute positioning on the span. However this produces invalid markup, you are not supposed to nest block elements inside inline elements.
• Another solution was posted on stackoverlfow.com, but it seems less elegant than I would like.

So, in summary, the problem is that it renders as a div which is a block element and the javascript associated with the control changes from display:none; to display:block when the UpdatePanel is updating.

The Solution- Borrow The UpdateProgress control from the Mono Project and modify it.

What I really wanted was to make the UpdateProgress control render as a span which is an inline element and I wanted the javascript to toggle between display:none; and display:inline;. Often, when I face a situation where an ASP.NET control cannot be coerced into rendering or behaving as I would like, I have found that I can borrow the Mono Project implementation of the ASP.NET control and modify it to meet my needs. Sometimes its more difficult than others to use this approach depending on what mono internals it may be using, but in this case it was fairly easy.

First I grabbed the UpdateProgress.cs from the Mono source code and added it to my project as UpdateProgressSpan.cs and changed the namespace to match my own project. Then it was fairly simple to change the rendering to use a span instead of a div. However, the problem still remained that the javascript would set the display to block which would still make the span render as a block just like a div. So I scrounged around in the javascript for ms ajax and found the relevant part for UpdateProgress. I copied it into my own javascript file, changed the namespace, and modified it to use display:inline instead of display:block.

The only changes I had to make in my UpdateProgressSpan.cs were:

1. In OnPreRender I had to tell it about my javascript like this:

ScriptReference SRef = new ScriptReference();
SRef.Path = "~/ClientScript/ajaxupdateprogressspan.js";
ScriptManager.Scripts.Add(SRef);
ScriptManager.RegisterScriptControl(this);

2. In Render, I changed it to use Span instead of div and use inline instead of block.

3. In the GetScriptDescriptors method I changed it from referencing the original ms ajax to use my custom one like this:

ScriptControlDescriptor descriptor = new ScriptControlDescriptor("mojo._UpdateProgress", this.ClientID);

Finally in my page I used my custom control instead of te ASP.NET version like this:

<asp:Button ID="btnSavePreferences" runat="server" />
<portal:UpdateProgressSpan ID="UpdateProgress2" runat="server" AssociatedUpdatePanelID="UpdatePanel1" >
<ProgressTemplate>
<img src='<%= Page.ResolveUrl("~/Data/SiteImages/indicators/indicator1.gif") %>' alt=' ' />
</ProgressTemplate>
</portal:UpdateProgressSpan>

Problem solved, the working indicator displays right next to the button.

If you would like to use this in your project, feel free, here is a .zip with the files.

I was worried at first whether the jQuery Tabs would support right to left layout because when I googled for it I could not find any explnations how to make the tabs layout from right to left. I found a number of people asking about it on mailing lists and forums but no-one offering any answers. So I used Firebug to study the css classes assigned to the elements and figured out the things that need to be overridden to make it layout from right to left. I thought I should post it since clearly there are people looking for hep with this. Its actually very straightforward, you include the normal css for the jquery ui theme, and you add another css file below it in the page (it must be lower in the page in order to override the style settings above it in the jquery ui css). There is only a little css needed because we want to override the minimum possible style settings, this is what is needed:

.ui-tabs { direction: rtl; }
.ui-tabs .ui-tabs-nav li.ui-tabs-selected,
.ui-tabs .ui-tabs-nav li.ui-state-default {float: right; }
.ui-tabs .ui-tabs-nav li a { float: right; }

I tested it with all 18 jQuery UI themes and it worked great. I hope this is helpful to others.

So today I encountered this exception on a new machine running in Medium Trust. Its not always easy to find out what is causing an exception like this because you don't get a lot of information in the stack trace, but I was able to pin it down to System.Web.Extensions.dll which is the MS AJAX library. We include this dll in the /bin folder with mojoPortal releases and in Full Trust this is ideal because we don't care if the dll is installed on the machine or not, but in Medium Trust, this dll can not run from the bin folder, it must be installed in the GAC (Global Assembly Cache) on the server. If it is installed in the GAC, the copy in the /bin folder will be ignored and the one in the GAC will be used. But if its not installed and the machine is configured for Medium Trust it will cause this mysterious SecurityException with System.Configuration.ConfigurationPermission.

So the reason I was never able to reproduce the problem on my development machine was because I already had this installed in the GAC. If you install the ASP.NET 2.0 AJAX 1.0 using  ASPAJAXExtSetup.msi, it installs it in the GAC on your machine. Your only solution to this at a web host is for the host to install it on the server.

I found this blog post by Phil Haack, where he mentioned that using an external config file with log4net could cause this exception and that moving the configuration into Web.config could solve it. Though he later updated that post and now says that it can work with an external file, I figured it was at least worth a try in case it is log4net causing this exception on some installations of mojoPortal. So I move the configuration into the Web.config file and a strange thing happened, the log messages started getting truncated to about 30 characters. So I did some googling for "log4net messages truncated" and found a number of messages about it but no real solution mentioned so I started reading more of the log4net documentation about the PatternLayout. I thought maybe this truncation was related to PatternLayout so I changed the config to use SimpleLayout and sure enough the messages were no longer truncated. But I wanted to use PatternLayout as I have all along if possible. Originally my configuration was like this:

<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger [%property{url}] - %message%newline" />
</layout>

So I started chopping things out to see if any particular setting was the culprit and indeed it turned out to be the [%property{url}] that was causing the problem. It still seems like a log4net bug, but its strange that it only happens when not using an external config file for log4net.

So for me the solution was just to remove that part of the pattern so my current configuration is like this:

<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date %level %logger - %message %newline" />
</layout>

Just figured after all the time I spent figuring this out that I should blog it in case others are having the same trouble.

Now I'm still not sure if moving the log4net configuration into Web.config is going to solve the rogue medium trust issue that happens on some machines. If I can figure that one out it will be worth posting about it as well.

I ran into this strange issue where events were firing twice for postbacks from Firefox but were firing normally when using IE. When you see double postbacks happening in the log, your first thought would be that the impatient user clicked the button twice, but in this case I knew that wasn't true because I was the user and also I have code to disable the button after it is clicked to prevent double postback. There is a very common technique used by many ASP.NET developers to do this. In mojoPortal we have a helper method that encapsulated it so we just pass in the button and text to show when its disabled like this:

UIHelper.DisableButtonAfterClick(
btnUpdate,
Resource.ButtonDisabledPleaseWait,
Page.ClientScript.GetPostBackEventReference(this.btnUpdate, string.Empty) );
 

and the guts of the method look like this:

public static void DisableButtonAfterClick(
WebControl button,
string disabledText,
string postbackEventReference)
{
if (button == null) return;
button.Attributes.Add("onclick", "this.value='"
+ disabledText
+ "';this.disabled = true;"
+ postbackEventReference);
}

The irony of it is that disabling a button inside an updatepanel actually causes double post back if the browser is Firefox. So the very code we are using to try and prevent double postback actually causes it to happen. All the events fire twice, OnInit, PageLoad and the button click event. Very strange indeed. The symptom doesn't happen in IE, and removing the code that disables the button fixes the problem in Firefox and events fire normally again, that is just once. So we are back to the problem of how to prevent the user from clicking the button twice if the button is inside an UpdatePanel. Our old way works in IE (and works in general outside of UpdatePanels) but actually causes double postback in Firefox.

I did some googling and found where someone else has reported this. I also found a free dll that solves it, but its not open source so I can't use it.

I wish I was posting a solution for this problem, but for the moment I've just gone with not disabling the button. If I find a good solution I'll update this post. but thought it worth mentioning for anyone else who is seeing double postbacks in Firefox. I will say my searches found a number of things that can cause double postback in Firefox, so this isn't the only possible cause to consider. For example if a page has an <asp:Image on it and the ImageUrl has not been specified, that apparently also causes double postbacks in Firefox.

Ever since I got new workstation, development has been a joy, productivity is high. Visual Studio solutions load fast, build fast, and debug fast. With 64 bit Vista you can use a lot more ram. I've got 8 gigs now where before 32 bit Vista/XP could only use 3 gigs. I've got a fast dual core processor (if I had it to do over I would spend more and go quad core). Also 10,000rpm drives make a big difference.

I can't even imagine going back to a 32 bit machine for day to day development. If you are struggling with VS on a slow machine its well worth the investment to get a new 64 bit workstation.

When I first tried mojoPortal this morning using Chrome, the FCKeditor wasn't enabled and it was degrading to a plain text area. This turned out to be just a configuration issue in .NET code I had FCKeditor disabled for Safari. FCKeditor has claimed support for Safari for a while now but when I tested it after their initial support announcement it didn't work for me so I disabled it in mojoPortal. Then I kind of forgot about it for a while since I don't use Safari on a regular basis. Its been several upgrades of FCKeditor since I had tested so I tried enableing it again and it worked fine both in Safari and in Chrome.

So then with more poking around testing things in mojoPortal I found a couple of other things that didn't work like my friendly url suggest feature. It turned out that this was easily fixed by upgrading to the new version of Sarissa. Sarissa is a javascript library I use in a few features in mojoPortal and I had not upgraded it in a long time.

My fixes for these things will be in the mojoPortal svn trunk sometime later tonight and I'll be making a new release soon.

I feel a little worried for Mozilla and Firefox. I've been using Firefox for a long time as my main browser but I have to admit Chrome is very appealing and I may not go back to Firefox as my main browser. Of course I'll continue testing in all the major browsers. Some people are complaining that we now have one more browser to test but so far the rendering of mojoPortal has seemed really good so I'm not too concerned about that. I subscribe to the GAWDS (Guild of Accessible Web Designers) mailing list and there was a lot of talk in the last 2 days about accessibility problems with Chrome particulary for assistive technology like screen readers, but word is there will be improvement on that, after all its just a beta. 

I'm sure they will be adding more polish to Chrome, but I would say this beta is a great start. The EULA gives me pause and I hope they change that based on feedback but I give them kudos for the first release. My only other concern is whether use of Chrome is making any more information about me available to google than if I use another browser. If using Chrome meeans sacrificing more privacy than other browsers it won't become my main browser. I also hope that since Silverlight works in Safari, it will also work in Chrome.

I made this post in my blog using Chrome.

I remember when I first got that Samsung clamshell phone on the left, gosh, how long ago was that 1997, 98 99? Somewhere in there I'm sure. I remember being so excited about that phone when I first got it. As a kid I had always fantasized about those communicators they used on Star Trek and when I got this phone it was like the realisation of a childhood dream. I got rid of my land line pretty soon after that and haven't had one since.

I was pretty excited when PocketPC phones first came out. Being a Web Developer, the idea of always having access to the internet wherever my phone worked seemd like a dream. I think I got that phone around 2002 or 2003 and at the time I gave my old phone to my younger brother Frank who lived in North Carolina (I was living in TN at the time). It really wasn't a compelling internet experience, and though I kept it until long after my service contract expired, I got really tired of carrying around that big phone. I mean if you put it in your pocket people were like "hey is that the internet in your pocket or are you just happy to see me?". It was really a phone that needed a belt clip like Batman, but I really wasn't into that belt clip thing.

So then I got the Razr, must have been around 2004 or 2005, again I gave my old PocketPC phone to my younger brother Frank. I was much happier with the Razr, it was slick, it was small, and it was a joy to stop carrying that old boat anchor PocketPC.

Last month I got an iPhone. Its way beyond any phone I ever imagined seeing in my lifetime. Its got a compelling web surfing experience, and yet it fits nicely in your pocket without raising eyebrows. I know a lot of people like a physical keyboard and those folks tend to like Blackberries. I suppose if I was answering a lot of email with my phone I might wish for a real keyboard too. Honestly I haven't yet answered an email with my iPhone. For me its more about knowing whether I have important mail at any time than actually responding to it from my phone. It can usually wait until I'm near a computer again. After all, I'm near a computer about 95% of the time. For me its just another convenient way to service my internet addiction. I work long days and then finally collapse and watch movies at the end of the day when I can no longer keep going. I used to find myself getting up from the couch a lot just to check if any new mail had come in, or see how many people are on mojoPortal.com. Now I don't have to get up off the couch. In some ways I like the Facebook experience better on the iPhone than on a computer. I love having a lot of my music collection in my phone, love the GPS. Its a really great device.

So I thought again whether I should offer my old Razr to my younger brother Frank. The funny thing is, now that I'm living in North Carolina, I find out he never activated or used any of the phones I ever gave him, thats how I'm now able to take a picture of them all together. He hasn't committed to a new phone contract for like eight years now. He's still using this old monstrosity:

We're talking dinosaur phone. Not only that but he relies on this thing for all his communication and he lost the battery charger years ago, so he can only charge it now in his car and he's been doing this for years. I'd say he's way over due for a new phone.

I walk by this sign almost every day when I go for my exercise walks at the park, its always struck me as funny. Today I took this picture with my iPhone.

"The All-New Yahoo! You Must Be A Part Of It To Avoid De-activativation Of Your Yahoo Account.

The All-New Yahoo! Mail Beta Is:
Faster: Fewer steps to get things done.
Easier: Drag & drop organization.
Effortless: Automatically checks email for you.

With the all-new Yahoo! Mail Beta you must fill the Informations Below To Verify Your Account, PleaseThis For Your Benefit. Read Below To Understand More.

Dear Yahoo User,

Due to the congestion of Yahoo users, Yahoo would be shutting down all unused Accounts, You will have to confirm your E-mail by filling out your Login Information below after clicking the reply button, or your account will be suspended within 24 hours for security reasons.

* Username: .................................

* Password: ...................................

* Date of Birth: ................................

* Country Or Territory: .................................

After following the instructions in the above, your account will not be interrupted and will continue as normal. Thanks for your attention to this request. We apologize for any inconveniences.

Warning!!! Whosoever that refuses to update his/her account after two weeks of receiving this warning will lose his or her account permanently.Until then, feel free to visit our online help center at
http://help.yahoo.com/
for answers if you have not already done so."