Ajax Control Toolkit Calendar doesn’t close when clicking outside the calendar

Just a quick one: if you have a textbox with a Calendar (extender) from the Ajax Control Toolkit and an associated PopupButtonID which is an image, the calendar won’t close when you click outside the popup. Use an input type=”image”or an ImageButton to solve this problem.

Hope this helps.

"AjaxControlToolkit is undefined"

Because we were still using an old Visual Studio 2005 solution which included a Web Site project, it was time to upgrade. We upgraded our Visual Studio 2005 solution to Visual Studio 2010 (and .NET 4.0), converted the Web Site Project to a Web Application Project and then, of course, the AjaxControlToolkit had to follow. I downloaded the latest build from their Codeplex site and updated the references in the different projects. I ran the website, and that’s where things got ugly…

Most pages worked nicely, but there were a few that gave an “AjaxControlToolkit is undefined” error. I removed all references to the AjaxControlToolkit, removed all the old versions of it from my machine, referenced the most recent version again, all to no avail. After Googling* Binging the error I found a LOT of possible solutions. These included:

  • Use the ToolkitScriptManager from the AjaxControlToolkit in stead of the built-in ScriptManager
  • When using the ToolkitScriptManager, set CombineScripts to false
  • When using the ToolkitScriptManager, set EnablePartialRendering to true
  • Clear the browser cache
  • Clear the ASP.NET Temporary Files directory
  • Use a (dummy) control to make sure the JavaScript files have been loaded correctly

Unfortunately, none of these possible solutions helped us with our specific problem. Our problem occurred when we, for instance, set the PositioningMode for a control from custom JavaScript using the AjaxControlToolkit.PositioningMode enumeration. The error was always from custom JavaScript. After looking around a bit more I found one site that mentioned something about changing the AjaxControlToolkit ‘namespace’ in JavaScript.  After playing around a bit I found out that changing the use of AjaxControlToolkit.XXX to System.Extended.UI.XXX provided the solution.

Hope this helps.

* Of course this is a weak attempt at a joke, but fact is that Google (the first 7 or so pages) only pointed me in the direction of the solutions that weren’t solutions for my situation. When I tried Bing for a change, I found something that put me on the right track pretty fast. Kudos to Bing!

Ajax Control Toolkit controls don’t show up in Visual Studio toolbar

Because I stopped working at Avanade and started my own company (this web site is under construction and in Dutch), I had to buy and install a new laptop. Everything went great and I was up and running in half a day. Or should I say half an evening… ;)

The next day I wanted to continue developing a web site we are working on. I needed one of the Ajax Control Toolkit controls, so I added it to my toolbar the way you should go about this (create a separate tab, right click, ‘choose items’, browse for the assembly). Strange enough, none of the toolkit controls showed up in my toolbar. I tried again, restarted Visual Studio and even restarted my computer. All to no avail…
After a while, I checked the ‘Show all’ option for the toolbar, and there were my Ajax controls, all of them disabled (grayed out). And if you think that is weird, read on for the cause of this behavior ;).

After some searching, I found something that I thought could be a solution. Unfortunately this did not solve my problems. Not even after repeating the steps several times. Luckily there were several people that commented on that same post, stating the proposed fix didn’t actually fix the problem. One of them said something about Microsoft wireless hardware being the culprit. I removed the wireless receiver of my Microsoft Wireless Notebook Optical Mouse, and the controls all appeared on the toolbar. Enabled and all…!

Now, whenever I need the Ajax controls in Visual Studio, I do the following:

  • Start Visual Studio (if not started already)
  • Open up a web page or a user control, or at least something you can place an Ajax control on
  • Open up the toolbox (note: no Ajax controls!)
  • Unplug the wireless device and see the controls appear like magic
  • Plug in the device: the controls should stay where they are

Hope this helps some of you…

LinkButton inside UpdatePanel results in full postback, UpdatePanel not triggered

When you dynamically generate a LinkButton in code that will be placed inside an UpdatePanel, you’ll experience that the Click event for the LinkButton results in a full postback in stead of the UpdatePanel being triggered. There’s a rather simpel solution to this problem…

First, let’s take a look at the scenario. Consider this HTML:
There’s a literal control outside of the UpdatePanel. There’s a second literal control inside the UpdatePanel. Besides that, there is a PlaceHolder inside the UpdatePanel, where the generated LinkButton will be placed. The parent control doesn’t have to be a PlaceHolder, it can also be a repeater or something like that.

Next, consider this code:
As you can see, a LinkButton is generated and added to the PlaceHolder in every PageLoad. In the same PageLoad, the literal outside of the UpdatePanel is updated. The literal inside the UpdatePanel is only updated when the LinkButton is clicked. This makes for something like this for the first time the page loads:
and something like this after the LinkButton is clicked:
Because the LinkButton is inside the UpdatePanel, you would think hitting it would trigger the UpdatePanel so only the literal control inside the UpdatePanel gets updated. The fact that the two literals have the same time on it in the ‘after LinkButton clicked’ image, shows that the entire page was posted back.
The problem here is in the fact that the ID for the LinkButton is not set in the code. Weird thing is that when you change the code to generate a normal ASP.NET Button (with or without an ID), the problem doesn’t occur. This has something to do with the fact that both the input rendered for the button and the link rendered for the linkbutton have no ID, but the input control does have a name that can be used to relate events/postbacks to. The link doesn’t have that either, so I’m guessing it has something to do with that.

