Coeamyd's

I just launched a new project at codeplex aiming at the integration of jQuery UI in DotNetNuke: http://jquidnn.codeplex.com/. The first releases are already available in form of DNN module packages containing the core functionality, including infrastructural code to include jQuery and jQuery UI, two web controls for the Tabs and Datepicker widgets, and the smoothness theme.

Also available are module packages for three more themes: Cupertino, UI Darkness and UI Lightness. Further skins are actually quite easy to package and will follow over time, or when someone issues a request for one

So please, start grabbing the releases and giving me feedback.

I just wasted another hour, trying to figure out, what exactly ASP.NET was trying to tell me, when giving me an "ASPNET: Make sure that the class defined in this code file matches the 'inherits' attribute, and that it extends the correct base class (e.g. Page or UserControl)." message on compiling my ascx file.

Ok, so I used a custom namespace, but I've done that hundreds of times, so that shouldn't be the problem. I also had a custom base class inheriting from UserControl. Also, nothing I haven't done before. So what was the issue now?!

I basically retyped everything concerning the namespace and class names in all files, but nothing helped. So I reverted to commenting out my code. This helped me find the issue: I used a

<% if (somethingOrOther) { %> Some code here <% } %>

construct in my ascx-file (Please don't start an argument on whether this is good practice or not. I know it's not the cleanest way to do things, but that is not the concern here ), and actually forgot to put in the closing <% } %>. Ok, my fault, but shouldn't you get a better Compiler message than "ASPNET: Make sure that the class defined in this code file matches the 'inherits' attribute, and that it extends the correct base class (e.g. Page or UserControl)."?!

