This is a working C# .NET program that demonstrates how to integrate most of the features of the DataGrid and DataSet in a single project including select, insert, update, delete, confirm delete, sort, filter and page.
Get more here http://www.developerfusion.com/scripts/print.aspx?id=3801
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Tuesday, September 28, 2004
How server form post-back works?
One of the most important features of the ASP.NET environment is the ability to declare controls that run on the server, and post back to the same page. Remember the days of classic ASP? We would create a form which would accept the user's input, and then we would most probably have to create another page that would accept all those inputs, either through HTTP GET or POST, and perform some kind of validation, display and action. Sometimes, even a third page was necessary to perform our actions. This wasted a lot of time and complicated things when you had to make a change. But of course, this is not necessary any more with ASP.NET. There is no need to create second pages that accept the inputs of the first, process them and so on. Form fields and other controls can be declared to run on the server, and the server simply posts the page back to itself and performs all the validation, display and actions. Our life as web developers has become a million times better. But how exactly is this done?
When a control is declared to run on the server, a VIEWSTATE is created which remembers the ID of that control, and the method to call when an action is performed. Submit event calls the JavaScript function __doPostBack (that's 2 underscore symbols in front of it). You do not write this function, instead it is generated by the ASP.NET engine and automatically included in our page. It submits the form to the same page, and accepts 2 arguments:
eventTarget: the control doing the submission
eventArgument: any additional information for the event
At least one control needs to be set to Visible, for the server to generate the __doPostBack function in our page. Even if we have numerous web controls declared to run on the server, but they are all set to Visible=false, then the javascript function will not be included and we will not be able to perform any actions.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
When a control is declared to run on the server, a VIEWSTATE is created which remembers the ID of that control, and the method to call when an action is performed. Submit event calls the JavaScript function __doPostBack (that's 2 underscore symbols in front of it). You do not write this function, instead it is generated by the ASP.NET engine and automatically included in our page. It submits the form to the same page, and accepts 2 arguments:
eventTarget: the control doing the submission
eventArgument: any additional information for the event
At least one control needs to be set to Visible, for the server to generate the __doPostBack function in our page. Even if we have numerous web controls declared to run on the server, but they are all set to Visible=false, then the javascript function will not be included and we will not be able to perform any actions.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
How is the viewstate encoded? Is it encrypted?
No, it isn't encrypted. It's Base64 encoded. By default, there's also a HMACSHA1 digest appended that prevents it from tampering. It's protected with an HMACSHA1 digest computed with the viewstate and a randomly generated 512 server secret so it is tamper resistant.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Do we HAVE TO name the ASP.NET configuration file as web.config?
Yes, if you want ASP.NET to read it. You can store arbitrary stuff for your app elsewhere but you'll have to consume it explicitly.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
How do we handle session across ASP and ASP.NET pages in the same Site?
Unfortunately, they can't share. ASP supports in-proc state only and they run in different processes.If you need to support this, you might want to try keep state in a database and using a cookie to track it.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Asynchronous Programming in Web Services
Callback functions are the way to implement Asynchronous programming in Web
services... We will get into details of this topic sometime but now just an
overview...
A client calls the Begin method on the server object and passes a reference
to the callback method... The asynchronous method on the server object
finishes execution and gives a call back to the method on the client
object... This method in client object now causes the call to End method on
the server object.... The End Method then returns the result to the
client...
Well why would you do such a thing??... The simple reason can be when your
server side execution is really going to take long and you do not want to
wait for all that processing to happen...
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
services... We will get into details of this topic sometime but now just an
overview...
A client calls the Begin method on the server object and passes a reference
to the callback method... The asynchronous method on the server object
finishes execution and gives a call back to the method on the client
object... This method in client object now causes the call to End method on
the server object.... The End Method then returns the result to the
client...
Well why would you do such a thing??... The simple reason can be when your
server side execution is really going to take long and you do not want to
wait for all that processing to happen...
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Tuesday, September 21, 2004
Top questions about Datagrid
Top questions about Datagrid
The DataGrid Web server control is a powerful tool for displaying information from a data source. It is easy to use; you can display editable data in a professional-looking grid by setting only a few properties. At the same time, the grid has a sophisticated object model that provides you with great flexibility in how you display the data.
This paper addresses some of the questions about customizing grid display that are commonly asked in newsgroups, on Web sites, and in other developer forums.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchTopQuestionsAboutASPNETDataGridServerControl.asp
Q) When I try to do an Update from my Datagrid, I keep getting the old/original values. Why?
This is caused by calling DataBind() on the grid before retrieving the updated values. The DataBind() overwrites the updates with the original values. Usually caused by having the initial DataBind() of the grid called on every Page_Load. Solution: call DataBind() only the first time the page is loaded:
Sub Page_Load(s As Object, e As EventArgs)
If Not IsPostBack Then BindGrid()
End Sub
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
The DataGrid Web server control is a powerful tool for displaying information from a data source. It is easy to use; you can display editable data in a professional-looking grid by setting only a few properties. At the same time, the grid has a sophisticated object model that provides you with great flexibility in how you display the data.
This paper addresses some of the questions about customizing grid display that are commonly asked in newsgroups, on Web sites, and in other developer forums.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchTopQuestionsAboutASPNETDataGridServerControl.asp
Q) When I try to do an Update from my Datagrid, I keep getting the old/original values. Why?
This is caused by calling DataBind() on the grid before retrieving the updated values. The DataBind() overwrites the updates with the original values. Usually caused by having the initial DataBind() of the grid called on every Page_Load. Solution: call DataBind() only the first time the page is loaded:
Sub Page_Load(s As Object, e As EventArgs)
If Not IsPostBack Then BindGrid()
End Sub
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
How do I specify more than one parameter for my HyperlinkColumn?
The HyperlinkColumn's DataNavigateUrlFormatString only supports one parameter. If you need more than one, switch to a TemplateColumn with an .
Note: You should always encode values passed into querystring to protect against spaces and special characters.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Note: You should always encode values passed into querystring to protect against spaces and special characters.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
ASP.NET State Management Overview
HTTP is a stateless protocol. Each request is serviced as it comes; after the request is processed, all of the data is discarded. No state is maintained across requests even from the same client.
However, it is very useful to maintain state across requests for certain solutions. ASP.NET enables you to maintain both application state and session state through use of application and session variables respectively.
Learn more about
Application State
Session State
Configuring Session State
here - http://support.microsoft.com/default.aspx?scid=kb;en-us;307598&Product=aspnet
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
However, it is very useful to maintain state across requests for certain solutions. ASP.NET enables you to maintain both application state and session state through use of application and session variables respectively.
Learn more about
Application State
Session State
Configuring Session State
here - http://support.microsoft.com/default.aspx?scid=kb;en-us;307598&Product=aspnet
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
ASP.NET Page Framework Overview
The ASP.NET page framework is a scalable programming model that you can use on the server to dynamically generate Web pages. The ASP.NET page framework is the successor to Active Server Pages
Learn more about
Page Life Cycle
Page Events
Page Directives
Inline Versus Code-Behind Programming Models
here - http://support.microsoft.com/default.aspx?scid=kb;en-us;305141&Product=aspnet
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Learn more about
Page Life Cycle
Page Events
Page Directives
Inline Versus Code-Behind Programming Models
here - http://support.microsoft.com/default.aspx?scid=kb;en-us;305141&Product=aspnet
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
How to use Response.Redirect in C# .NET
How to use Response.Redirect in C# .NET
Use HttpResponse.Redirect
HttpResponse Class
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWebHttpResponseClassTopic.asp
HttpResponse.Redirect Method
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebhttpresponseclassredirecttopic.asp
HttpResponse.BufferOutput Property
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebhttpresponseclassbufferoutputtopic.asp
More here...
http://support.microsoft.com/default.aspx?scid=kb;en-us;307903#7
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Use HttpResponse.Redirect
HttpResponse Class
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWebHttpResponseClassTopic.asp
HttpResponse.Redirect Method
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebhttpresponseclassredirecttopic.asp
HttpResponse.BufferOutput Property
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebhttpresponseclassbufferoutputtopic.asp
More here...
http://support.microsoft.com/default.aspx?scid=kb;en-us;307903#7
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Common Request: Which Data Control should I use?
Common Request: Which Data Control should I use?
Learn about ASP.NET's three controls for displaying data: the DataGrid, the DataList, and the Repeater. Each of these controls has unique traits and associated advantages and disadvantages. When creating an ASP.NET application that displays data, it is important to choose the right control for the job.
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/aspnet-whenusedatawebcontrols.asp
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Learn about ASP.NET's three controls for displaying data: the DataGrid, the DataList, and the Repeater. Each of these controls has unique traits and associated advantages and disadvantages. When creating an ASP.NET application that displays data, it is important to choose the right control for the job.
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/aspnet-whenusedatawebcontrols.asp
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Wednesday, September 01, 2004
Building Custom Controls with ASP.NET
# Developing ASP.NET Server Controls
* http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondevelopingwebformscontrols.asp
# ASP.NET Server Control Samples (short demonstrations of server control authoring tasks)
* http://msdn.microsoft.com/library/en-us/cpguide/html/cpconservercontrolssamples.asp
# Microsoft® ASP.NET QuickStarts Tutorial – Authoring Custom Controls
* http://samples.gotdotnet.com/quickstart/aspplus/doc/webctrlauthoring.aspx
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
* http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondevelopingwebformscontrols.asp
# ASP.NET Server Control Samples (short demonstrations of server control authoring tasks)
* http://msdn.microsoft.com/library/en-us/cpguide/html/cpconservercontrolssamples.asp
# Microsoft® ASP.NET QuickStarts Tutorial – Authoring Custom Controls
* http://samples.gotdotnet.com/quickstart/aspplus/doc/webctrlauthoring.aspx
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Compilation
Technical details on how ASP.NET pages are compiled to native code when requested.
Machine boots.
Request for MyPage.aspx comes in (first time).
MyPage.aspx compiles to an assembly* (we'll call it MyPage.dll* ).
The portions of MyPage.dll that are needed for execution are JITed* to memory.*
Page execution completes. The JITed code stays in memory.
A new request for MyPage.aspx comes in. The page hasn't changed. The JITed code that is still in memory runs.
The source for MyPage.aspx changes.
A new request for MyPage.aspx comes in. MyPage.aspx compiles to an assembly, JITs, and executes. The JITed code stays in memory.
A new request for MyPage.aspx comes in. The page hasn't changed. The JITed code that is still in memory runs.
IIS is stopped and started.
A new request for MyPage.aspx comes in. The page hasn't changed. Because IIS was stopped and started, the JITed code is no longer in memory. The existing MyPage.dll JITs and executes. This new JITed code stays in memory.
The JITing process is similar with any .NET code, including .DLL's in your ASP.NET application and .DLL's and .EXE's in WinForms applications. Since there's no page, and since the assembly is already created, these steps don't take place. Instead, methods in the assembly are JITed to native code in memory when they're called (step 4 above), and unloaded from memory when the calling application (the Windows .EXE, or IIS and the ASP.NET worker process as in step 10 above) is closed.
Please Note:
Step 3: Note that a code file (.CS for C# code, .VB for Visual Basic code or no code) gets created from the .ASPX page first, then this file gets compiled into an assembly (.DLL).
Step 3: The MyPage.dll assembly won't have a friendly name like that. Expect more like "yxgq4-hz.dll". Whatever it's called, it will be under a directory called something like "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files".
Step 4: "JITed" is shorthand for "just-in-time compiled." In .NET, methods from your assemblies are compiled into native binary code when they are called. In ASP.NET, this happens when pages are requested by the web browser--at runtime, and thus, just in time before serving the response. Contrast this with COM components, which must be compiled to binary code ahead of time, before they can be called.
Step 4: This is just a one-time performance hit, and even so, it shouldn't be of concern. In Scott Guthrie's words: "Note that in practice, the cost of dynamic JITing the first access of a page's code is minimal. Because most of the overall page code path actually lives within [.NET] Framework libraries (for example: the code within the page base class, the code within System.Data, System.XML, etc.), the number of instructions generated from your actual code are pretty minimal. Because we can dynamically JIT millions of instructions to native code per second, this one-time cost ends up being noise in the grand scheme of things."
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Machine boots.
Request for MyPage.aspx comes in (first time).
MyPage.aspx compiles to an assembly* (we'll call it MyPage.dll* ).
The portions of MyPage.dll that are needed for execution are JITed* to memory.*
Page execution completes. The JITed code stays in memory.
A new request for MyPage.aspx comes in. The page hasn't changed. The JITed code that is still in memory runs.
The source for MyPage.aspx changes.
A new request for MyPage.aspx comes in. MyPage.aspx compiles to an assembly, JITs, and executes. The JITed code stays in memory.
A new request for MyPage.aspx comes in. The page hasn't changed. The JITed code that is still in memory runs.
IIS is stopped and started.
A new request for MyPage.aspx comes in. The page hasn't changed. Because IIS was stopped and started, the JITed code is no longer in memory. The existing MyPage.dll JITs and executes. This new JITed code stays in memory.
The JITing process is similar with any .NET code, including .DLL's in your ASP.NET application and .DLL's and .EXE's in WinForms applications. Since there's no page, and since the assembly is already created, these steps don't take place. Instead, methods in the assembly are JITed to native code in memory when they're called (step 4 above), and unloaded from memory when the calling application (the Windows .EXE, or IIS and the ASP.NET worker process as in step 10 above) is closed.
Please Note:
Step 3: Note that a code file (.CS for C# code, .VB for Visual Basic code or no code) gets created from the .ASPX page first, then this file gets compiled into an assembly (.DLL).
Step 3: The MyPage.dll assembly won't have a friendly name like that. Expect more like "yxgq4-hz.dll". Whatever it's called, it will be under a directory called something like "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files".
Step 4: "JITed" is shorthand for "just-in-time compiled." In .NET, methods from your assemblies are compiled into native binary code when they are called. In ASP.NET, this happens when pages are requested by the web browser--at runtime, and thus, just in time before serving the response. Contrast this with COM components, which must be compiled to binary code ahead of time, before they can be called.
Step 4: This is just a one-time performance hit, and even so, it shouldn't be of concern. In Scott Guthrie's words: "Note that in practice, the cost of dynamic JITing the first access of a page's code is minimal. Because most of the overall page code path actually lives within [.NET] Framework libraries (for example: the code within the page base class, the code within System.Data, System.XML, etc.), the number of instructions generated from your actual code are pretty minimal. Because we can dynamically JIT millions of instructions to native code per second, this one-time cost ends up being noise in the grand scheme of things."
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
ASP.NET Page Execution
Here I want to explain the basics on what order events and methods get executed during the lifecycle of a request. Its essential to understand this order when debugging what can be complex bugs in Page and WebControl code.
Here's a short exercise that will help you internalize what is happening during the creation and execution of a page. Do this without looking up the answer, and it will really make you think through what is happening. Put the following events in order, assuming the request is a PostBack resulting from a Button click:
Unload
Pre-Render
Handle Postback Events
Dispose
Save State
Load View State
Load
Button Click Handler
Process Postback Data
Initialize
Send Postback Change Notifications
Render
You can lookup the answer in MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcontrolexecutionlifecycle.asp, but realize that at least one of the events is out of order in the documentation.
Consider the events in your Global.asax class on the first request received by an application not yet started:
Authorize Request
Application Start
Authenticate Request
End Request
Page Execution
Begin Request
Session Start
The next time you try to access ViewState during the Init event, you'll know why it doesn't work correctly.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Here's a short exercise that will help you internalize what is happening during the creation and execution of a page. Do this without looking up the answer, and it will really make you think through what is happening. Put the following events in order, assuming the request is a PostBack resulting from a Button click:
Unload
Pre-Render
Handle Postback Events
Dispose
Save State
Load View State
Load
Button Click Handler
Process Postback Data
Initialize
Send Postback Change Notifications
Render
You can lookup the answer in MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcontrolexecutionlifecycle.asp, but realize that at least one of the events is out of order in the documentation.
Consider the events in your Global.asax class on the first request received by an application not yet started:
Authorize Request
Application Start
Authenticate Request
End Request
Page Execution
Begin Request
Session Start
The next time you try to access ViewState during the Init event, you'll know why it doesn't work correctly.
With Best Regards,
Mitesh Mehta
Email : miteshvmehta@gmail.com
http://cc.1asphost.com/miteshvmehta/
Maintaining State Across ASP.Net Pages
We will talk about two standard methods of maintaining state across ASP.Net pages today... The more sophisticated methods will be discussed from tomorrow onwards...
1) Using QueryString : You can pass values of one page to another page using Query strings... This is an old ASP custom but for security reason not always recomended in ASP.Net
2) Using Session : You can also pass values of one page to another by storing them in session... Use of session is pretty simple and we have discussed that earlier as well (Click Here)... But do understand the fact that Session variables are to store user specific information which is unique to each user and not each page... Also do note that if you forget to clean the session variables in the next page you might land up increasing the session size like anything effecting performance of your application...
Other Advance Methods Are :
3.) Using HttpContext/RequestParams with Server.Transfer: We discussed adding to session yesterday, similarly you can add to HttpContext as well and this eliminates the cleaning code required in the next page like the way it is required in Session... There are other advantages too...
If you use Server.Transfer then all your control values are automatically transferred to the next page you do not have to add anything to the context explicitly here rather just access the values in the coming page... The code example will show this more clearly...
If you have certain values other than the above mentioned then you have to do certain special operations to explicitly add them in the first page and retrieve them in the second...
CODE SNIPPET
FirstPage Code:
//These are the special values being added to context
//we will retrieve them in the next page
context.Items.Add("specialVariableName", "specialVariableValue");
//We set the second parameter of Server.Transfer to True this will help
//sending certain values automatically
Server.Transfer("NextPage.aspx", True);
NextPage Code:
string strValueOfFirstPageTextBox;
string strSpeciallyAddedValue;
//Use Request.Params to get values of the standard variables
//which get automatically transferred
strValueOfFirstPageTextBox = Request.Params.Get("firstPageTextBox")
//Use HttpContext to get the values specially added
strSpeciallyAddedValue = context.Items("specialVariableName")
4.) Using Properties with Server.Transfer: Make your first page in such a way that you expose the required values in next page as properties in the first page... Then use Server.Transfer to go to the next page(keep the second parameter as false here, WHY SO WE WILL TALK TOMORROW)... Now in the next page using context handler you can get all the properties of the first page...
I am not writing the first page code as it is just simply adding values into properties and calling Server.Transfer and I believe you all know how to do that...
CODE SNIPPET
NextPage Code:
if(Context.Handler != null)
{
string strInternalVariableOfNextPage;
FirstPage objFirstPage = new FirstPage();
objFirstPage = (FirstPage)Context.Handler;
//Note that SomeValue is a public property of First Page
strInternalVariableOfNextPage = objFirstPage.SomeValue;
}
1) Using QueryString : You can pass values of one page to another page using Query strings... This is an old ASP custom but for security reason not always recomended in ASP.Net
2) Using Session : You can also pass values of one page to another by storing them in session... Use of session is pretty simple and we have discussed that earlier as well (Click Here)... But do understand the fact that Session variables are to store user specific information which is unique to each user and not each page... Also do note that if you forget to clean the session variables in the next page you might land up increasing the session size like anything effecting performance of your application...
Other Advance Methods Are :
3.) Using HttpContext/RequestParams with Server.Transfer: We discussed adding to session yesterday, similarly you can add to HttpContext as well and this eliminates the cleaning code required in the next page like the way it is required in Session... There are other advantages too...
If you use Server.Transfer then all your control values are automatically transferred to the next page you do not have to add anything to the context explicitly here rather just access the values in the coming page... The code example will show this more clearly...
If you have certain values other than the above mentioned then you have to do certain special operations to explicitly add them in the first page and retrieve them in the second...
CODE SNIPPET
FirstPage Code:
//These are the special values being added to context
//we will retrieve them in the next page
context.Items.Add("specialVariableName", "specialVariableValue");
//We set the second parameter of Server.Transfer to True this will help
//sending certain values automatically
Server.Transfer("NextPage.aspx", True);
NextPage Code:
string strValueOfFirstPageTextBox;
string strSpeciallyAddedValue;
//Use Request.Params to get values of the standard variables
//which get automatically transferred
strValueOfFirstPageTextBox = Request.Params.Get("firstPageTextBox")
//Use HttpContext to get the values specially added
strSpeciallyAddedValue = context.Items("specialVariableName")
4.) Using Properties with Server.Transfer: Make your first page in such a way that you expose the required values in next page as properties in the first page... Then use Server.Transfer to go to the next page(keep the second parameter as false here, WHY SO WE WILL TALK TOMORROW)... Now in the next page using context handler you can get all the properties of the first page...
I am not writing the first page code as it is just simply adding values into properties and calling Server.Transfer and I believe you all know how to do that...
CODE SNIPPET
NextPage Code:
if(Context.Handler != null)
{
string strInternalVariableOfNextPage;
FirstPage objFirstPage = new FirstPage();
objFirstPage = (FirstPage)Context.Handler;
//Note that SomeValue is a public property of First Page
strInternalVariableOfNextPage = objFirstPage.SomeValue;
}
Subscribe to:
Posts (Atom)