Correcting Delete Key operation in server

[DeusExMachina]

OK, So I have finally gotten the server pages working such that when a user on a Mac hits the "Delete" key , or PC user hits the Backspace key, the server page does what it should (at least in my perspective.)
If no playlist item is selected, then, like magic, nothing happens. If a playlist item IS selected, then even more magically, it is deleted!

"What's the big deal?" those unfamiliar with kJams server might ask. Well, since time immemorial, standard web browser behaviour was to treat the delete key as equivalent to the back button. While this is fine in most contexts, in kJams, it is NOT. If a kJams server user has their tonight list up, and notices that they have a song in that they do not want, or, say, three copies of the same song, the intuitive thing that almost EVERY user I have talked to or secretly watched over their shoulder during my "studies" of kJams server usage, does is to select that song and hit the delete/backspace key. The last thing they expect is to be whisked away back to Kansas! (OK, maybe not the VERY last thing, but close.)
When this happens, it can be quite jarring, and in fact, I have seen people do double takes.
This little modification prevents that very unintuitive behaviour.

Also, since server is supposed to work as a kiosk, FAIAP, having a user back out of the main screen in this way would not be a good thing, especially since they may assume it worked correctly, or they may get frustrated and walk away. Either way, they remain logged in, and the next person using the machine (if it is a public one) may now start inadvertently adding songs to the previous user's Tonight and Favourites lists!

So anyway, this little mod stops that from happening, and keeps Dorothy firmly in the land of Oz.

Since I am interested in how many people are actually using server, and might find this useful, instead of posting the code directly, I'll ask that you chime in here and let me know if there is any interest. Assuming there is, I will either then post it, along with limited instructions on how to add it in, or I will send it to individuals via PM.

So let me know.

[dave]

want

[DeusExMachina]

<nt>

[DeusExMachina]

UGH, DO NOT DOWNLOAD THIS YET!!!

I just realized I broke the delete key in the search field, too! (I.e. you can't backspace when typing in a search!)

Trying to implement a fix A.S.A.P.

[dave]

lolz

[DeusExMachina]

Well, I have a fix but it is acting weird. It you have the focus in the search field, then after that, everything works fine. Delete deletes in the search field, clicking on an item in a playlist and hitting delete deletes that item. But if you haven't first focused the search field, it still takes you back. I can't figure out why, but I guess I can try to just hack it for now, by forcing focus on the search field. Aye yai yai.

[DeusExMachina]

Crap, still no luck.
Working…

[dave]

[DeusExMachina]

Yes! Finally. Please, please, please beta test me!

Reverse roles, Dave?

main.js

OK, OK, it is kind of a kludge, but it seems to be working, and I have a more elegant solution in the wings, if anyone REALLY cares about such things (awaiting simultaneous IE/nonIE compliant code.)

mainscreen.html

[DeusExMachina]

For those who care about such things, this works by calling a function to intercept the delete key (but only on keyDown events.) When the user is in the searchfield (onFocus event) a global variable (ew) is set to true. When the user leaves the search field (onBlur event) this variable is reset to false.
When the user hits any key while on the page, the onKeyDown event triggers the trapDelete function. This checks to see if the pressed key was delete. If it is, AND the inSearch variable is false, it traps the Delete key from sending an onKeyDown event. Otherwise it passes it through. In this way, in text fields like search, delete continues to work.

Now, since the removeListItem function is triggered by onKeyUp events, which are not trapped, both Fn+Del (forward delete) and Delete (backspace) make it through, and thus do what they are supposed to, remove a list item.

As an historical note, some people complain that Apple continues to use this "non-standard" interpretation of Delete as meaning backspace, instead of the proper forward delete.
Historically, however, Apple is correct. Typographically, just as there is a difference between the <CR> and <LF> keys (with Windows just needing the <CR> to mean <CR>+<LF> but Apple and others correctly requiring both to mean both) technically, backspace just means move the cursor back one space, it does NOT mean delete backward. This comes from old typeset machines and typewriters. This was carried forward with the invention of typewriters with correcting ribbons, where you would first hit backspace to move the carriage backward, and then hit the incorrect letter key while engaging the correcting ribbon.
Blah, blah, blah, the take home message is that the backspace button on a mac keyboard is the historically accurate Left Arrow key.

For those who care about such things!

Anyway, the "more elegant" solution I mentioned earlier does not involve global variables, but instead checks for what field the user is in inside the trapDelete function. The problem is, MS with IE insists on doing this differently than the rest of the entire planet (and just hoping to bludgeon the rest of the world in to compliant submission) using:
window.event.srcElement.type.match("text")

whereas everyone else uses the web standard:
window.event.target.

Once I get the code to work, and test across IE/Safari/Firefox, I'll post the new code. For now, though, the current solution works well!

[DeusExMachina]

OK, for those two of you who have actually downloaded this and noticed the alternating opacity of playlist items, this was residual code from a hack I am working on to put a slide show of pics from a folder behind the playlist items. I have now commented out that line of code, so it should no longer do that. Feel free to delete that line.

[dave]