So the solution is rather simple. Add a line in code where the ID for the control is set (like linkButton.ID = “TestLinkButton”;) After clicking the linkbutton in my example, only the literal in the UpdatePanel is updated. Hooray! ;)

kick it on DotNetKicks.com

Technorati tags: ,,

DropDownList SelectedIndexChanged doesn’t trigger UpdatePanel in SharePoint 2007 SP1

A week ago I had a nice page that was hosted in SharePoint and, among others, contained an updatepanel with a dropdownlist in it. Everything worked, and all was well. Because our testers had found some issues we had delivered two newer versions to our development environment. In the last version they found an issue that wasn’t there before: selecting a different value in the dropdown did not only update the updatepanel, but resulted in a complete postback. My first idea was: that’s an easy one, I’ll check the triggers. Boy, was I wrong…

A few hours later, we had everything working again. But rebuilding the entire usercontrol didn’t solve the issue, and neither did changeing all available settings for all controls ;). Weird thing was it did work when outside of a SharePoint environment. After some extensive searching, I found a post on Brian H. Madsen’s blog, called Using DropDownList with an UpdatePanel in MOSS 2007. As it turns out, SP1 introduces a bug for working with dropdownlists, making that the SelectedIndexChanged event isn’t captured by the update panel. Brian’s post contains the code below which, if placed in the page_load, solves this issue:

if (this.Page.Form != null)
    if (this.Page.Form.Attributes[“onsubmit”] == “return _spFormOnSubmitWrapper();”)
        this.Page.Form.Attributes[“onsubmit”] = “_spFormOnSubmitWrapper();”;

ScriptManager.RegisterStartupScript(this, this.GetType(), “UpdatePanelFixup”,
    “_spOriginalFormAction = document.forms[0].action;_spSuppressFormOnSubmitWrapper=true;”, true);

ModalPopupExtender in SharePoint – part II

As I said earlier, we didn’t test our solution to using the ModalPopupExtender in SharePoint in all situations. Today we made a start to do so. To indicate our successrate: we now use window.showModalDialog with some extra pages…

Lets go through some of the problems we encountered.

  • Placing an UpdatePanel around the entire UserControl (with default settings) makes that the entire UserControl is posted back, even when it is a control inside a nested UpdatePanel that posts back. The ASP.NET controls have no problem with this, but the SharePoint InputFormTextBox set to RichText does. The toolbars are not rendered, and the entire HTML is shown. Setting ChildrenAsTriggers would disable this behaviour (it does with default ASP.NET controls), because in that case only the nested UpdatePanel is posted back. Unfortunately we didn’t get to test that.
  • The SharePoint page layout doesn’t render properly when using the XHTML Transitional doctype. Probably nothing a redesign of the masterpage (and maybe some controls) can’t handle, but it seems you need time and budget for that. ;)
  • The background wasn’t always completely grayed out using the BackgroundCssClass. Sometimes a ribbon of say 10 pixels was shown normal, sometimes the entire background was displayed normal. And clickable! That’s not what we would like to use a modal popup for.

Especially the last problem made us eventually switch back to an oldskool JavaScript solution, although we did mix it with some UpdatePanels. The Ajax modal popup sometimes did its job, but not all of the time. We couldn’t quite put our finger on it. When a solution doesn’t feel stable and there isn’t much time, you should / sometimes have to revert to proven technology. The problems we encountered are solvable, or at least I think so. We didn’t have time to prove they are. At least not this time… ;)

Getting the ModalPopupExtender to work in SharePoint 2007

Getting the ModalPopupExtender from the Ajax Control Toolkit to work (decently) in SharePoint was not exactly a walk in the park. With a default SharePoint installation, the modal popup is partly positioned ‘outside’ of the page (you only see the bottom right part of the popup in the top left corner of the browser). Postbacks are not executed or executed poorly and the page gets garbled up. A possible solution for the positioning of the popup is to set the X and Y property of the ModalPopupExtender. Downside is you never know (for sure) if the popup is positioned inside the visible part of the browser because of things like non-maximized browser, different resolutions and so on.
Today we seem to have solved our issues with the ModalPopupExtender in SharePoint. We haven’t tested it in all scenario’s yet, but we’ll get to that. At this point everything looks the way it is supposed to. And it seems to work, too… ;).

The extra steps we took to make these two play together the way we wanted them to, besides the usual steps to make Ajax work in ASP.NET 2.0, are:

* Because of our setup with close-images that postback (because we have to clear controls and that sort of stuff) and more, we couldn’t use the TargetControlID property for the ModalPopupExtender. Well, we could, but that would result in the background not being displayed properly half the time ;). This can be solved by setting the TargetControlID to a dummy control (like a hidden one) and showing the popup from code.

** We have a usercontrol with several usercontrols in it. This one usercontrol (the parent) was added to a page. The normal (postback) controls on the usercontrols didn’t work after one of the modal popups was shown. And I can image neither would any other ‘normal’ controls on the page, but we didn’t encounter this scenario. The problem was the page would freeze with a message in the taskbar stating ‘The page is busy submitting data to the server’ directly after an Ajax postback. The controls that performed a ‘normal’ postback did nothing: the serverside code just was not executed. We solved this by putting an updatepanel around everything inside the usercontrol. That way the normal controls would postback in an ajaxy way too, apparently solving the ‘The page is busy’ message.

We’ll be testing this solution over the next few days. If any problems pop up, I’ll keep you posted.