Modal Popup with Rounded Corners

If you set the TargetControlID of both ModalExtender and RoundedCornerExtender to one panel, ASP.NET will not like it, probably because of some JavaScript clashes.

One simply trick is to have an inner panel, surrounded by an outer panel. Set the outer panel’s background color to transparent and let the inner panel have the rounded corner extender.

Like so: (key is the transparent)
.modalPopupOuter {
background-color:Transparent;
padding:10px 10px;
width:700px;
height:520px;
}
.modalPopupInner {
background-color:#ffffff;
padding: 10px;
width:700px;
height:500px;
}
The screen shot below doesn’t have rounded corners, but it has a stand-out “X” on the top-right corner, that’s achieved by having the transparent outer panel, obviously.

Validation Controls

ASP.NET supplies 6 different validation controls, each with some distinct properties besides the few common ones:

• RequiredFieldValidator
• RangeValidator
  • MaximumValue (In code behind, MaximumValue=DateTime.Today.ToString(“yyyy/MM/dd”))
  • MinimumValue (1850/1/1)
  • Type (String or Date)
• RegularExpressionValidator
  • ValidationExpression – put in regular expression here. There are a few of pre-defined ones.
• CompareValidator
  • ControlToValidate & ControlToCompare
• CustomValidator
  • Double-click on design mode to get the event handler on server-side
    e.g. args.IsValid == (args.Value.Length >= 8 )
  • clientValidationFunction (JavaScript)
    e.g.
    function isLengthValid (source, args)
    {
    args.IsValid = (args.Value.Length >= 8 )
    }
  • Both client- and server-side validation function should be included
• ValidationSummary
  • HeaderText
  • CssClass
  • DisplayMode

• Common properties:

• • ControlToValidate – this is the most essential obvisouly, a must
  • ErrorMessage – Text in here will be displayed in the ValidationSummary
  • Text – This will be displayed right at where the validation control lies
  • Display (Static/Dynamic/None) – pretty intuitive. I see “dynamic” being the default, because it doesn’t take up space when it’s not being validated. There is no reason for some empty place holder.
  • EnableClientScript – default is true; if browser supports JavaScript, then validation is done on client first. If the validation fails, then postback is cancelled.
  • ValidationGroup – Just give it a name, and give the same name to the button or whatever control that is to trigger the validation, then only the fields with the same group name will be validated.
    Uses:
    Page.Validate(ValidationGroupPropertyValue) – tells the page to perform validation on fields with that specified validation group
    GetValidators(ValidationGroup) – returns a collection of validation controls that belong to the specified validation group
  • SetFocusOnError – same as the Focus() method; if set to True, causes the Web control the validation control is operating on to receive focus if the validation control is invalid

Example: To validate a password, should use the following validation

• RequiredFieldValidator
• RegularExpressionValidator
• CompareValidator (for the re-type password field)
• CustomValidator (To check length of password)

More references:

• MSDN – ASP.NET Validation in Depth
• MSDN – Validating ASP.NET Server Controls
• ASP.NET Quickstart Tutorials
• Google Password Strength API (CodeProject)
  
• 4GuysFromRolla – Creating Validator Controls for the CheckBox and CheckBoxList

Some Client-side Know-Hows

Referring to Scott Mitchell’s article “Client-Side Enhancements in ASP.NET 2.0” on 4GuysFromRolla, it contains

• How to programmatically set focus to a Web control
• How to add client-side script when a Button is clicked
• How to maintain scroll position on postbacks
  Attached with this is another article on “Resetting scroll positions” that talks about handling scroll position on a page-by-page basis, and as always, MSDN Library reference

ClientID & UniqueID

ClientID and UniqueID are definitely different. In the simplest sense, ClientID is used for client-side, UniqueID is used for server-side. However, there are more subtle differences between them.

ClientID:

• Used with id attribute of rendered HTML tag
• Uses underscore as separator (e.g. ParentPanel_ChildControl)
• MSDN ClientID reference
• <%=%>, combined with $get or $find, can be used to access the ClientID thru JavaScript. It is executed at the rendering stage of the Page, and is included to the page’s rendering output (HTML, most likely). <%=%> does never run at client-side. It is server-side code. You just use it to “spit” output between the content on the aspx page, so that it will impact on the end result which is rendered at the client. For information on $get and $find, check here.

UniqueID:

• Used with name attribute
• Uses colon as separator (e.g. ParentPanel:ChildControl)
• MSDN UniqueID reference

With regard to the separator explained above, I’ve encountered one exception, whereas the UniqueID separator is “&”. I have a button and a update panel on a page, with the button being the AsyncPostbackTrigger for the update panel. When trying to access the button via its ID in code behind, the ID rendered and written to the HTML is not the button’s ClientID, but its UniqueID, which then has “&”, instead of colon (:), as the separator. The only explanation I can think of for such behavior is due to the postback triggers for the update panel. Trial and error always help.

In addition, both ClientID and UniqueID can be overridden to be identical all around, of course. Just simply assign them with the ID attribute of the control.

/// <summary>
/// Override to force simple IDs all around
/// </summary>
public override string UniqueID
{
get
{
return this.ID;
}
}
/// <summary>
/// Override to force simple IDs all around
/// </summary>
public override string ClientID
{
get
{
return this.ID;
}
}