I’m trying, but don’t quite understand HTMLHeader (under App). I have the following source in it, and it’s not working. It’s supposed to suppress the ‘Backspace’ key so that the browser doesn’t use that as the ‘Back’ button and accidentally exit the application. When I copy and paste this exact code in Dreamweaver, it works fine (regardless where it’s entered, ie. Head, Between Head & Body, Body)… what am I doing wrong?
<script language=javascript>
document.onkeydown = function (e) {
e.stopPropagation();
if ((e.keyCode==8 || e.keyCode==13) &&
(e.target.tagName != "TEXTAREA") &&
(e.target.tagName != "INPUT")) {
return false;
}
};
</script>
It’s getting overridden by our framework.
Well, could you (or somebody) advise on a possible route to a solution for disabling the ‘Backspace’ as the ‘Back’ button? More and more sites are actually doing this via Javascript… even Google does it (it sets focus to the editfield if you press the ‘Backspace’ on it’s main page).
Alright, would I be breaking any license or terms agreement by editing the framework.js in the WebFrameWorks\Global folder to include this for my own reasons?
If not, I’ve found my solution… if so, and I’m unable to edit it then I’m still in search for something and need some desperate assistance.
You should not be editing the framework files. Especially because those files may change with each release, but also because you may inadvertently break other parts of the framework.
I’m aware of the risks; however, I don’t currently know of any other viable solution. I’m willing to hear suggestions, though. Until then, I’ve edited the Xojo.input.keyDown event with this as the first few lines, which seems to do exactly as I needed:
// - personal revision : keep browser from going back a page if user presses 'Backspace' outside of a textfield|input field
if ((event.keyCode == 8) &&
(event.target.tagName != "TEXTAREA") &&
(event.target.tagName != "INPUT")) {
Xojo.input.handleKey(event,"KeyPressed");
return false;
}
Eric, if you’re going to hack the framework (don’t), the right way to do it is to set edited handlers after the first page loads, i.e first time its Shown event is called. The first time you introduce a bug of your own making by editing the framework files, and report it to Xojo or a third party as their problem, there will be a voodoo doll with your name on it.
Haha, Brad… alright. You’re right, and so is Greg. I will try that approach and revert the framework.js to its original state (kept a backup). I wasn’t thinking about those kinds consequences for Xojo, and don’t want to risk adding to their already full plate with issues I’ve created myself. Sorry Greg, for not taking your advice the first time.
How about using WebSession.PrepareSession to add your script into the HTMLHeader string?? I also want to stop users from backing out of my app pages, so would be interested to know if this works.