Jovan's Blog

MaskedInput Transform Intellisense

2008-10-27T14:06:00Z

MaskedInput class's Transform property that I described in depth in a few preceding blog posts presented us with an interesting design dilemma. At first it seemed like it should be a typical enumeration property, with one value for each Transform type. However, since the architecture allowed new Transform types to be added in a number of different ways (see the previous blog posts), the enum turned out to be too stifling. For that reason, we opted for a string instead.

However, we still wanted to offer some Intellisense, to give the developer a hint at the values he would most likely want to use. We did it by placing the TypeConverterAttribute on the Transform property:

public sealed class MaskedInput : BaseInput
{
  ...
  [TypeConverter(typeof(MaskedInputTransformConverter))]
  public string Transform
  {
    get {...}
    set {...}
  }
  ...
}

The implementation of MaskedInputTransformConverter is very simple:

/// <summary>
/// Provides Visual Studio intellisense for Transform property.
/// The list of StandardValues here corresponds to the properties of client-side ComponentArt_MaskedInput_Transforms object.
/// </summary>
public class MaskedInputTransformConverter : TypeConverter
{
  public string[] StandardValues =
  {
    "empty", 
    "CreditCard_VisaMasterCard",
    "CreditCard_AmEx",
    "Telephone_NorthAmerica",
    "ZipCode",
    "PostalCode",
    "PostalCode_Australia",
    "EmailAddress"
  };
  public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context)
  {
    return new StandardValuesCollection(StandardValues);
  }
  public override bool GetStandardValuesSupported(ITypeDescriptorContext context)
  {
    return true;
  }
}

This works really well in ASPX Intellisense, popping up the list of standard values, without forcing you to use one of them - exactly the behaviour we needed. The Intellisense also works for the Properties pane. Unfortunately it does not work in the CodeBehind files, and I don’t think there is a way to implement it there.

Share this post: email it! | bookmark it! | digg it! | reddit!

Building in new MaskedInput Transforms

2008-10-24T14:05:00Z

In the previous post I explained how you can customize the behaviour of MaskedInput’s Transforms. That should probably cover all your needs. However, MaskedInput’s architecture does allow for one more way to customize transforms. You can actually build in your own.

As you can see from the MaskedInput_Transforms.js file attached in the previous post, all the built-in transforms are contained in a global JavaScript object named ComponentArt_MaskedInput_Transforms, indexed by Transform name. So building in a new Transform is as easy as adding another property to ComponentArt_MaskedInput_Transforms. You can do that in a few ways:

You can completely redefine the object ComponentArt_MaskedInput_Transforms:

 <script type="text/javascript">
   window.ComponentArt_MaskedInput_Transforms =
   {
     'UpperCaseInput':
     {
       'validate': function(maskedInput) {return true;},
       'unmask': function(maskedInput) {return maskedInput.masked.value.toUpperCase();},
       'mask': function(maskedInput) {return maskedInput.unmasked.value.toUpperCase();}
     }
   }
 </script>
 <ComponentArt:MaskedInput runat="server" ID="MaskedInput1"
   Transform="UpperCaseInput"
 />

Keep in mind that because you are overwriting ComponentArt_MaskedInput_Transforms, the built-in transforms will no longer work.

A less drastic solution is to just add your new Transform to the existing ones:

 <ComponentArt:MaskedInput runat="server" ID="MyMaskedInput" />
 <script type="text/javascript">
   window.ComponentArt_MaskedInput_Transforms.UpperCaseInput =
   {
     'validate': function(maskedInput) {return true;},
     'unmask': function(maskedInput) {return maskedInput.masked.value.toUpperCase();},
     'mask': function(maskedInput) {return maskedInput.unmasked.value.toUpperCase();}
   }
   window.MyMaskedInput.set_transform('UpperCaseInput');
 </script>

If you have a source code license and are compiling your own custom builds, you can easily add your transforms directly to the JavaScript file. They will then work just like the original built-in transforms.
If you are doing this, you may also want to extend MaskedInput Transform Intellisense, as described in the next blog post.

