As you know .NET Framework's System.Web.Script.Serialization.JavaScriptSerializer class can be used to to do C# to JSON serialization and JSON to C# deserialization. When JavaScriptSerializer serializes a DateTime into a JSON string it uses the Local DatetimeKind, unless otherwise specified while creating the DateTime, resulting in a potential problem while deserializing it. The reason is AJAX framework deserializes DateTime value assuming its Kind property is set to Utc format. So if the serialized DateTime is created using a different DateTimeKind deserialization will produce a different DateTime value.
For example assume your Local is GMT+1 and you have serialized the DateTime value "15-May-2011 00:00:00" using JavaScriptSerializer and passed it to a WCF method where you deserialize it. Here deserialization will produce a DateTime with the value "14-May-2011 23:00:00". This is because deserialization assumes the value is serialized using Utc DateTimeKind, which is nothing but GMT time, and it uses the same DateTimeKind.Utc to deserialize it. So it results in a DaTime value which is one hour (remember the Local is GMT+1) less than the original value.
The fix is do something similar to below code snippet before serializing which will make sure DateTimeKind.Utc will be used for serializing the value.
DateTime departureDate = DateTime.SpecifyKind(value, DateTimeKind.Utc);
And finally you will get the correct value after deserialzation in the WCF method or wherever you do it.
Click here to read more.
Tuesday, 10 May 2011
Wednesday, 4 May 2011
How to check whether an element is visible or not using jQuery
jQuery(':visible') - Selects all elements that are visible.
Elements can be considered hidden for several reasons:
* They have a CSS display value of none.
* They are form elements with type="hidden".
* Their width and height are explicitly set to 0.
* An ancestor element is hidden, so the element is not shown on the page.
Elements with visibility: hidden or opacity: 0 are considered to be visible, since they still consume space in the layout. During animations that hide an element, the element is considered to be visible until the end of the animation. During animations to show an element, the element is considered to be visible at the start at the animation.
Below JavaScript is useful if you need to know if a specific object is visible:
if ( $('#elementid').is(':visible')){
// element is visible, do something
}
OR
if ($('#elementid:visible').length > 0){
// element is visible, do something
}
Elements can be considered hidden for several reasons:
* They have a CSS display value of none.
* They are form elements with type="hidden".
* Their width and height are explicitly set to 0.
* An ancestor element is hidden, so the element is not shown on the page.
Elements with visibility: hidden or opacity: 0 are considered to be visible, since they still consume space in the layout. During animations that hide an element, the element is considered to be visible until the end of the animation. During animations to show an element, the element is considered to be visible at the start at the animation.
Below JavaScript is useful if you need to know if a specific object is visible:
if ( $('#elementid').is(':visible')){
// element is visible, do something
}
OR
if ($('#elementid:visible').length > 0){
// element is visible, do something
}
Thursday, 21 April 2011
DropDownList.FindByText() case in-sensitive
The default behavior of FindByText() and FindByValue() of ListBox is case sensitive. You have to write your own code to do a case-insensitive search against any list box. One of the UIs which I was working on recently had a country list box where "United Kingdom" had to be selected by default. It was done by binding a country list returned by the middle-tier to the listbox and then doing
CountryListBox.FindByText("United Kingdom").Selected = true
Everything was fine until the middle-tier code started returning a new list where it has "UNITED KINGDOM" in place of "United Kingdom" in the original list. As you know this breaks my code.
This caused me to think about a solution which can do it case-insensitively. And here is what I have come up with.
foreach (ListItem countryListItem in CountryListBox.Items)
{
if (countryListItem.Text.ToLower().Equals("united kingdom"))
{
_ddlCountry.SelectedIndex = -1;
_ddlCountry.Items.FindByText(countryListItem.Text).Selected = true;
}
break;
}
FYI
String.Compare Method (String, String, Boolean) allows to to do case insensitve comparison when you pass the third parameter as true.
Click here to read more about String.Compare()
CountryListBox.FindByText("United Kingdom").Selected = true
Everything was fine until the middle-tier code started returning a new list where it has "UNITED KINGDOM" in place of "United Kingdom" in the original list. As you know this breaks my code.
This caused me to think about a solution which can do it case-insensitively. And here is what I have come up with.
foreach (ListItem countryListItem in CountryListBox.Items)
{
if (countryListItem.Text.ToLower().Equals("united kingdom"))
{
_ddlCountry.SelectedIndex = -1;
_ddlCountry.Items.FindByText(countryListItem.Text).Selected = true;
}
break;
}
FYI
String.Compare Method (String, String, Boolean) allows to to do case insensitve comparison when you pass the third parameter as true.
Click here to read more about String.Compare()
How to check whether an element exists using jQuery
There might be different ways of doing this. One is using the length property of jQuery selector as shown in the below code snippet
if ($("#elementid").length > 0){
// element exists, do something here
}
if ($("#elementid").length > 0){
// element exists, do something here
}
Align radio button with corresponding label
You might have spent time to align the label against radio button or checkbox when you use RadioButton, RadioButtoList, CheckBox, CheckBoxList in ASP.NET. It can be fixed by using CSS vertical-align propery.
Example :
label, input[type="radio"]{
vertical-align:middle;
}
Or if you want to apply it for all the input fields
input, label{
vertical-align:middle;
}
This works for IE8, Firefox3.6 and Chrome as well. I may not work for IE6. Worth testing if your are targeting your site for IE6 users.
Example :
label, input[type="radio"]{
vertical-align:middle;
}
Or if you want to apply it for all the input fields
input, label{
vertical-align:middle;
}
This works for IE8, Firefox3.6 and Chrome as well. I may not work for IE6. Worth testing if your are targeting your site for IE6 users.
Tuesday, 12 April 2011
First-Party and Third-Party cookies
Websites save cookies in your computer for the purpose of recognising your specific browser / computer combination, were you to return to the same site.
All cookies have an owner which tells you who the cookie belongs to. The owner is the domain specified in the cookie.
The word "party" refers to the domain as specified in cookie; the website that is placing the cookie. So, for example, if you visit www.helloeveryone.com and the domain of the cookie placed on your computer is www.helloeveryone.com, then this is a first-party cookie. If, however, you visit www.helloeveryone.com and the cookie placed on your computer says www.goodbye.com, then this is a third-party cookie.
Increasing numbers of people are either manually blocking third-party cookies, or deleting them reguarly. The cookies being deleted / blocked are third-party party cookies, as opposed to less problematic first-party cookies.
Why do far fewer people block first-party cookies? The reason for this is primarily that it is very difficult to surf the internet without accepting these cookies. First party cookies are necessary in order for you to be recognised as an individual. Any site that you login to as an individual requires a way of identifying you as "you". Hotmail, Yahoo, Gmail, online banking, ebay, Amazon, etc.
Additionally, anti-spyware software and privacy settings do not target first-party cookies.
How does this affect tracking systems, when people block / delete cookies?
A: All visits will still be recorded, but a person who has deleted the cookies will not be recognised as the same (returning) visitor.
When cookies are in place, and not blocked or deleted, total visitor counts will remain comparatively low. If a person constantly deletes cookies, they will be counted as a new "unique" visitor with every subsequent visit.
All cookies have an owner which tells you who the cookie belongs to. The owner is the domain specified in the cookie.
The word "party" refers to the domain as specified in cookie; the website that is placing the cookie. So, for example, if you visit www.helloeveryone.com and the domain of the cookie placed on your computer is www.helloeveryone.com, then this is a first-party cookie. If, however, you visit www.helloeveryone.com and the cookie placed on your computer says www.goodbye.com, then this is a third-party cookie.
Increasing numbers of people are either manually blocking third-party cookies, or deleting them reguarly. The cookies being deleted / blocked are third-party party cookies, as opposed to less problematic first-party cookies.
Why do far fewer people block first-party cookies? The reason for this is primarily that it is very difficult to surf the internet without accepting these cookies. First party cookies are necessary in order for you to be recognised as an individual. Any site that you login to as an individual requires a way of identifying you as "you". Hotmail, Yahoo, Gmail, online banking, ebay, Amazon, etc.
Additionally, anti-spyware software and privacy settings do not target first-party cookies.
How does this affect tracking systems, when people block / delete cookies?
A: All visits will still be recorded, but a person who has deleted the cookies will not be recognised as the same (returning) visitor.
When cookies are in place, and not blocked or deleted, total visitor counts will remain comparatively low. If a person constantly deletes cookies, they will be counted as a new "unique" visitor with every subsequent visit.
How Google Analytics works?
Google Analytics works by the inclusion of a block of JavaScript code on pages in your website. When visitors to your website view a page, this JavaScript code references a JavaScript file which then executes the tracking operation for Analytics. The tracking operation retrieves data about the page request through various means and sends this information to the Analytics server via a list of parameters attached to a single-pixel image request.
The data that Google Analytics uses to provide all the information in your reports comes from these sources:
How the Tracking Code Works
In general, the Google Analytics Tracking Code (GATC) retrieves web page data as follows:

The data contained in the GIF request is the data sent to the Google Analytics servers, which then gets processed and ends up in your reports. Here is an example of only a portion of a GIF request:
http://google-analytics.com/__utm.gif?utmwv=4&utmn=769876874&utmhn=example.com&utmcs=ISO-8859-1&utmsr=1280x1024&utmsc=32-bit&utmul=en-us&utmje=1&utmfl=9.0%20%20r115utmcc=__utma%3D97315849.1774621898.1207701397.1207701397.1207701397.1%3B
How GIF Requests Are Classified
A GIF request is sent to the Analytics servers in the following cases and classified according to the table below (Page, Event, Transaction, Item, Var). In each of these cases, the GIF request is identified by type in the utmt parameter. In addition, the type of the request also determines which data is sent to the Analytics servers. For example, transaction and item data is only sent to the Analytics servers when a purchase is made. Visitor, page, and system information is only sent when an event is recorded or when a page loads, and the user-defined value is only sent when the _setVar method is called.
![]()
Requests classified as interaction requests will impact the bounce rate calculations for your page or site. Bounce rate is referred to as a single-page visit to your site, but is strictly defined as a single interaction request during a user session. For this reason, a bounce rate for a page is also affected by ecommerce transactions and event tracking requests. This is because these features co-exist with page tracking and, when they are triggered, they result in additional interaction requests to the Analytics servers.
click here to read more.
The data that Google Analytics uses to provide all the information in your reports comes from these sources:
- The HTTP request of the visitor
- Browser/system information
- First-party cookies
How the Tracking Code Works
In general, the Google Analytics Tracking Code (GATC) retrieves web page data as follows:
- . A browser requests a web page that contains the tracking code.
- . A JavaScript Array named _gaq is created and tracking commands are pushed onto the array.
- . A <script> element is created and enabled for asynchronous loading (loading in the background).
- . The ga.js tracking code is fetched, with the appropriate protocol automatically detected. Once the code is fetched and loaded, the commands on the _gaq array are executed and the array is transformed into a tracking object. Subsequent tracking calls are made directly to Google Analytics.
- . Loads the script element to the DOM.
- . After the tracking code collects data, the GIF request is sent to the Analytics database for logging and post-processing.

