If you don’t want to or can’t wait for the next version, you can easily fix your current jquery.js file. Go to line 2255 and look for the beforeactivate function. The if-clause limits the initial data storage for change events to radio buttons. That’s why the other change events won’t be registered in IE. Remove the if-clause and everything will work again.

2255
2256
2257
2258

beforeactivate: function(e) {
  var elem = e.target;
  jQuery.data(elem, "_change_data", getVal(elem));
}

Impulse Studio Labs has produced the first cheat sheet I’ve found for the new version of jQuery. It’s printer-friendly, fits on one page, marks all the new or changed functions and I don’t think they missed anything important.

Most of the time it’s pretty easy to avoid server controls, but if you want to relay information from the server to the client at startup, you are usually stuck with WebControls like Literals or HTML controls for hidden fields.

At least that was what I thought till I stumbled upon a command to create hidden fields without these horrible long ids in a separate div container right after the form tag:

ClientScript.RegisterHiddenField(string id, string value)

I usually create my fields in Page_Load like this:

using System.Web.UI;
  ...
  protected override void Page_Load(){
      ClientScriptManager csm = Page.ClientScript;
      csm.RegisterHiddenField("foo", "1");
      csm.RegisterHiddenField("bar", string.Empty);
  }

This will create the following HTML code:

<form ...>
  ...
  <div>
      <input type="hidden" id="foo" name="foo" value="1" />
      <input type="hidden" id="bar" name="bar" />
  </div>
  ...
</form>

Of course you won’t be able to read or manipulate the field later like a WebControl. And you have no control about the final placement on the page either. But that was never my intention and you can do whatever you want with the field in your JavaScript anyway.

I’ve been eagerly waiting for the next update on my favorite JavaScript library, jQuery. I haven’t done any testing, but the list of new features looks very promising:

First of all we have to register the event on the document. Unfortunately keypressed isn’t supported on all browsers and keyup is a little too late to prevent all browser functions so we have to go with keydown.

1

$(document).keydown(function(event){

For cross-browser compatibility two properties of the event need to be checked: event.keyCode and event.which.

2

    var key = event.keyCode || event.which;

And the last thing you have to know is whether the focus is on a textbox or a textarea. Otherwise we can screw up the ability to edit text very easy if we work with ENTER, DELETE or BACKSPACE. The check is done by looking at event.target.type.

3

    if(event.target.type !== 'textarea'){

For the rest of the example, let’s say we have three buttons on our page, selected by jQuery, which get shown and hidden dynamically according to the context: one back button, $back, one forward button, $forward and one button to submit the form, $save.

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

        //ENTER
        if (key === 13) {
            //The button has to be visible to be used.
            if ($save.is(':visible')) {  
                $save.click();  
            } else if ($forward.is(':visible')) {  
                $forward.click();
            }
            //Preventing any other action by the browser
            //even if no button is visible  
            return false;  
        }
        //Not in a textarea or textbox
        if (event.target.type !== 'text') {
            //BACKSPACE  
            if (key === 8) {
                //SHIFT is also pressed
                if (event.shiftKey) {
                    if ($forward.is(':visible')) {
                        $forward.click();
                    }
                } else {
                    if ($back.is(':visible')) {
                        $back.click();
                    }
                }
                return false;
            }
        }
    }
});

That’s it, our application’s enhanced with a few simple keyboard commands.

A little tip at the end: To make your code easier to write and understand here’s a handy object maps the real key codes of the most important special keys to easy to use constants. Just put it in front of the rest of your code.

var keyCode = {
  BACKSPACE: 8,
  CAPS_LOCK: 20,
  COMMA: 188,
  CONTROL: 17,
  DELETE: 46,
  DOWN: 40,
  END: 35,
  ENTER: 13,
  ESCAPE: 27,
  HOME: 36,
  INSERT: 45,
  LEFT: 37,
  NUMPAD_ADD: 107,
  NUMPAD_DECIMAL: 110,
  NUMPAD_DIVIDE: 111,
  NUMPAD_ENTER: 108,
  NUMPAD_MULTIPLY: 106,
  NUMPAD_SUBTRACT: 109,
  PAGE_DOWN: 34,
  PAGE_UP: 33,
  PERIOD: 190,
  RIGHT: 39,
  SHIFT: 16,
  SPACE: 32,
  TAB: 9,
  UP: 38  }

The following example shows some code somewhere within an iframe with the id content:

<h1>An example title</h1>
Some text that isn't  particularly interesting...
<ul>
  <li id="back">previous posts</li>
  <li id="forward" class="green">next posts</li>
</ul>

Apparently the list entry for next posts has the styles for a green button. That’s the way it should look most of the time, but in some cases it has to be red instead. We have to remove the class for the green color and add one for red. Using jQuery that’s done in only one statement:

$("#content")
  .contents()
  .find("#forward")
  .removeClass("green")
  .addClas("red");

It’s that easy because of jQuery’s contents() function. Normally the function returns all child nodes from the matched elements, but in case of an iframe you get the whole document that’s loaded into the iframe. Now you can use find() to locate the elements you need to work with and that’s it.