Share this post: email it! | bookmark it! | digg it! | reddit!

Customizing MaskedInput Transforms

2008-10-23T13:30:00Z

In this blog post I will assume that you understand how MaskedInput Transforms function. It was explained in the previous blog post.

Here is the list of currently implemented transforms:

CreditCard_VisaMasterCard - Visa or MasterCard credit card number.
CreditCard_AmEx - American Express credit card number.
Telephone_NorthAmerica - North American telephone number.
ZipCode - American ZIP code.
PostalCode - Canadian postal code.
PostalCode_Australia - Australian postal code.
EmailAddress - e-mail address.
empty - accepts all inputs.

empty Transform is a special case. It accepts all inputs, and it doesn't mask or unmask them. Here is how it looks in code:

 'empty':
 {
   'validate': function(maskedInput)
   {
     // Accept all input:
     return true;
   },
   'unmask': function(maskedInput)
   {
     // Just pass on the edited displayed text:
     return maskedInput.masked.value;
   },
   'mask': function(maskedInput)
   {
     // Just pass on the unmasked value:
     return maskedInput.unmasked.value;
   }
 }

There is not enough space in this blog post to show the code of the rest of the Transforms, but I made the source code file available for download.

Ideally the available transforms will be enough for your requirements. New transforms are very easy to build in, so please don't hesitate to send in your suggestions.

However, for those times when your requirements cannot be met by the built-in transforms, there are a number of ways to customize the MaskedInput.

In addition to Transform, MaskedInput exposes three more server-side properties: TransformValidate, TransformUnmask, and TransformMask. These allow you to override the behaviour of any of the three transform functions. For example, to make the Visa card transform featured in the previous blog post mask with dashes instead of masking with spaces, you can do something like this:

 <script type="text/javascript">
   function maskVisaWithDashes(maskedInput)
   {
     return maskedInput.unmasked.value.replace(/^(\d{4})(\d{4})(\d{4})(\d{4})$/, '$1-$2-$3-$4');
   }
 </script>
 <ComponentArt:MaskedInput runat="server" ID="MyMaskedInput"
   Transform="CreditCard_VisaMasterCard"
   TransformMask="maskVisaWithDashes"
 />

This allows you to fully override any of the Transform's functions. Note that you can also leave the Transform property blank. In that case, the control defaults to the empty transform.

In the next blog post, I will introduce another more integrated way to add a new Transform.

Share this post: email it! | bookmark it! | digg it! | reddit!

MaskedInput Transform functionality

2008-10-22T14:06:00Z

The format of the masked input is fully defined by the "Transform" it uses.

A Transform is a client-side JavaScript object containing just three functions:

validate – A function that takes a look at what the user just typed into the masked input box, and returns a boolean value: true if text is valid, false if it isn't.
For example, if the transform is used to accept a Visa card number, and the user types in "4506/00020002-0002", this function returns true. (It just makes sure that there are exactly 16 digits.) If the user types in "2008-10-14", the function returns false.
unmask – A function that takes a look at what the user has just typed into the input box, and "unmasks" it. Typically, this means that the text is cleaned of formatting, leaving behind just the raw data. Unmask gets called even when validate does not return true, so it should not assume that the masked text it is working on is valid.
In our example, if the user typed in "4506/00020002-0002", this function will return "4506000200020002".
mask – A function that takes a look at the raw, clean data, and "masks" it: formats it for display.
With our raw data being "4506000200020002", this function will return "4506 0002 0002 0002".