So, if you encouter this error (and believe me, I've had it more than once due to typos), and are 100% positive you've spelled everything correctly, check for unbalanced parentheses!

Yesterday, I had one of those WTF moments. I had a page with a form for entering two addresses. Both had the same fields, including a RadioButtonList with identical items. Since the items are resourced, I decided to optimize the performance by reusing the ListItems like so:

ListItem[] items = new ListItem[2];
items[0] = new ListItem(this.GetString("salutation.Mister"), "Mr");
items[1] = new ListItem(this.GetString("salutation.Misses"), "Mrs");
this.salutation.Items.AddRange(items);
this.salutation2.Items.AddRange(items);

Simple eh. Everything seems to be ok. And was I amazed, when I tested it, and I always got the SelectedItem to be the one selected in salutation2. I double-checked every location were I was storing the values, in case I forgot to change the field name after copy/pasting. But everything was correct, as far as I could tell. I even checked the values submitted by the browser, they were also correct.

Finally, it hit me: The ListItem has a Selected property, and it is used to find the RadioButtonLists SelectedItem property. And since I reused the items, the first list parses its items on postback, sets the appropriate ListItem's Selected property to true. Same thing happens with the second RadioButtonList. And since the ListItems are used in both lists, the last one wins.

So, I changed my code to look like this:

ListItem[] items = new ListItem[2];
items[0] = new ListItem(this.GetString("salutation.Mister"), "Mr");
items[1] = new ListItem(this.GetString("salutation.Misses"), "Mrs");
this.salutation.Items.AddRange(items);
items = new ListItem[2];
items[0] = new ListItem(this.GetString("salutation.Mister"), "Mr");
items[1] = new ListItem(this.GetString("salutation.Misses"), "Mrs");
this.salutation2.Items.AddRange(items);

Now everything works as it should. So next time, be careful when reusing your ListItems!

I have been using jQuery with DotNetNuke for a while now, and was very happy to finally see it integrated into DotNetNuke. What makes me wonder, is that there is no central method for including it in DNN 4.9.1. The library has been placed into the folder ~/Resources/Shared/scripts/jquery, but the one usage I could find does not use the ClientScriptManager to include the script. Instead, it manually creates a Literal script control. This will cause the script to be included multiple times, if different controls use it simultaneously. Perhaps this will be "fixed" in a future release. Perhaps adding a method to the ClientAPI for including it would be a good solution for a global include mechanism.

Today, I was building a nice little page layout for SharePoint and wanted to use SharePoint DateTimeField control. Since the field I wanted to edit was DateOnly, I set the corresponding property, leaving me with this code:

<SharePointWebControls:DateTimeField runat="server" id="dtfArticleStartDate" DateOnly="true" FieldName="ArticleStartDate" />

Seems fine to me, but ASP.NET did not like it. Or rather, the control did not like it. I got an ArgumentException with the following StackTrace:

 

[ArgumentException: FieldName value is not specified.]
Microsoft.SharePoint.WebControls.FieldMetadata.get_Field() +150
Microsoft.SharePoint.WebControls.DateTimeField.CreateChildControls() +310
System.Web.UI.Control.EnsureChildControls() +87
Microsoft.SharePoint.WebControls.DateTimeField.set_DateOnly(Boolean value) +29
ASP.MYNEWSPAGE_ASPX__2072755151.__BuildControldtfArticleStartDate()

FieldName value is not specified?! As you can see in my code above, it is indeed specified. But the stack trace gives us more information: The exception occurs in the compiled ASPX file.

• ASP.MYNEWSPAGE_ASPX__2072755151.__BuildControldtfArticleStartDate():
  - We are building my DateTimeField control.
• DateTimeField.set_DateOnly:
  - We are setting the DateOnly property.
• FieldMetadata.get_Field:
  - Getting the field is where the exception occurs.

Note my ASPX-code again: I first set DateOnly="true" and then FieldName="ArticleStartDate". Oh my god, this can't be true... The solution is very simple: change the order of the attributes/properties:

<SharePointWebControls:DateTimeField runat="server" id="dtfArticleStartDate" FieldName="ArticleStartDate" DateOnly="true" />

Against all good practices, the SharePoint team actually created a direct dependency between two properties. At least the stack trace directly tells you where things go wrong, so the solution is obvious. Nonetheless, I thought, this was worth noting. It actually made me laugh, when I encountered it. Another one of those nice little pitfalls when working with SharePoint

A newer (beta) version of the FCKEditorProvider for DotNetNuke has been made available: http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/127/threadid/247501/scope/posts/Default.aspx

It finally integrates the newest version of FCKeditor, giving you much better styling support and various other features. So far, my tests have been quite positive with the new version.

One thing to note is the bothering "Red title" style, that is configured by default. If you wish to remove it, you can edit the fckconfig.js files located in the provider's "FCKeditor" and "Custom" folders. Just comment out the line that add the style to FCKeditor's custom styles, and you'll be rid of it.

Regards to Mauricio Márquez for his great work on the integration!

While I was building an ASP.NET user control, I ran across the problem, how to serialize a property as the inner text of the Control in the ASPX-Code. I found a nice attribute named PersistenceModeAttribute, that allows you to specify, how a property is supposed to be persisted. Setting it to InnerDefaultProperty or EncodedInnerDefaultProperty should do the trick, I thought.

But, as I had to find out, this is only part of what needs to be done. There are two more Attributes, that control the parsing of a control: ParseChildrenAttribute and PersistChildrenAttribute. When you use InnerDefaultProperty to persist a property, you must add [ParseChildren(true, "<YourPropertyName>")] and [PersistChildren(false)] to your control's class declaration. Otherwise things won't persist.

It took me a while to find this solution, and I found a nice explanation of things here: http://alvinzc.blogspot.com/2006/10/aspnet-basic-of-custom-server-control_25.html.

Alvin did a really nice job of explaining, what the attributes do. So if you want the details, just visit his blog.

When using ASP.NET membership, you should always be sure to specify the applicationName attribute on all providers. If you omit it, and deploy your database to the web server, you will find, that all your users have vanished (or at least cannot be found). So make sure your web.config looks similar to this:

<membership>
    <providers>
        <remove name="AspNetSqlMembershipProvider" />
        <add name="AspNetSqlMembershipProvider" applicationName="/" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="LocalSqlServer" />
    </providers>
</membership>

After setting the application name, you can start adding users. If you added users before specifying it, they will probably no longer be available.