GridView must be placed inside a form tag with runat=server

I was creating an online test and I wanted to email the test results by topic to an email distribution list. I have a panel which has two child controls, a label with an overall % correct and a gridview with percentages by topic.

A few simple lines of code would typically handle this:

string listRecipients = ConfigurationManager.AppSettings["candidateTestEmailList"].ToString();
StringBuilder sb = new StringBuilder(2000);
pnlResults.RenderControl(new HtmlTextWriter(new System.IO.StringWriter(sb)));

//---------------------------------------------------------------------
// Send to the mail handler class
//---------------------------------------------------------------------
MailHandler mh = new MailHandler();
mh.SendMail(listRecipients, "Test Results " + tbName.Text, sb.ToString());

But I was getting the error...Gridview must be placed inside a form tag with runat=server. And of course it is, and the panel and the label are not throwing a similar error. I found this nifty fix:

public override void VerifyRenderingInServerForm(Control control)
{
return;
}

found it here: http://blogs.x2line.com/al/archive/2004/10/08/576.aspx

and it worked like a charm. I didn't spend more time investigating which controls require the fix, but if I see the error, I know where to start. Thanks Anatoly!

Blow by Blow Heavyweight Fight -Marriage of Yahoo API Widget with ASP.Net 2.0

Ok, I spent the last 2 hours of my life implementing a really simple html rich text editor using the Yahoo Javascript API (it's a Widget in beta - look here: http://developer.yahoo.com/yui/editor/) with my .Net 2.0 website.

When I say really simple, that was the theory, the reality was a little different. The problem was, embarrassed to admit this, our job postings and our press releases are static text on our website and when HR comes up with a new posting, it takes a developer time to release a new page. So, I want to free up our developers from spending time on administrative tasks such as these. Duck soup, right? Well, I also wanted to get my feet wet with some of the new widgets in the Yahoo Javascript API library...two birds with one stone!

I already have a project open in my VS2005 IDE, so I created a new page and copied and pasted my Yahoo code in. That took all of 5 minutes. The control that sees all the action is a textarea. I took the default markup from Yahoo and added runat=server attribute; this is all you need to expose your HTML controls server-side. Here are the steps I'm going to take in my code-behind to hook up this control to my html txt job postings files:

1. Pass in my job id in my query string; this id will be the name of the txt file without the extension.
2. Use the System.IO namespace.
3. Use the StreamReader to get the contents of the text file and place it in the text area.
4. Use the StreamWriter to get the contents of the text area and write it to the file.
5. I have the ability to overwrite the original file or create a new file, but that is just a detail.

This was the code for the Page Load event:

if (!IsPostBack)
{
//read query string and include a job if one exists
try
{
if (Request.QueryString["id"] != null)
{
job = Request.QueryString["id"].ToString();
//get the contents of text file
msgpost.Value = GetJobFileContents(job);
}
else
{
btnUpdateJobPosting.Visible = false;
}
}
catch (Exception ex)
{
msgpost.Value = ex.Message;
}
}

I also needed two supporting methods to do the Getting and Setting of the text file value:

protected string GetJobFileContents(string job)
{
string path = Server.MapPath("../jobs/");
path += job + ".txt";

StreamReader sr = new StreamReader(path);
string strContents = sr.ReadToEnd();
sr.Close();

return strContents;
}

protected void SetJobFileContents(string job)
{
string path = Server.MapPath("../jobs/");
path += job + ".txt";

StreamWriter sw = new StreamWriter(path, false);
sw.Write(msgpost.Value);
sw.Close();
}

Adding all this to the code behind took about 15 min. Then I hooked up my click events, I had two buttons, one for Updating and one for saving a new file with a textbox to put in a filename.

At this point you may be asking why I'm using server-side code with a javascript API. Well, to write a file to the server, you have to use server-side code. I can execute a server-side function with JSON using AJAX on the client, but that's more work than just using the native .Net postback events. The only reason NOT to use the postback events is to minimize round trips to the server (we've already said we have to go to the server!) or to give the user a better experience without an entire page refresh...very valid in most cases, but not in mine; this control takes up the whole page, it's the raison d'etre (raze-on det: reason for being ) of the page.

So yeah, I took the easy road and didn't really go through my paces with the new API, so the payback was, YES, it didn't work! All the events were handled properly, executed perfectly, as planned, files were read, files were saved, but no changes were reflected. Putting a breakpoint on the sw.Write(msgpost.Value) line revealed that the value of the textarea was the old, unedited value. I tried changing the property I was reading, using InnerText and InnerHtml instead of Value, but they all gave me the same data. I also tried reading the Request object with no luck, it also held the old, before-edit value.

I remembered back in the days of 1.1 where the autoeventwireup used to execute all the code twice so I stepped through the code from start to finish to determine that I was NOT reading from my file and overwriting the changes with the old text. My whopping 20 lines of c# code were doing exactly what i wanted. So I commented out my API code on the client (aspx), and made it a plain textbox, and VOILA, I was getting exactly what i wanted, but my rich text editor was gone. Now I actually had to read the documentation to see what my options were.

I found this little property:

handleSubmit -
Boolean

Config handles if the editor will attach itself to the textareas
parent form's submit handler. If it is set to true, the editor will attempt to
attach a submit listener to the textareas parent form. Then it will trigger the
editors save handler and place the new content back into the text area before
the form is submitted.

Default Value: false

So I changed the value to true, and we got some good news and we got some bad news. Good news is that the value of the textarea now reflects the changes made, but the bad news is my buttons now fire the Page_Load event, but not the click events. So now I'm two hours into what I planned to be a half-hour quickie, so I just threw in a hack. I hooked up the following to the else block of my !IsPostBack check:

else
{
//we're saving the contents
try
{
if (tbJobPosting.Text.Length > 0) //we're writing to a new file
{
//remove .txt if it's in the filename
job = tbJobPosting.Text.Replace(".txt","");

//set the contents of text file
SetJobFileContents(job);

//redirect to page
Response.Redirect("../jobs/jobposting.aspx?id=" + job);
}
else //we better have a query string
{
if (Request.QueryString["id"] != null)
{
job = Request.QueryString["id"].ToString();
SetJobFileContents(job);
}
}
}
catch (Exception ex)
{
lblUserMessage.Text = ex.Message;
}
}

It isn't pretty, but it works. It's not even the best, free, rich-text editor out there, and I'm sure I'll be replacing it with something else, but I learned some interesting things! Oh, and if you're going to be allowing html content in your postback, don't forget to add validateRequest="false" to your Page directive, and make sure you're taking care of the security risk of doing so.

Quote for the Week

Our company CEO dropped a book excerpt by my desk on Monday. It's from the book "Fierce Conversations" by Susan Scott. From the excerpt, it looks like a great read, but my disclaimer here is that I have not read the entire book, so proceed at your own risk.

One of the quotes from the book was immediately compelling to me, so much so that I cut it out and pasted it on my computer.

"The person who can most accurately describe reality without laying blame will emerge the leader."

There was more description around this point, but the power of the statement hits home without it. In my consulting world, we have a sunset review once a project phase has been completed. There is value to be gained from an analysis of what we did right, but the time and passion is always spent dissecting what went wrong, and the close cousin, who is to blame. The ability to recognize our mistakes and to learn from them is critical in any effort to improve a process, but our need to place the blame undermines trust and infuses a group of people who once acted as a team with a sense of isolation and a motive for CYA.

One of the reasons this was poignant to me is that I'm coming off a rather painful project completion, and I was challenged by the statement and realized that I wasn't exhibiting this critical characteristic of leadership, and yet by my project role and my own self-assessment I am a leader. My takeaway: Everything can be improved, even me!

Clearing Items in Repeater (or other) Control in .Net 2.0

You might notice that a repeater does not have an Items.Remove() or an Items.Clear() or even an Items[i].Remove() where you can loop through the collection and remove them one at a time. Nope, clearing a repeater is even easier than that.

I have a search control that dumps the results in a repeater, and to clear the results between search, I use the following line in my search click event:

myRepeater.DataSource = null;

whoop there it is :)

Date Validation in .Net 2.0

All of my input date fields require two things in the validation world of 2.0:
- AJAX MaskedEditExtender
- Range Validator

What does the MaskedEditExtender give you? Only numbers are allowed and the
_ _ / _ _ / _ _ _ _ appear magically when the text field obtains focus. Here's what it looks like in your aspx source view:

<cc1:MaskedEditExtender ID="MaskedEditExtender3" runat="server" TargetControlID="txtBrideBDay"
Mask="99/99/9999"
MessageValidatorTip="true"
OnFocusCssClass="MaskedEditFocus"
OnInvalidCssClass="MaskedEditError"
MaskType="Date"
InputDirection="LeftToRight"
AcceptNegative="Left"
DisplayMoney="None"
>
</cc1:MaskedEditExtender>

The key fields to look at here are the mask and the mask type. The date mask only allows for numbers and the /. If you haven't added the AJAX toolkit to your webprojects, go here http://www.asp.net.

Now for the second piece. When you want a date to fall in a certain range, for example, scheduling an appointment, obviously the date needs to be in the future. Add a RangeValidator to your text field, select a validation type of Date, and put in your minimum and maximum values. For my application, this is what my RangeValidator looks like:

<asp:RangeValidator ID="RangeValidator1" runat="server" ControlToValidate="txtWeddingDate" Display="None"
ErrorMessage="Wedding Date cannot be in the past." Type="Date" MaximumValue="1/1/2050" ValidationGroup="GroupContactInfo"></asp:RangeValidator>

You can see that I don't care very much about the maximum date, setting it waaaaay in the future, and I haven't set a MinimumValue at all. This will throw a runtime error as both values are required for a RangeValidator. I've done this because future is not a definite date, it's dynamic based on the date the user is filling in the form. So I have to add it dynamically, which I've chosen to do in code-behind the first time the page loads:

if (!IsPostBack)
{
RangeValidator1.MinimumValue = DateTime.Now.ToShortDateString();
}

You can also put the value in the aspx page (which won't require compiling to change) with MinimumValue="<% =DateTime.Now.ToShortDateString() %>".

As always with the special validators, a RequiredField validator is needed for the RangeValidator to kick in.

Onward validation soldiers!

Aspdotnetstorefront Menu

Some things are easier than you think they're going to be, and that just makes my whole day! So every single client we've had has requested the top categories go horizontally across the top in the menu instead of vertical submenus under Category, and to accomodate this, we've hard-coded the menus in menuData.xml in the skins directory.

What we lose here is the dynamic control of the menus for our clients, meaning they have to touch an xml file in addition to setting up the categories, and i don't know many product managers who speak xml.

So what I found was a curious line of code in the templatebase.cs file in app_code. Look at the Page_Load function and the section commented "// Find Categories menu top" and the line which starts with a call to AddEntityMenuXsl. See the final parameter being passed into that method is string.Empty. Well, when i look at AddEntityMenuXsl, I see that we have a piece of code that allows us to add a ROOT level element if the parameter length is greater than 0. So I just made my method call look like this:

AddEntityMenuXsl(doc, "Category", AppLogic.CategoryEntityHelper.m_TblMgr, mNode, 0, "1");

and VOILA! I now have a dynamic menu with the categories across the top! With just a little itty bitty code change. Some days programming is berry berry good to me :)

Specified string is not in the form required for an e-mail address

If you have recently moved from the System.Web.Mail (.net 1.1) to System.Net.Mail (.net 2.0), you might get this error message when sending in a string of mail recipients, and when debugging, the emails look good to you! The reason is the delimiter. I cannot imagine what twist of fate movitivated the Microsoft Class gods to switch a standard on us, maybe it was just to keep us on our toes, but they did. We used to delimit our email addresses (multiple to's, cc's, bcc's, etc) with semi-colons (;) as we do in outlook, but that no longer works, now the class only accepts the comma (,) as the address delimiter. Go figure.

So, if you have a large established code base, and you want to upgrade your mail class, just one class that you use for ALL your applications, what do you do to minimize your rework? My advice is to use the string replace function and just replace every instance of semicolon with a comma. That will handle the old code passing in semicolons as well as the new code passing in commas. Then you have one place to make the update and you can leave your legacy code alone.

If you are NOT using a single mail handler class across your applications, then you're working too hard!