Using up/down arrows with the script.aculo.us Autocompleter

I came across a problem recently, using the Autocompleter API of the script.aculo.us library.  Some amount of Googling later and I still couldn’t find a solution, but I discovered that there was misery in company – other devs were having the same issue.

Basically, when the autocomplete list is generated, and said list has a scrollbar on it, clicking on a scrolling arrow (or the scrollbar itself) would cause the list to disappear. Why? Because the input field’s onblur() would fire and close the list.

So I looked through the code a bit, and came up with this simple solution.

First: make sure that you save a reference to the Ajax.Autocompleter object that you create:

var oAutocompleter = new Ajax.Autocompleter()

Second: define an undocumented option in the options parm list:

onHide:	fOnHide

…where fOnHide is a function we’ll define later.

Third: add a boolean var to the Autocompleter object:

oAutocompleter.lcl_bActive = false;

Fourth: apply some event handlers to the div that is populated with the results:

oAutocompleter.update.onmouseover = function() {oAutocompleter.lcl_bActive = true;};
oAutocompleter.update.onmouseout = function() {oAutocompleter.lcl_bActive = false; oAutocompleter.element.focus();};

Fifth, and finally: define the fOnHide() function:

function fOnHide() {
  if (!oAutocompleter.lcl_bActive) {
    new Effect.Fade(oAutocompleter.update,{duration:0.15});
  }
}

Now – how does this work? (good to know, since I’m sure it’s inevitable that it won’t work for somebody or at some point in time)

It seems that somebody ends up calling the onHide() function of your instantiated Ajax.Autocompleter object whenever the input field’s onblur() fires. Normally this results in an Effect.Fade being instantiated, and your result list fades out of existence.

We interrupt that process – instead of calling the Effect.Fade() directly, we first check to see if a flag has been set.  The flag is set to true whenever the pointer is hovering over the list – manipulating the scroll buttons or scrollbar or just hanging out.  In those instances, the onHide will essentially do nothing, and your autocomplete list will not disappear.

Once you move away from the list, the flag is reset and, crucially, focus is returned to the input field.  This is done so that the field’s onblur() can fire when appropriate, as it would have done before we made any code changes.  Now, when the field loses focus, the fOnHide() function will perform the default task of running the Effect.Fade() function.

Easy breezy 🙂

Is it really that easy?

My last post may have started a trend… based on a conversation I had recently I’ve started thinking about more areas that could benefit from some forward progress.

My Whole Home Automation project is based in ASP Classic at present, with VBScript the language of choice on the backend.  This has necessarily meant some familiarity with (D)HTML, Javascript, and obviously VBScript itself – not to mention SQL for the DBMS interface.  I’ve never blinked an eyelash at the level of know-how required to get all of this stuff done.  If anything, I figured that it must be trivial in light of the move to ASP.Net and what I perceived to be a marked increase in code complexity to go along with the marked increase in features.

And perhaps I was half on the mark and half off of it.  Sure the code itself can be more complex than VBScript, what with inheritance and classes and all the other good stuff you get with an OO-capable language (C#).  But getting down and dirty to the point of making something functional?  Oh, that only requires that you’re good with a mouse.

It’s all down to the IDE, the Integrated Development Environment.  And I’m here watching an intro video on the asp.net site where it took something like 2-3 clicks to make a DBMS-linked table, complete with end-user editing functions.  It’s so easy, a monkey could do it.  So surely this code-warrior could too, right?

To be honest, I’m dismayed.  Though I shouldn’t be surprised.  A recent article in Wired talked about making programmers out of everybody – that having a good idea but no programming skills shouldn’t keep your idea from seeing the light of day.  The article seemed to suggest that the real innovation today is with the developers who are making these drop-dead-easy design tools a reality.

I suppose it’s just how this industry works.  What’s complex and out-of-reach for the masses today becomes a commodity in short order.  Just look at the Kinect and all of the functionality it has afforded, which was once the realm of big money and big brains.

It almost makes me reluctant to go the ASP.Net route, if only because it seems that it makes things *too* easy.  But it’s hard to argue with the notion of concentrating on ideas->reality rather than ideas->how?->reality.

Perhaps there’s hope for me in the Perl and/or PHP arena.  Ahh, LAMP, embrace me in your searing glow.