backspace in Internet Explorer

[Steve]

I have a webset in which users type in fields. But if users try to erase with the "backspace" key in Internet Explorer, instead of erasing their text, Internet Explorer jumps back to the previous web page in its history.

This does not happen in FireFox or Safari. In those browsers, backspace just erases your text.

Windows discussion boards are full of complaints about this "feature" of Internet Explorer. Apparently, backspace does erase text if the focus is on a regular browser field, such as in a form. But fields in a LiveCode weblet are apparently not recognized as browser fields, so the browser sends you back in history.

This makes erasing difficult in Internet Explorer. You have to use arrows and the forward delete key. Users rarely remember to do this and keep jumping out of my revlet by accident.

Does anyone know a way to "trap" the backspace key and get it to erase the text in a field, or to get the weblet fields recognized by Internet Explorer as real fields, so the backspace key erases in them?

Thanks in advance,
Steve Alessi

[Mark]

Hi,

Apparently, this is an IE bug rather than a LC bug. Do a simple search with a search engine and the first link gives you the answer.

Kind regards,

Mark

[Steve]

Mark,

Yes, I know that. My saying it is an Internet Explorer "feature" is my way of saying it is an IE bug. My question was really, does anyone know a workaround in LiveCode to avoid this IE bug?

Steve Alessi

[mwieder]

I believe the browser handles keystrokes before handing them off to plugins, so no, I don't think this possible short of another IE plugin to fix the backspace "feature". And since nobody's come up with one of these yet to my knowledge I wouldn't put much hope into that.

[Mark]

Hi Steve,

I don't think this can be solved in LiveCode currently.

May I ask why you are still using the plugin? It is available for 32 bit only while all current computers are 64 bit.

Kind regards,

Mark

[mwieder]

Mark-

Like it or not, there *are* valid use cases for deploying revlets. As, for instance, when you need to provide a stack solution in a situation where an IT department will not allow the installation of executable applications, but will allow browser plugins. School environments, for example.

[Mark]

Hi Mark,

I have been in such situations and basically it means that school IT deparments simply refuse to install the plugin.

Kind regards,

Mark

[mwieder]

Yeah, I've been there too. But sometimes it's easier to talk them into installing a browser plugin than to allow the installation of executable apps without having to have them vet each one. Gives them more control and they like that. YMMV.

[Mark]

Hi Mark,

It might be easier, but apparently not. If I were a network admin and wanted to keep control of things, I'd prefer to check out each executable myself rather than allowing people to run arbitrary stacks through a plugin. This is also what I've learned from experience while dealing with IT deparments at schools and universities. Kind of strange that this doesn't seem to apply to Flash.

Mark