replace values in the QueryString key/value pairs

The URL with a  QueryString is something like “apage.aspx?month=10&year=2006&…”, anything in Request.QueryString cannot be changed because it is readonly, but the values of “month” and “year” can be changed as followed:

NameValueCollection nvc = HttpUtility.ParseQueryString(Request.QueryString.ToString());

nvc.Set(“month”, “12″);

nvc.Set(“year”, “2009″);

string newUrl = this.Request.ServerVariables["URL"].ToString() + “?” + nvc.ToString() ;

populate TreeView with DataTable

TreeView can be bound with XmlDataSource and SiteMapDataSource controls (vs2008exp). But the data come up from the database, a strongly typed DataSet. So, manually populate a TreeView from a DataTable object, instead of auto binding:

int currYear = 0;
TreeNode curRootNode = new TreeNode();
int i = 0;

do
{
rw = dt.Rows[i];
if (rw.theYear != currYear)
{
currYear = rw.theYear;
TreeNode root = new TreeNode(currYear);
curRootNode = root;
this.TreeView1.Nodes.Add(root);
TreeNode child = new       TreeNode(Enum.GetName(typeof(ShortMonthName),rw.theMonth) + “. [" +       rw.itemNumber + "]“);
curRootNode.ChildNodes.Add(child);
}
else
{
TreeNode child = new TreeNode(Enum.GetName(typeof(ShortMonthName), rw.theMonth) + “. [" + rw.itemNumber + "]“);
curRootNode.ChildNodes.Add(child);
}
i++;
} while (i < dt.Rows.Count);

Here is the result:

create a TableAdapter method with parameters when using OLEDB

If use the following query script for creating a TableAdapter method, like “GetDataById”, when using OLEDB:

“SELECT * FROM aTable WHERE theID=@id”

an error will happen:

“error in where clause near ‘@’ unable to parse query text”

The solution is to use “?”, instead of “@variablename”, so teh following will succeed:

“SELECT * FROM aTable WHERE theID=?”

GridView’s border setting doesn’t work in IE!

I only tried IE7.0, but it did donot work well if you have this setting in your GridView:

<asp:GridView ID=”GridView1″ runat=”server” BorderColor=”red” BoderStyle=”Solid” BorderWidth=”1px” RowStyle-BorderColor=”blue” RowStyle-BorderStyle=”Solid” RowStyle-BorderWidth=”1px” ……>

<……/>

But using css works:

1. create css class

<style type=”text/css”>
table.GridViewCss  td,th
{
height:25px;
color:#333333;
border:solid 1px #6A8CA5;
border-collapse: collapse;
}

table.GridViewCss
{
height:25px;
color:#333333;
border:solid 1px #6A8CA5;
border-collapse: collapse;

}
</style>

2. use it

<asp:GridView ID=”GridView1″ runat=”server” CssClass=”GridViewCss” ……>

<……/>

Page Life Cycle Events

1. Page_Init: initializing the controls.
2. LoadViewState: restores the View State.
3. LoadPostData: restores the View State.
4. Page_Load: populate and bind data to controls
5. RaisePostDataChangedEvent:
6. RaisePostBackEvent
7. Page_PreRender: make changes to the data contained in controls prior to their rendering.
8. SaveViewState
9. Page_Render: creates the Response object and uses a text writer to write the response stream to the Response.
10. Page_UnLoad: unloaded from the memory, and the Response object is sent to the browser.

Comparing Web Site Projects and Web Application Projects

The following table lists Web project options or tasks and indicates which project model best implements those options.

Option or Task	Web App Projects	Web Site Projects
Need to migrate large Visual Studio .NET 2003 applications	X
Prefer single-page code model to code-behind model		X
Prefer dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).		X
Need to control names of output assemblies	X
Need to generate one assembly for each page		X
Need stand-alone classes to reference page and user control classes	X
Need to build a Web application using multiple Web projects	X
Need to add pre-build and post-build steps during compilation	X
Want to open and edit any directory as a Web project without creating a project file		X

