Retrieve Data from Either the Form or Querystring Object

This may have been known by everyone for quite some time now but it's news to me. Apparently in classic ASP there is an alternative to using Request.Form("key") and Request.QueryString("key"). Instead, Request("key") can be used which will check both the QueryString and the Form with one line of code. If a form value and a querystring value get sent over with the same key, I'm not sure which one take precedence though. If you feel like trying this experiment, please send me the results (I'm too lazy to try it myself).

Access The Page Object From a Separate Class in ASP.NET

I just found this out today and thought you might want it for your notes. For awhile now I've been under the impression that the Page object was inaccessible from a class outside of the codebehind page. Today I found out that I was wrong. To access the Page object you simply need to do the following:


Page page = (Page)HttpContext.Current.Handler;

It would have been alot nicer if they included a property of HttpContext that would work like this: HttpContext.Current.Page, but for some stupid reason they did not do that. Anyway, I know that I was happy to find that out so I thought you might want to know too.

Dynamically Add and Modify Server Side Buttons in an ASP.NET Datagrid or Repeater

Within the last few weeks I was asked about how to dynamically format the output of either datagrids or repeater objects in .Net. My response at the time was to do something like the following:

<%# SomeMethod(DataBinder.Eval(DataItem.Container, "data_column").ToString()) %>

Where SomeMethod() is a server-side method in the code-behind which evaluates the bound-data given to it as a parameter, and returns it in the desired format. In some code that I've used this design, I send SomeMethod, which is called DateFormatter() in my code, two dates and then compare the two dates to see if they are the same. If they are the same then the method returns just the one date in MM/DD format, but if they are different then the method returns the two dates like so, MM/DD - MM/DD.

Recently I found that I had need for something a little bit more robust. I wanted to dynamically create server-side buttons in the repeater object which would have different parameters based on the data to which the item was bound. To do this I created a method and wired it to the OnItemDataBound Event of the Repeater. Here is basically what I did:

Aspx File

<asp:Repeater OnItemDataBound='ItemDataBoundMethod'>
...
<ItemTemplate>
<input type='hidden' id='parameter1' value='<%#DataItem.Container, "data_column").ToString())' runat="server" />
... Some More Hidden Fields ...
<!-- Below I create a button with no parameters and no events wired to it, so that I can set them dynamically in the OnItemDataBound Event-->
<asp:Button id='ButtonTemplate' runat='server' />
</ItemTemplate>
...
</asp:Repeater>


Code-Behind

protected void ItemDataBoundMethod(Object sender, RepeaterItemEventArgs e)
{
//Make sure that this is an item and not a header, footer, etc.
if(e.Item.ItemType == ListItemType.Item e.Item.ItemType == ListItemType.AlternatingItem)
{
//Here I access the hidden fields with the Id that I gave them
string param1 = ((HtmlInputHidden)e.Item.FindControl("parameter1")).Value.ToString().Trim();
...
Button buttonTemplate1 = ((Button).e.Item.FindControl("ButtonTemplate"));
...
...Evaluate the values in the hidden field and then set the properties of the button accordingly...
...
}
}

COM Objects are not destroyed when using Server.CreateObject in Classic ASP (Jscript)

Recently it was discovered that, on a particular ASP page in our application, COM objects that were being created using Server.CreateObject were not being properly destroyed. Actually, I should rephrase that, they weren't being destroyed at all until the component services package was shut down. If I kept task manager open, and watched the mem usage of dllhost.exe, I could see the memory being used by the processed increased each time I hit the page in question, and never decreased. Also, if I went to Administrative Tools -> Component Services and looked at the Objects, Activated, and In Call columns for the COM objects in my package, I could see those numbers ever increasing without decreasing.

The code is written in JScript and looked something like this:

var o = Server.CreateObject("dllname");

/* do stuff... */

o = null; //<--- I thought that this line should cause this object to be destroyed, I was //wrong

After much searching I came across this article: PRB: COM Objects Created in JScript Not Released Immediately. The article basically says that because JScript uses deferred garbage (for performance reasons), it can sometimes delay object destruction (in my case, permanently delay it). The article offers two solutions, the first suggest that a destructor be written for the dll, and the second suggests that the undocumented CollectGarbage() function be used. I chose the latter, simply because adding to the dll would be a bigger inconvenience (aka laziness).

A third suggestion that I would suggest, just based on conjecture from information provided in the article, is to rewrite the code block causing the problem in vbscript, as it is not effected by this problem (no garbage collection).

As for my problem, I'm not entirely sure why the problem occurs on only one page and not the others. My only guess is that on the page that is having a problem all of the COM objects are instantiated (about 14), whereas on most others only one or two objects are created.

The following is my code, after I fixed it:

var o = Server.CreateObject("dllname");

/* do stuff... */

o = null;

CollectGarbage(); // <-- This one little line fixed my problem