The data contained in the GIF request is the data sent to the Google Analytics servers, which then gets processed and ends up in your reports. Here is an example of only a portion of a GIF request:
http://google-analytics.com/__utm.gif?utmwv=4&utmn=769876874&utmhn=example.com&utmcs=ISO-8859-1&utmsr=1280x1024&utmsc=32-bit&utmul=en-us&utmje=1&utmfl=9.0%20%20r115utmcc=__utma%3D97315849.1774621898.1207701397.1207701397.1207701397.1%3B
How GIF Requests Are Classified
A GIF request is sent to the Analytics servers in the following cases and classified according to the table below (Page, Event, Transaction, Item, Var). In each of these cases, the GIF request is identified by type in the utmt parameter. In addition, the type of the request also determines which data is sent to the Analytics servers. For example, transaction and item data is only sent to the Analytics servers when a purchase is made. Visitor, page, and system information is only sent when an event is recorded or when a page loads, and the user-defined value is only sent when the _setVar method is called.
Requests classified as interaction requests will impact the bounce rate calculations for your page or site. Bounce rate is referred to as a single-page visit to your site, but is strictly defined as a single interaction request during a user session. For this reason, a bounce rate for a page is also affected by ecommerce transactions and event tracking requests. This is because these features co-exist with page tracking and, when they are triggered, they result in additional interaction requests to the Analytics servers.
click here to read more.
Subscribe to:
Posts (Atom)