Each of these methods takes only one argument: the reference to the client-side MaskedInput JavaScript object. The function can then easily use this object to get any other information it needs. For example, here is the entire code of the Visa card transform:

 'CreditCard_VisaMasterCard':
 {
   'validate': function(maskedInput)
   {
     // Ensure the unmasked edited text has exactly 16 digits:
     return this.unmask(maskedInput).length === 16;
   },
   'unmask': function(maskedInput)
   {
     // Simply remove all the non-digits from the displayed text:
     return maskedInput.masked.value.replace(/[^\d]/g, '');
   },
   'mask': function(maskedInput)
   {
     // Insert spaces between four-digit groups:
     return maskedInput.unmasked.value.replace(/^(\d{4})(\d{4})(\d{4})(\d{4})$/, '$1 $2 $3 $4');
   }
 }

Two often used properties of the client-side MaskedInput object are maskedInput.masked and maskedInput.unmasked:

maskedInput.masked refers to the display textbox element that the user sees and edits. It contains the masked text.
Although the masked text is typically not examined on the server, it can be accessed as MaskedInput's DisplayText property.
maskedInput.unmasked refers to a hidden input that contains the unmasked text.
The unmasked text is often examined or manipulated on the server, where it can be accessed as MaskedInput's Text property.

Hopefully it is now clear how Transforms function. In the next blog post I will explain how you can customize them.

Share this post: email it! | bookmark it! | digg it! | reddit!

Major input control Gotcha

2008-10-14T15:17:00Z

Short Story:

This will not work:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="MyNumberInput.increaseValue();" />
<input type="button" value="-" onclick="MyNumberInput.decreaseValue();" />

This is how to correct it:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="window.MyNumberInput.increaseValue();" />
<input type="button" value="-" onclick="window.MyNumberInput.decreaseValue();" />

Long Story:

This will work:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="increase();" />
<script type="text/javascript">
  function increase()
  {
    MyNumberInput.increaseValue();
  }
</script>

But, as mentioned before, this:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="MyNumberInput.increaseValue();"/>

will instead produce a JavaScript error: MyNumberInput.increaseValue is not a function

But isn't that the exact same code?? What is going on?

It turns out that in the second case "MyNumberInput" is not referring to the client-side NumberInput object. Instead it is referring to a DOM element of the same name.

Like most ComponentArt controls, input controls create a number of client-side DOM elements and JavaScript objects.
In this particular example, with a NumberInput named MyNumberInput:
In JavaScript, the most important object is named MyNumberInput, and is an instance of client-side class ComponentArt.Web.UI.NumberInput.
In the DOM, there are a number of different elements, including a text input with the id MyNumberInput.

This results in a very unusual naming conflict. Normally, when you write MyNumberInput in client-side code, you expect it to refer to the global JavaScript object of that name. And it does. Except when the code is running in the event handler of an HTML tag. Then MyNumberInput refers to the DOM element with that id. Which is probably not what you want.

To avoid ambiguity, you can use window.MyNumberInput to refer to the JavaScript object, and document.getElementById('MyNumberInput') to refer to the DOM element.

So why don’t we fix this? Well, it turns out that there is no real bug here.
First of all, this is not a design that is unique to ComponentArt input controls. In fact, most ComponentArt controls produce JavaScript objects and DOM elements with matching identifiers, for a number of reasons. What is different with input controls is that the DOM element in question happens to be a form element. This triggers the naming conflict.
However, having these matching identifiers turns out to be needed for the input controls to work smoothly with ASP.NET’s client-side validation, which is a very important feature.
So it is unlikely that we will be able to "fix" this. Instead, just please keep this gotcha in mind.

Share this post: email it! | bookmark it! | digg it! | reddit!

Multiline strings in JavaScript

2007-10-17T23:53:00Z

Myth: You can't have a string literal stretch across two lines of text in JavaScript.

Fact: You can have multiline string literals in JavaScript in all browsers.

Multiline (or is it "multi-line"?) strings are a fringe feature of programming languages. They are very rarely needed, so a lot of languages don't support them at all (VB.NET). And even when a language does support them (C#), most programmers are not even aware of that. How often have you seen something like this in real code:

string myStr = @"This is a C#
multiline string
just because I can!";

