If you getting this error while opening an existing project in VS.Net 2003, then please check the < project > .csproj.webinfo file.
< urlpath="http://........"> path should be match with your browser path.
Saturday, April 11, 2009
.Net 2003 existing project opening issue
If you getting this error while opening an existing project in VS.Net 2003, then please check the < project > .csproj.webinfo file.
< urlpath="http://........"> path should be match with your browser path.
Thursday, July 24, 2008
Compare Time using Custom Validator
Hi,
In ASP.Net, you can use Compare Validator to compare Date but you can't compare the Time.
For that you need to write a JavaScript function and should be called in the property 'ClientValidationFunction' of Custom Validator.
You can do it by writing code in CodeBehind, but you have to be patient for postback.
So, the code you will write InLine is :-
In ASP.Net, you can use Compare Validator to compare Date but you can't compare the Time.
For that you need to write a JavaScript function and should be called in the property 'ClientValidationFunction' of Custom Validator.
You can do it by writing code in CodeBehind, but you have to be patient for postback.
So, the code you will write InLine is :-
<head runat="server">
<title>Compare Time</title>
<script language="javascript" type="text/javascript">
function compareTimes(sender, args)
{
var difference = 0;
//Get the current date
var dd= new Date();
//Set the start time and end time in the format: 'MM/dd/yyyy textvalue'
startTime = new Date(dd.getMonth()+1 +"/"+dd.getDate()+"/"+dd.getFullYear()+" "+document.getElementById('<%=txtStartTime.ClientID%>').value);
endTime = new Date(dd.getMonth()+1 +"/"+dd.getDate()+"/"+dd.getFullYear()+" "+document.getElementById('<%=txtEndTime.ClientID%>').value);
//Compute difference and then convert to minutes
difference = endTime - startTime;
minutes = Math.round(difference/(1000*60));
//If the result is negative or zero,
if (minutes<=0)
{
//show error
args.IsValid = false;
return;
}
//Otherwise pass the error
args.IsValid = true;
}
</script>
</head>
<body>
<form id="form1" runat="server">
<div>
Start Time: <asp:TextBox ID="txtStartTime" runat="server" </asp:TextBox>
<br />
End Time: <asp:TextBox ID="txtEndTime" runat="server"></asp:TextBox>
<asp:CustomValidator ID="CustomValidator1" runat="server"
ControlToValidate="txtEndTime" ErrorMessage="Start Time can't be greater than or equal to End time" ClientValidationFunction="compareTimes">
</asp:CustomValidator>
<br />
<asp:Button ID="btnSave" runat="server" OnClick="btnSave_Click"
Text="Save" />
</div>
</form>
</body>
Tuesday, June 3, 2008
AssociatedControlID Property of Label Control
In ASP.Net Label control, there is a property called AssociatedControlID. This property changes the behaviour of the label control after rendering.
e.g. We have a label control...
<asp:Label ID="lblSearch" Text="Search" runat="server" />
After running the page, go to so View --> Source... and you will get like this :
<span id="lblSearch">Search</span>
This means label contol render to a simple html element.
So, after adding the AssociatedControlID property and taking a contol (I'm taking a text box) to be associated...
<asp:Label ID="lblSearch" Text="Search" runat="server" associatedcontrolid="txtSearch"/>
<asp:textbox id="txtSearch" runat="server"/>
Now run the page and go to View --> Source...You will find something different.
<label id="lblSearch" for="txtSearch">Search</label>
<input id="txtSearch" name="txtSearch">
Now the Label control rendered a
e.g. We have a label control...
<asp:Label ID="lblSearch" Text="Search" runat="server" />
After running the page, go to so View --> Source... and you will get like this :
<span id="lblSearch">Search</span>
This means label contol render to a simple html element.
So, after adding the AssociatedControlID property and taking a contol (I'm taking a text box) to be associated...
<asp:Label ID="lblSearch" Text="Search" runat="server" associatedcontrolid="txtSearch"/>
<asp:textbox id="txtSearch" runat="server"/>
Now run the page and go to View --> Source...You will find something different.
<label id="lblSearch" for="txtSearch">Search</label>
<input id="txtSearch" name="txtSearch">
Now the Label control rendered a
Monday, May 26, 2008
Get the current version of ASP.Net
We can get the current version of ASP.Net running in our system by executing the following code on page load event.
protected void Page_Load(object sender, EventArgs e)
{
//Get the current version of asp.net running in your system
Response.Write(System.Environment.Version.ToString());
}
protected void Page_Load(object sender, EventArgs e)
{
//Get the current version of asp.net running in your system
Response.Write(System.Environment.Version.ToString());
}
Monday, November 12, 2007
Server.Transfer() Vs Response.Redirect()
Server.Transfer Vs. Response.Redirect
If you read a lot of industry magazines and ASP.NET code samples, you may find that, although the majority use Response.Redirect to send the user to another page, some seem to prefer the rather mysterious-sounding Server.Transfer. So, what's the difference?
Well, Response.Redirect simply sends a message down to the browser, telling it to move to another page. So, you may run code like: Response.Redirect("WebForm2.aspx")
orResponse.Redirect(http://prfkrushna.blogspot.com)
to send the user to another page.
Server.Transfer is similar in that it sends the user to another page with a statement such as Server.Transfer("WebForm2.aspx"). However, the statement has a number of distinct advantages and disadvantages.
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
For example, if your WebForm1.aspx has a TextBox control called TextBox1 and you transferred to WebForm2.aspx with the preserveForm parameter set to True, you'd be able to retrieve the value of the original page TextBox control by referencing Request.Form("TextBox1").
This technique is great for wizard-style input forms split over multiple pages. But there's another thing you'll want to watch out for when using the preserveForm parameter. ASP.NET has a bug whereby, in certain situations, an error will occur when attempting to transfer the form and query string values. You'll find this documented at http://support.microsoft.com/default.aspx?id=kb;en-us;Q316920.
The unofficial solution is to set the enableViewStateMac property to True on the page you'll be transferring to, then set it back to False. This records that you want a definitive False value for this property and resolves the bug.
So, in brief: Response.Redirect simply tells the browser to visit another page. Server.Transfer helps reduce server requests, keeps the URL the same and, with a little bug-bashing, allows you to transfer the query string and form variables.
Top Tip: Don't confuse Server.Transfer with Server.Execute, which executes the page and returns the results. It was useful in the past, but, with ASP.NET, it's been replaced with fresher methods of development. Ignore it.
If you read a lot of industry magazines and ASP.NET code samples, you may find that, although the majority use Response.Redirect to send the user to another page, some seem to prefer the rather mysterious-sounding Server.Transfer. So, what's the difference?
Well, Response.Redirect simply sends a message down to the browser, telling it to move to another page. So, you may run code like: Response.Redirect("WebForm2.aspx")
orResponse.Redirect(http://prfkrushna.blogspot.com)
to send the user to another page.
Server.Transfer is similar in that it sends the user to another page with a statement such as Server.Transfer("WebForm2.aspx"). However, the statement has a number of distinct advantages and disadvantages.
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
For example, if your WebForm1.aspx has a TextBox control called TextBox1 and you transferred to WebForm2.aspx with the preserveForm parameter set to True, you'd be able to retrieve the value of the original page TextBox control by referencing Request.Form("TextBox1").
This technique is great for wizard-style input forms split over multiple pages. But there's another thing you'll want to watch out for when using the preserveForm parameter. ASP.NET has a bug whereby, in certain situations, an error will occur when attempting to transfer the form and query string values. You'll find this documented at http://support.microsoft.com/default.aspx?id=kb;en-us;Q316920.
The unofficial solution is to set the enableViewStateMac property to True on the page you'll be transferring to, then set it back to False. This records that you want a definitive False value for this property and resolves the bug.
So, in brief: Response.Redirect simply tells the browser to visit another page. Server.Transfer helps reduce server requests, keeps the URL the same and, with a little bug-bashing, allows you to transfer the query string and form variables.
Top Tip: Don't confuse Server.Transfer with Server.Execute, which executes the page and returns the results. It was useful in the past, but, with ASP.NET, it's been replaced with fresher methods of development. Ignore it.
Subscribe to:
Comments (Atom)