.NET Student Blog

Change the border color of the controls whose validation fails

kreddi — Tue, 27 Sep 2005 02:21:00 GMT

Ever wondered how you can change the border color settings of the control whose client side validation fails, so you can catch the user attention easily.. Well I did. I tried with the asp.net validation controls given by the .net framework, but none of those validation controls facilitate this. So, I dug around little deeper and found a way to do that. Ofcourse, that involves modifying the WebUIValidation.js file provided with asp.net.

For folks who are wondering what this WebUIValidation.js file does. This is a javascript file provided by microsoft with all the javascript code used by the various asp.net validation controls. This file is found in the "aspnet_client\system_web\1_1_4322" folder under your wwwroot folder

Ok. Lets get to the point here.

Ohh.. by the way, I am assuming we all use ValidationSummary control in our pages to summarise all the validation error messages at one place, if not this may not be much helpful to you, although this trick may give you some clues

Before we begin place the following javascript function somewhere in the WebUIValidation.js file

function changeBorder(id)

{

var control = document.getElementById(id);

control.style.borderWidth = "1px";

control.style.borderStyle = "solid";

control.style.borderColor="red";

}

Now....

Look for the function named ValidationSummaryOnSubmit in the WebUIValidation.js file. This method is used by the validation summary control to iterate through all the invalid controls and output their error messages in certain format

If you look inside the method, you notice that there is a conditional block, which checks to see if the Page is valid..

if (!Page_IsValid) {

......

}

In this If loop, there is a "for" loop, which iterates through all the invalid controls..

