Maybe you're a freak of nature who's memorized the entire Unicode table. Maybe you already have a handy dandy keycode chart plastered somewhere on your cubicle wall.

Then again, maybe you don't.

I frequently find myself searching for keycodes when I'm writing keyboard listeners; sure, it's a simple matter of glancing at the internet, but for those (e.g., people like me) that can't be bothered with such things, I threw together the following little application (click here to download):

The EXE is around 3 M because (I can only assume!) the projector makes it so -- the SWF itself (included in the ZIP) is roughly 20 K.

To use it, just launch it and start mashing your keyboard! It's not terribly smart (it thinks the regular plus sign [+] is a double angle bracket [»]) -- and decidely sparse -- but if all you want to know is "What's the keycode for 'y'?", keyc will definitely do the trick.

Update: I noticed a few problems with some of the regular expressions governing em dashes. I've updated them accordingly, so if you're actually using this class, please re-download it!

Lots of stuff I do for work requires either closed captioning or walls of text—all of which gets loaded in through XML files.

Normally, I wouldn't bother with converting a normal quote (") to a "smart quote" (y'know, that crap Microsoft Word's always doing), but for some reason, I figured I'd give it a go. The following class is the result:

Typographize class (AS3)

I'm sure others have done something similar -- and quite possibly better -- but here's my attempt. It has a few methods that allow you to "smarten" either the entire blob of text or a subset of things (like double quotes, single quotes, em dashes, etc.). There's a method called only that may or may not work—I haven't tested it. At all. (But I do know its presence doesn't throw any errors, so good enough for now!)

It's poorly commented (when commented at all), but to use it, just plop it in your project's directory and try something like this:

var myString:String="This is an \"unsexified\" blob of 'text' --
I'm not even kidding! (You can also throw
<i class=\"my-italic-class\">\"a small subset of
Flash-supported HTML tags\"</i> in there, and it'll respect
the quotes [that is, it'll leave them alone] within the tag!)";
 
trace (Typographize.all(myString));

which will output the following:

This is an “unsexified” blob of text—I’m not even kidding! (You can also throw “a small subset of Flash-supported HTML tags” in there, and it’ll respect the quotes [that is, it’ll leave them alone] within the tag!

If you like it, well, there you go!

Note: For some reason, when tracing to the Output panel, the modified quotes (double and single) don't always show up; if you assign the output to the text or htmlText property of a textField, however, you'll see that everything does what it should.

I'm creating a function that accepts the contents of an XML node as an argument (or is it a parameter? I'm never sure...) and splits it into an array. Not rocket science.

Here's the thing, though: Because I can't guarantee that people editing or creating the XML files with which these functions are intended to work will enter things correctly, I'm trying to make them as...accepting as possible; for example, if someone were to use the following:

 
<panel onExit="prev   : p1,     next:      p4">...</panel>

bad things would happen if I don't allow for such an arbitrary placement of commas and colons.

I initially tried cleaning it up like this:

myArr=panel.@onExit.toString().split(/(\W*),(\W*)/i);

which returns something like...well, something unusable. According to my handy-dandy little regular expression thingy (RegEx-Buddy), such an expression should split the above pseudo-XML quite nicely. In practice, however, it doesn't.

So I recreated all of the above in Javascript -- and experienced the same result.

Oddly enough, if you do the following:

myStr=panel.@onExit.toString().replace(/(\W*),(\W*)/i, ",");
myArr=myStr.split(",");

everything looks like it should. I really would have preferred the one-line method, since I'm lazy and not a fan of having to write extra lines when I don't think I should have to, but since it doesn't work (for me, anyway), the two-line method's not terrible.

Just thought I'd throw that out there.