November 2006 - Posts

Often neglected is the importance of your physical surroundings when you code, yet I think your environment can have more of an impact on your productivity than a fully tooled IDE. Do you like the lights full glare, half, or off altogether? Do you hate it when the office is cold? Do you use a space heater? Does your chair recline? Is your keyboard the natural type or are you standard layout junkie? Do you absolutely have to have dual monitors? Do you listen to music while you code? What kind?

Personally I like it dark. No lights on at all would be ideal, but I compromise with my office mate by turning on one small light :). Warm -- preferably in the upper 70s or as high as 80. If it won't get that warm I wear a jacket almost all the time (at the moment there's snow on the ground outside, so I'm quite out of my element!). I only use standard layout keyboards (although I'm trying out a mildly natural layout right now, with some humorous results). I prefer to lean back in my chair, pushing my chair as far under the table as it can go so my chest is up against the desk. This lets me rest my arms on the table easily. I definitely notice an increase in my ability to stay focused on the task at hand if I'm listening to music with head phones on, usually some form of ambient or techno. Unfortunately I always forget to put my headphones back on after taking a phone call, guest, or trip to the restroom. Duel monitors aren't a must, but they sure help a lot. I use a dark background color scheme in Visual Studio, it's much easier on my eyes. Because I sit so far into my desk, the monitor is set a ways back.

It's amazing how much easier it is to focus when most of my preferences are in perfect tune with one another. But one person's preferences are another's torture.

What are your preferences?

 

A lifetime ago, and several Microsoft AJAX releases ago, I extended the built-in AutoCompleteBehavior and AutoCompleteExtender, enabling it to gather its list of completion items via a callback to the page rather than a web service. Well it seems like I hit a nerve with it, because it became pretty popular!

The problem is it was written to work with the July CTP of Atlas. But now we're on Beta 2! So, by popular demand, it is time to give the old thing an overdue face lift.

Like before, this version of the AutoComplete extender has the following advantages over the built in one:

  • Optionally uses an ASP.NET callback to query for completion items.
  • In callback mode you can keep the completion query logic encapsulated within the page, allowing you to access the page state.
  • The Extender raises an event when completion items are requested, making providing completion items as easy as handling a button click.
  • Inherits from the base extender, so you can swap it out easily!

Unlike my original version, I did not create a derived TextBox class this time. The new model for how extenders attach makes it somewhat less necessary to go that far.

I will post an example application using this extender shortly.

Use the source however you like... change it, trash it, claim it as your own, I don't mind :) This is just meant to be an example of extending from a base AJAX component yet still doing something more useful than Hello World. Enjoy!

Download the Project Here

Update 2/19/07: You can also download Leo Vildosola's sample VS2005 Web Application project here.

To use it, you will need both the Beta 2 install of AJAX extentions, and the Futures preview CTP. Then either add the linked project to your solution and reference it, or build it then reference the DLL directly. Add a tag prefix to your page:

<%@ Register TagPrefix="i88" Namespace="Infinity.Web.UI.WebControls" Assembly="Infinity.Web" %>

And use it! Here it is with callback mode enabled:

<i88:SmartAutoCompleteExtender id="auto1" runat="server" TargetControlID="Textbox1" UpdateMode="Callback" OnAutoCompleteCallback="[my event handler]" />

UPDATE 1/19/07: Leo Vildosola (lvldosola) has graciously documented the steps needed to get this control working against the RTM version of ASP.NET Ajax and the Control Toolkit, and has included a sample application. Please be sure and check it out here: http://lvildosola.blogspot.com/2007/01/how-to-get-smartautocompleteextender.html

It's easy to create runtime errors in JavaScript. But it's not every day you find a way to crash the runtime entirely.

It looks so innocent, yet it is so delightfully evil... copy/paste this into a simple HTML file and open it.

<html>
<head>
    <script type="text/javascript">
    function appendToBody() {
        var span = document.createElement('span');
        document.body.appendChild(span);        
    }
    </script>
</head>
<body>
    <form>
        <script type="text/javascript">
            appendToBody();
        </script>
    </form>
</body>
</html>

This is what you see:


For the search engines: "Internet Explorer cannot open the Internet site", "Operation aborted" :)

Upon clicking the one and only thing you can click on, your page is completely replaced with this...


"The page cannot be displayed"

Unfortunately the error isn't very helpful, so if you run into this you will likely scratch your head searching for an answer. You'll probably find suggestions like "reinstall IE" or "use Firefox". Don't listen to that nonsense :)

The problem is you can't append to the BODY element from script that isn't a direct child to the BODY element.

If you research it enough, you will find that some people ran into this when they had script inside a <table>. The proposed fix was to move the script outside the <table> element. But that would only work if the <table> was a direct child to the body! If the table is inside yet another element, it will still fail.

And of course, it's ok if your script isn't a direct child of BODY as long as it doesn't execute inline while the page is being parsed. So for our example here, you could fix it by moving the script to the top or bottom of the body, moving it after the body, or putting it in a function and calling it from window.onload or in response to some other event.

With AJAX apps becoming ever more popular, DOM manipulation is becoming more commonplace, and I fear more and more people may run into this. Hopefully this helps.

More Posts