The following table helps you select a project type by describing some of the key differences between Web application projects and Web site projects.

Scenario	Web Application Project	Web Site Project
Project definition	Similar to Visual Studio .NET 2003. Only files that are referenced in the project file are part of the project, are displayed in Solution Explorer, and are compiled during a build. Because there is a project file, some scenarios are more easily enabled:You can subdivide one ASP.NET application into multiple Visual Studio projects.You can easily exclude files from the project and from source code-control.	Web site projects use the folder structure to define the contents of the project. There is no project file and all files in the folder are part of the project.This project type is desirable if you have an existing folder structure representing an ASP.NET application that you want to edit in Visual Studio without having to explicitly create a project file.
Compilation and build outputs	The compilation model for Web application projects is very similar to that in Visual Studio .NET 2003.All code-behind class files and stand-alone class files in the project are compiled into a single assembly, which is placed in the Bin folder. Because this is a single assembly, you can specify attributes such as assembly name and version, as well as the location of the output assembly.Certain other applications scenarios are better enabled, such as the Model-View-Controller (MVC) pattern, because they allow stand-alone classes in the project to reference page and user control classes.	The Build command compiles Web site projects only to test them. To run Web site projects, you deploy source files and rely on ASP.NET dynamic compilation to compile pages and classes in the application.Alternatively, you can precompile the site for performance, which uses the same compilation semantics as ASP.NET dynamic compilation. The ASP.NET dynamic compilation system has two modes—batch mode (the default) and fixed-names mode. In batch mode, many assemblies (typically one per folder) are produced when precompiling the site. In fixed mode, one assembly is produced for each page or user control in the Web site.
Iterative development	To run and debug pages, you must build the entire Web project. Building the entire Web application project is usually fast, because Visual Studio employs an incremental build model that builds only the files that have changed.	You can configure build options Visual Studio 2005 for when you run the site: build the site, an individual page, or nothing at all. In the last case, when you run a Web site, Visual Studio simply launches the browser and passes to it the current or start page. The request then invokes ASP.NET dynamic compilation.Because pages are compiled dynamically and compiled into different assemblies as needed, it is not required that the entire project compile successfully in order to run and debug a page.By default, Visual Studio completely compiles Web site projects whenever you run or debug any page. This is done to identify compile-time errors anywhere in the site. However, a complete site build can significantly slow down the iterative development process, so it is generally recommended that you change the build project option to compile only the current page on run or debug.
Deployment	Because all class files are compiled into a single assembly, only that assembly needs to be deployed, along with the .aspx and .ascx files and other static content files.In this model, .aspx files are not compiled until they are run in the browser. However, when used with Web Deployment Projects (a downloadable add-in to Visual Studio 2005), the .aspx files can also be compiled and included in a single assembly for deployment.Each time you deploy the single assembly produced in this model, you replace the code for all pages in the project.	Both .aspx files and code-behind files can be compiled into assemblies using the Publish Website command in Visual Studio. (Note that the Build command does not create a deployable set of assemblies.) The updateable publish option supports compiling only code-behind files while leaving .aspx files unchanged for deployment.The default mode for precompiling produces several assemblies in the Bin folder, typically one per folder. The fixed-names option produces one assembly per page or user control and can be used to create deployable versions of individual pages. However, the fixed-names option increases the number of assemblies and can result in increased memory usage.
Upgrade from Visual Studio .NET 2003	Because the Web application project model is the same as in the Visual Studio .NET 2003, upgrade is generally simple and will usually not require any restructuring of the application.	The compilation option for Web site projects is significantly different than Visual Studio .NET 2003. A conversion wizard is available to upgrade existing Visual Studio .NET 2003 Web projects to Web site projects. For any reasonably complex Visual Studio .NET 2003 projects, manual fix-up is usually required after the conversion. For most scenarios, it is preferable to upgrade existing Visual Studio .NET 2003 projects to Web application projects in Visual Studio 2005.

[reference]