I think I used that only once. Old "\n" would have worked alright, but in that case the string was very long. Multiline option was much more readable and also gave me a chance to show off my incredibly amazing super knowledge of this marginal feature. It is this very marginality and near-uselessness that makes multiline strings a topic I want to blog about.

Actually, JavaScript, being a tricky little scripting language, has an increased need for multiline strings. Use it in depth and you will need statements like eval, which evaluates a string of code, or this textbook example:

var square = new Function('x','return x*x;');

alert(square(5)); // alerts 25

This is actually a very useful feature of the language. Being able to construct code on the fly is certainly not your run-of-the-mill onclick-change-image JavaScript. But if you get deep into the language, the need for it does arise. Problem is, what if the function you want to create is more complex than x*x?

var factorial = new Function('n',
  'var result=1; for (var i=1; i<=n; i++) result *= i; return result;');

alert(5)); // alerts 120

That works, but man is it ugly. Too hard to read. Multiline strings to the rescue:

var factorial = new Function('n', '\
  var result = 1;            \
  for (var i=1; i<=n; i++)   \
    result *= i;             \
  return result;             \');

alert(factorial(5)); // alerts 120

Yes, that works! And it's exactly the same as the previous piece of code (aside for extra white space to make it more readable).

Simply put, you can use backslash character to ignore end of line in JavaScript strings. This directly contradicts my JavaScript books. For example, David Flanagan's [JavaScript: The Definitive Guide], my JavaScript bible for almost a decade and counting, specifically says: backslash escape cannot be used before a line break to continue a string. This is clearly incorrect. (I am so proud to have found an error in that book, I want to let everyone know.) I tested this technique in all browsers I could think of, and it works in all of them.

I learned this technique from a Google search that turned up some [post on an obscure Australian forum]. How this one guy was the only enlightened individual is still a mystery.

Note that the strings will not contain newline characters, unlike the C# multiline example from the beginning of this post. In particular in JavaScript:

alert('foobar' == 'foo bar'); // false
alert('foobar' == 'foobar');  // true
alert('foobar' == 'foo\
bar');                        // true!

So end of line is simply magically ignored. If you really want to have new line characters, you will have to run something like:

var myStr = 'line one\n\
line two';

Share this post: email it! | bookmark it! | digg it! | reddit!

Tackling Stubborn TD Style Definitions

2007-06-18T21:05:00Z

"If you set a default style for the td tag in your stylesheet, like this,
td {font-family: Arial, Helvetica, sans-serif; font-size: 11px; color: #333333;}
then this will be used in your tab strip, no matter what style you create for the tab items"

Questions like this are quite common in forums and support calls. An obvious way to avoid this conflict is to not have a default style for TD tags. However, this is not always practical - default TD style definitions are quite common, sometimes even mandated by corporate policy. Instead, there is a lot less intrusive way to get this to work. First let's take a look at an example of how this happens.

Suppose we have a page which contains a CSS definition like this, instructing table cells to use Comic font:

TD
{
  font-family:"Comic Sans MS";
}

However we want to show menu items in Courier font:

.myMenuItem
{
  font-family:"Courier New";
}

This looks like it should work, and it sometimes does. But more often it doesn't: Menu items (or TabStrip tabs, or NavBar items...) use Comic Sans font from the default TD style, instead of Courier New from myMenuItem CSS class. To understand why, let's take a look at a (simplified) sample of HTML that is rendered by the menu for its item:

<td class="myMenuItem">
 ITEM TEXT
</td>

In this first case definitions applied in myMenuItem CSS class will correctly take effect. However, in many cases - for example, when the item has an icon - the rendered HTML is more complex:

<td>
 <table class="myMenuItem">
  <tr>
   <td>
    <img src="icon.gif" mce_src="icon.gif">
   </td>
   <td>
    ITEM TEXT
   </td>
  </tr>
 </table>
</td>

In this case, style definitons for default TD element will take precedence over definitions for myMenuItem CSS class. The item will show in Comic font instead of the desired Courier.

There is a very simple CSS workaround for this situation. Just slightly modify the original definition to get:

.myMenuItem TD
{
  font-family:"Courier New";
}

The meaning of this defintion is: if a TD tag is within a tag of class myMenuItem, show it in Courier New font. This is more specific than the default TD style we're trying to overrule, so it will win out. Note however, that while this definition will work in the second case (the more complex item), it will not work in the first (the simple item). So finally the solution that works for all cases is a combination of the two:

.myMenuItem, .myMenuItem TD
{
  font-family:"Courier New";
}

Share this post: email it! | bookmark it! | digg it! | reddit!

Client-side Date Format Localization in ASP.NET AJAX

2006-12-02T06:03:00Z

Much buzz has already been created around new client-side localization features introduced with ASP.NET AJAX Beta 2. Most of it has focused on localized resources, which can now easily be retrieved from the server by client scripts. This makes sense - resources are arguably the most important aspect of localization. But not from a web control developer's point of view. When developing web controls, we deal with little actual content - for the most part, we are providing form for our customers' content. Having worked on ComponentArt.Web.UI Calendar control in particular, I was especially interested in localization features that deal with date and time formats.

How Calendar Works Today

In order for Calendar control to be customizable and culture-independent, we send information about date settings to the client, where the rendering is to take place. Examine the HTML source of a page that contains a Calendar control and you will see excerpts like these:

['AbbreviatedDayNames',['Sun','Mon','Tue','Wed','Thu','Fri','Sat']]
['AbbreviatedMonthNames',['Jan','Feb','Mar','Apr','May','Jun','Jul',
  'Aug','Sep','Oct','Nov','Dec']]
['DayNames',['Sunday','Monday','Tuesday','Wednesday','Thursday',
  'Friday','Saturday']]
['MonthNames',['January','February','March','April','May','June',
  'July','August','September','October','November','December']]

These are portions of JavaScript arrays with relevant date format information. They are put together by the Calendar control on the server, to be used by the control's rendering engine on the client. The original source of information is ASP.NET's System.Globalization namespace (unless, of course, the developer specifically instructs the Calendar control instance to use some custom date formats). It is the wealth of information in the framework that enables the Calendar to seamlessly switch between various cultures as seen in the [Globalization demo].

What ASP.NET AJAX Brings

So I was really delighted to hear that as of ASP.NET AJAX Beta 2, this information is also available on the client. Only information for current culture (on the server: System.Globalization.CultureInfo.CurrentCulture) is being propagated to the client, which makes perfect sense with - count them - 134 cultures and growing. Full documentation on this feature is not yet available, but I did a little snooping around - using the good old for/in loop mentioned in [my previous blog post], and here's what I found out. The relevant client-side object is called Sys.CultureInfo.CurrentCulture.dateTimeFormat, and its contents for my English (Canada) culture are:

AMDesignator: AM
Calendar: [object Object]
DateSeparator: /
FirstDayOfWeek: 0
CalendarWeekRule: 0
FullDateTimePattern: dddd, MMMM dd, yyyy h:mm:ss tt
LongDatePattern: dddd, MMMM dd, yyyy
LongTimePattern: h:mm:ss tt
MonthDayPattern: MMMM dd
PMDesignator: PM
RFC1123Pattern: ddd, dd MMM yyyy HH':'mm':'ss 'GMT'
ShortDatePattern: M/d/yyyy
ShortTimePattern: h:mm tt
SortableDateTimePattern: yyyy'-'MM'-'dd'T'HH':'mm':'ss
TimeSeparator: :
UniversalSortableDateTimePattern: yyyy'-'MM'-'dd HH':'mm':'ss'Z'
YearMonthPattern: MMMM, yyyy
AbbreviatedDayNames: Sun,Mon,Tue,Wed,Thu,Fri,Sat
ShortestDayNames: Su,Mo,Tu,We,Th,Fr,Sa
DayNames: Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday
AbbreviatedMonthNames: Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,
  Dec,
MonthNames: January,February,March,April,May,June,July,August,
  September,October,November,December,
IsReadOnly: false
NativeCalendarName: Gregorian Calendar
AbbreviatedMonthGenitiveNames: Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,
  Oct,Nov,Dec,
MonthGenitiveNames: January,February,March,April,May,June,July,
  August,September,October,November,December,

Further drilling into Sys.CultureInfo.CurrentCulture.dateTimeFormat.Calendar, we find:

MinSupportedDateTime: Thu Dec 31 19:00:00 EST 99
MaxSupportedDateTime: Fri Dec 31 18:59:59 EST 9999
AlgorithmType: 1
CalendarType: 1
Eras: 1
TwoDigitYearMax: 2029
IsReadOnly: false

As you can see, a lot of this information duplicates the settings propagated by the Calendar control. This is great, because I love to throw code away. In the near future, we will hopefully be able to rely on the client-side framework to provide date and time format information, and only propagate it ourselves when necessary.

You can use this data for your own needs with confidence. While it is not yet documented, and has the appearance of some internal code, good folks of the ASP.NET AJAX team confirm that it will be in this same form and public, supported, and documented when ASP.NET AJAX is released. Until client-side docs are available, you can rely on the server-side documentation for DateTimeFormatInfo. Client-side object is designed to duplicate it.

It feels great to see more and more of the ASP.NET framework migrate (or rather replicate itself) to the client. Soon we will all benefit from building and using a much better interweb.

Share this post: email it! | bookmark it! | digg it! | reddit!

Quick Type Conversions and Other JavaScript Tricks

2006-11-29T07:28:00Z

I recently read a post in [Bertrand Le Roy's blog] titled [A nice and compact way to coerce to Boolean in JavaScript]. Having used JavaScript extensively for the past few years, I knew from the title what the post would be about - the lovely double negation: !!somevariable - the shortest way to say "parse boolean" in JavaScript. While the trick was not new to me, the blog post did give me the idea to share a couple of similar tips:

Type Conversions

A compact way to convert to integer: somevariable - 0

A compact way to convert to string: somevariable + ''

None of these may be very readable at first, but I found them very easy to get used to. They certainly are short to write, which counts when writing web controls. And frankly, I never was a big fan of "parseInt".

Note also that parseInt(somevariable) and somevariable-0 are not equivalent. For example, parseInt(true) evaluates to NaN, while true-0 evaluates to 1. I prefer the latter.

I first learned these three tricks from David Flanagan's [JavaScript: The Definitive Guide], a terrific book.

Here are a couple more tricks I learned from that book (or was it somewhere else?):

Undefined vs null and === vs ==

When you just a declare a variable foo, but you do not assign a value to it, what is its value? You may think it is null, because foo==null evaluates to true, but this is not exactly correct. The value is actually undefined - or unassigned, if you prefer. You can prove this by using the identity operator, ===:

var foo;
alert(foo == null); // true
alert(foo === null); // false
var o = new Object();
alert(o.bar == null); // true
alert(o.bar === null); // false
alert(o.bar == foo); // true
alert(o.bar === foo); // true
alert(foo === void 0); // true

The last line uses the operator void, another recluse. Its purpose is to discard the value of its operand and return an undefined value instead. If you are writing code and need an undefined value, you should do what cool kids do and use void 0, instead of an unassigned dummy variable or something else lame.

So: undefined value is not null value, which can be proven using the identity operator, which is not the equality operator. But will you actually need this any time soon? Probably not. Identity operator, undefined value, and void operator are used more often in examples like this one than in actual code. But I did occasionally have a need for them, so it pays to keep them in mind. Also they're fun to blog about.

for/in Loop

In contrast, for/in loop is very important in JavaScript. It enables looping through the properties of an object. This is indispensable in some cases - for example when you need to examine an unknown object:

for (var propertyName in myObject)
{
  alert('Property ' + propertyName + ' has value: ' + myObject[propertyName]);
}

Share this post: email it! | bookmark it! | digg it! | reddit!