Came across the most frustrating IE bug (for IE 7 anyway, there are rumours that this has been fixed in IE8, though I haven’t dared to try yet.

let’s set it up: you have an existing <FORM> element somewhere on your page, and for whatever reason you would like to add elements (such as a hidden field, or a textbox) to this form dynamically from a JavaScript function.

(Sane) Non-IE code:

newField = document.createElement("input");
newField.setAttribute("name", "myNewField");
newField.setAttribute("type", "hidden");
newField.setAttribute("value", "it is a secret");

theForm = document.getElementById("myForm");
theForm.appendChild(newField);

Loverly! A little wordy and all that, but hey, that’s what working (correctly) with the DOM is like, and we get used to it. Though we never love it (that’s where MooTools etc come in…)

Of course, if we do a little peeking around with

alert(theForm.innerHTML);

Everything is beautiful in the “good” browsers (FF and Chrome et al) and then we look at IE. Guess what?

Internet Explorer does not allow you to set the name attribute of an element after it’s been created. Yep. It’s a read-only property. element.setAttribute(“name”, “whatever”) fails. silently.

In some peabrained propellerhead way, I can see that this makes sense – IE used to use “name” the way the DOM uses ID, and changing something’s ID after it’s created can cause havoc. If you’re a lazy-ass, short-sighted programmer of course.

But we already knew that that’s a primary job qualification of the IE development team, right?

Enough griping, Tom you ass, what’s the workaround?

IE has this really ugly (mis)implementation of document.createElement() that fails in all other browsers, where you can actually pass the entire HTML element as a string. Not just the node name (ie: “input”) but the actual HTML (ie: “<input name=’blah’>”).

This is the ONLY time you can set the name attribute – on creating the element.

But I mentioned that it fails (errors out) in other browsers.

So, we wrap the whole ugly baby in a swaddling try…catch statement and send it down the river like so….

Ugly-ass Try…Catch Wrapper for Uglier-Ass IE Element Creation Code

try {
  // for IE, curse it
  newField = document.createElement("<input name='uglyBaby'>");
} catch (error) {
  // for all other sane browsers that bothered to read the DOM specification
  newField = document.createElement("input");
  newField.setAttribute("name", "happyChild");
}

// ... and then you can set all your other attributes nicely here for all browsers...

I need to go puke somewhere. Please excuse me.

Although the Behringer FC-1010 seems to be a simpler match-up for getting foot-pedal control, with expression input, to Ableton Live, the Boss (Roland) FC-50 is a solid choice in a more robust and compact format. Given that I was able to pick one up on Craigslist for about $100, I figured this would be the way to go.

The real challenge with the FC-50 is that it sends MIDI PC (Program Change) data, not CC (Controller Change) data. Since the FC-50 was designed to control patch switching for external synths and guitar effects racks, PC data was the right call. Unfortunately for those of us in the DAW generation, especially Ableton Live users, PC messages are not as useful or versatile as CC data. Ableton Live, specifically, at least as of version 8, converts all PC MIDI data into Pitch Bend (PB) data, and all on the same PB #, so although you COULD use the PB data to trigger, for example, a global clip start, you couldn’t take advantage of the fact that the FC-50 has 5 footswitches. If I wanted just 1 footswitch, there are a lot easier ways to go about hooking one up to Ableton.

Well, getting the FC-50 working exactly as I wanted it proved to be a little challenging for me, given my hardware and software configuration, but for what it’s worth, I”m posting my experience here, in case it may be of use to others. I am by no means a MIDI wizard, but with about 5 hours of research, installation and experimentation, I was able to create a configuration that for now appears to meet my needs, which are:

• leverage all 5 foot-pedals to be able to MIDI- or Key-map to any toggle-based Live control input, such as track start, overdub on/off, move up/down scene etc.
• leverage the Expression pedal input capabilities and map Expression to any continuous controller in Live (not just volume)
• spend no additional money to do all this

Read the rest of this entry »

So I ran into a bit of a snag yesterday when I was working for the first time with the most excellent Greensock TweenLite ActionScript class. Naturally I panicked and blamed everything on the class. Fortunately the author of the class, Jack Doyle was listening in on his forums and responded to my surprise within minutes of my posting the query there. He assured me that his class was iron-tight and pointed me in a direction that led me to uncover the error of my ways.

How naive I was! Ah, the shame of it all.

So, to hopefully forestall any future embarassment on the part of you, my reader, who has miraculously stumbled upon this obscure piece of flotsam in the vast ocean that is the InterMegaWeb, let me expound upon the dangers of ActionScript’s pass-by-reference.

But first, let me set the stage by introducing TweenLite a little. Although the class has absolutely no bearing whatsoever on the problem I was experiencing, the way the class is designed kind of allows one to fall into the trap fairly easily, and makes a good example. And besides, it’s a very useful class, so if this is your first introduction to it, I will consider that I did you a service.

TweenLite serves to bolster ActionScript support for tweening things over time without using the Timeline or the Flash IDE. For those of us foolish enough to try to animate things using code, the built-in native Flash Tween class is woefully poor, performance-wise. There are tests to prove it (beware: when testing the native Flash Tween class, be sure to lower the values as it will crash your browser – that’s just how bad the Flash class is!). The TweenLite tween class is a joy to use.

Let’s say you want to tween a MovieClip named myClip across the stage from x = 100 to x = 500, and from y = 100 to y = 400, and you want it done over 5 seconds:

TweenLite.to(myClip, 5, {x:500, y:400});

The previous example assumes that myClip is already at x = 100 and y = 100. Over the next 5 seconds, it will move its way toward (500,400) incrementally each frame. You don’t have to do a damned thing but sit back and watch. Very sweet.

You can even add other, custom parameters to TweenLite to tweak its behaviour. Say you wanted a 1-second delay before the object actually started to move:

TweenLite.to(myClip, 5, {x:500, y:400, delay:1});

Simple. And then of course I had to get in there, try to make things even more user-friendly and that’s when stuff starting blowing up.

Read the rest of this entry »

This is a quickie. I recently had a lengthy form using the <label> tag, and needed to switch label methods. Being industriously lazy, I figured a Regular Expression search and replace would do the trick. Fortunately DreamWeaver CS4 supports Regular Expressions in its Search and Replace dialog box (as long as you turn the appropriate checkbox on!).

In case you’re not too familiar with the <label> tag, it can be used in two ways:

<label>First Name<input type="text" name="firstName" /></label>

and

<label for="firstname">First Name</label><input type="text" name="firstName" />

They look similar, but the salient difference here is that one form of the <label> tag usage encapsulates the form element, while the other does not. There are various (mostly) CSS-related reasons why you would choose one over the other, most notably in terms of whether you would rather be able to have a block surround your text label and input form, or whether you would rather be able to have two separate blocks (which might need to be encapsulated by further markup – such as an ordered list item, as suggested on A List Apart.

Anyway, I was using the first form, and needed to switch to the second form of the tag. The following two regular expressions will do that for you:

“Find” RegExp: <label>([^<]+)(<input.+name=”([^"]+)” \/>)<\/label> 

“Replace” RegExp: <label for=”$3″>$1</label>$2

What’s cool here is that it automatically populates the “for” attribute of the label with the “name” attribute of the input tag, while leaving the rest in place.

Big Disclaimer: There is a good chance that this RegExp will not work for your specific situation, because it is highly specific. If you are not familiar with Perl-style Regular Expressions, you will most likely not be able to make much use of this unless your input tags are exactly the same as mine (ie: the “name” attribute is the last attribute before the closing />, all your spacing is the same, everything is lower case etc). If you would like me to craft a more generic RegExp, leave a comment and I will do one up.