for (i=0; i<Page_Validators.length; i++) {

if (!Page_Validators[i].isvalid && typeof(Page_Validators[i].errormessage) == "string") {

s += pre + Page_Validators[i].errormessage + post;

}

In this loop put the following code

changeBorder(Page_Validators[i].controltovalidate);

Now the above for loop would look something like this

for (i=0; i<Page_Validators.length; i++) {

if (!Page_Validators[i].isvalid && typeof(Page_Validators[i].errormessage) == "string") {

/*Your Code -- Not Microsoft's*/

changeBorder(Page_Validators[i].controltovalidate);

/*End of Your Code*/

s += pre + Page_Validators[i].errormessage + post;

}

Thats all.. All of your invalid controls will have a thin red border color when they are invalid

How to prevent default button from firing

kreddi — Sun, 26 Jun 2005 20:47:00 GMT

In my previous Tips and Tricks blog entry I talked about a workaround for ASP.NET not submitting when the Enter key is pressed on the keyboard. Now in this blog entry lets talk about how to prevent the button from submitting the form when you press ENTER key on the keyboard. Its very simple.. we need to capture the keycode from the onkeypress event of the form and return false

This is the code to capture the ENTER keycode...

This is the code to for the form wide onkeypress event.

You could customize this.. If you want to prevent the button to submit only for a particular textbox, you could just capture the onkeypress event for that textbox and but not the whole form

Pressing Enter key does not submit asp.net form

kreddi — Sun, 26 Jun 2005 20:26:00 GMT

This is one of the first problem I encountered after I started working in ASP.NET. The webform does not submit or postback when I click “Enter” key on the keyboard when there is only one textbox on the form. I heard this as a bug in IE. It seem to work as it is supposed to be in FireFox.

So, the workaround for this is to add another input control of type text and make it invisible if you do not want it to, by making its width and height to be set to '0'

How to Prefill password into TextBox web control

kreddi — Sun, 26 Jun 2005 18:14:00 GMT

This is one of the commonly asked question I have seen recently on ASP.NET forums. Logically speaking you shouldnt try to prefill a password textbox field for security reasons. But, if the application size and scope warrant a cheap trick to prefill password field, then keep reading....

Lets say you have a password “pwd“, which you retrived from database of session and you want to assign it to the .Text property of password textbox control.

You would say passText.Text=“pwd“; and run the page. So you expect the password to be prefilled in the password field, when you see the actual page in the browser..But ASP.NET simply ignores it and display's a blank password field (Ofcourse that is exactly what it is designed to do)

Now lets say you want to find a workaround even if it means to compromise on the security.. keep reading..

As you know, we add client side properties with the Attributes.Add() method for web server controls. So to your pasword field.. add the password to the “value“ property. Remember a texbox is rendered as the INPUT html field and the .Text property will become “value“ property for the input control.

passText.Attributes.Add("value", “pwd“);

This will instruct the ASP.NET to assign the password to the value property of the html input control

Even here, as you can see you are just manipulating the html version of this control. ASP.NET does not let you assign a value to a password field from the code behind

Caution: If you try to use this workaround.. keep in mind that anyone can see the password by looking at the html source of the rendered html

Hi Everybody

kreddi — Tue, 21 Jun 2005 21:05:00 GMT

I used to blog @ http://kumarreddi.blogspot.com. I thought of changing the blog to some technology specific site. So, I requested the admin's to provide me with the blogspace in aspadvice servers. And they are kind enough to oblige to my request. Anyway, the posts below this are the posts I made on the previous blog site. I just transferred them from that site. For anybody wondering what's with the hoopla....I am just a rookie blogger

MSDE 2000 install

kreddi — Tue, 21 Jun 2005 21:00:00 GMT

Today I was installing MSDE 2000 Release A on my machine, since our company do not allow us to install SQL Server on our work stations.
I noticed MSDE 2000 Release A does not come with the two highly mentioned sample databases "NorthWind" and "Pubs". But luckily if you have VS.NET 2003, you allready have the sql files for these two databases, you need to run these files against your MSDE instance using osql utility. The following is the sample command to install these two data bases

C:\>osql -E -S (local)\VSDOTNET -i instnwnd.sql

Also, sometimes it gets tricky installing MSDE on our machine. For anyone's information, you should use the following procedure to install MSDE 2000

Open the setup.ini file in ur C:\MSDERelA
Add the lines under the [options]
INSTANCENAME=VSDOTNET
DISABLENETWORKPROTOCOLS=1
SAPWD=urPassword

After saving the setuo.ini file run the setup with these arguments

setup /L*v C:/MSDELog.log

Oh yeah, one more tricky thing is, MSDE setup at times do not notify you that, set up is completed. So, if you are unsure about it, restart the computer and see if the Service Manager starts in the system tray.

Application Domains in .NET

kreddi — Tue, 21 Jun 2005 21:00:00 GMT

In .NET, the primary application boundary is not a process, but Application domain. Lets see some of the differences between these two

Operating System Process

Each process has its own virtual address space, executable code, and data
A windows process cannot directly access the code or data of another windows process
A windows process runs only one application, so if an application crashes, it does not affect other applications
Processes are efficient in isolating applications, but they require expensive IPC mechanisms to communicate
A process is a vary low level operating system construct; the exact behavior of a process is determined by the operating system. Thus a windows 2000 process is very different from a Unix process

Remember, when a processor switches between processes, the processor must save and reset the execution context of the processes. This takes lot of resources

Instead of a process, the basic unit of isolation for running applications in the CLR is an application domain. CLR allows several application domains to run within a single windows process

Application domain:

An application domain is the .NET runtime’s representation of a logical process
Each application domain contains its own set of code, data and configuration settings
An application domain cannot directly access the code or data structures of another application domain
Code running in one application domain cannot affect other application domains. CLR can terminate an application domain without stopping the entire process
Application domain hides operating system’s details of a process. This allows .NET to be ported to a variety of operating systems
Application domains allow the .NET runtime to optimize communication between applications running in the same process where expensive IPC mechanisms are not required

An Application domain can be created using AppDomain class of System namespace. However, in most cases the application domains created and managed by the runtime hosts that execute your code. Runtime hosts provide the environment to run managed code on behalf of the user. The following three runtime hosts come with .net installation
Windows shell
ASP.NET
Internet Explorer

What is the need of extensions in the urls

kreddi — Tue, 21 Jun 2005 20:59:00 GMT

Recently a user asked the following question in the microsoft's asp.net forum

Can I serve the asp.net pages without the extensions, like
http://site.com/page1 instead of http://site.com/page1.aspx

I thought its an interesting post. I thought of writing what is the importance of extensions in the url with respect to IIS.

The first thing that happens, when a user types in a url is, IIS receives the request for the page. IIS looks up at the extension of the url, and then decide what to do with it. Sometimes IIS handles the request by itself, othertimes it has to delegate the work to some other process, as I said its all based on the extension.

If the request is for, lets say for html page or for some image content or some other static content, IIS handles the request by itself.But if the request is for, lets say for a asp page (.asp extension), then IIS forwards this request to asp.dll ISAPI. Then this dll takes over the execution and serves the page back to IIS, which will send the response to the user. Similarly for asp.net pages (.aspx, .asmx, .ascx..), aspnet_isapi.dll handles the request, which will forward the request to the worker process, which will execute the application in an application domain.

So, all this forwarding to isapi dll's would not be possible without extensions in the url.

View State Is Invalid Error message when using Server.Transfer

kreddi — Tue, 21 Jun 2005 20:59:00 GMT

This is a very common error message we get when we use Server.Transfer with the second parameter set to true, which indicates transferring QueryString as well as Form collection, which contains information about the Form elements.
The common workaround we do is to set EnableViewStateMac to false.

But I read in an article today, that when we store sensitive information in the Viewstate, setting EnableViewStateMac to false, opens a big security hole. Microsoft would not suggest doing this. They suggest transferring server control elements in other ways, setting the element accessors as public. See the following article if you want to know what I am talking about
http://support.microsoft.com/default.aspx?scid=kb;EN-US;316920

Session and Cookies

kreddi — Tue, 21 Jun 2005 20:58:00 GMT

I have seen so many posts in newsgroups asking questions related to cookies and their relationship with asp.net session. So, I thought of making a small post explaining the role cookies play in asp.net session

Typical SessionState element in a web.config file looks as follows

<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>

Most of us are pretty familiar with the first three attributes, which simply give the information about where the session state is stored. So, let’s jump to the cookieless="false” attribute

This attribute tells the asp.net whether to use cookies to store the session identifier or not.

Little background
Anytime, you request a page from the web server by making a GET request or POST request, asp.net runs the page in a session. If the session already exists asp.net simply executes the page in that session, if not it would create a new session to serve the request. As you know, asp.net along with many web technologies is state less, i.e. a request has no knowledge of the previous or the next requests. Therefore, asp.net will have no idea if the request you made is the first request, so it needs to create a session for you, or you made a second request, so it needs to use the previously created session. So, there needs to be some mechanism to inform asp.net to use previously created session information if it hasn’t been timed out and not go crazy and create 100 sessions for 100 requests. That is exactly what we are trying to do with the Cookieless attribute in the above sessionState element

Lets look at the two solutions .net provide to solve this problem

First Solution
When you have cookieless="false" we are telling asp.net to store the identifier of the session it created in a temporary browser cookie. So, the next time we make a new request or do a postback within the same browser, asp.net would read this browser cookie and determine that this request belongs to the previously created session. If that session hasn’t timed out, asp.net simply serves the request and use that session information without creating a new session

Caveat
If your browser does not accept cookies and you have cookieless="false", then you are busted. Asp.net would create a new session for every request you make, whether it is a GET or POST request and you wouldn’t be able to use any session information you stored between your requests. The reason for this behavior is, you are telling the asp.net to use cookie to store the session identifier and yet not providing a browser setting which accept the cookies.

So to get around this problem, please adjust your browser security settings to allow cookies. The typical security setting for browser to accept cookies is Medium High

Second Solution
Now the second case , when you have cookieless="true" you are telling asp.net not to use cookies to store the session identifier. So, in this case our poor asp.net gets panicked and mess up with the url’s. A typical url in this case looks as follows

http://www.yourdomain.com/(v5j2hoqkijx0dsqwry1kpojx)/yourPage.aspx

You could see that crazy text appended between your domain name and your page address. As you guessed it is the session id. So, asp.net creates this mangled url’s incase you do not let it to use cookies to store the session identifier. The advantage of this approach is, you are not making any assumptions about the browser behavior, but the disadvantage is the urls are not user friendly and can not be book marked.