Userscripts.org

Drat, it's not only there. :-( I forgot to disable the shortcuts in a bunch of places where the user might be entering something:

preferences
networkkommunikation
alliance

I'll fix it in a moment.

Arrrgggh. That's the federationlayer page, right? I'll fix it in a moment.

Plus, I implemented planet changing by Shift-LeftArrow and Shift-RightArrow. :-) (I couldn't use just the arrows, because then you wouldn't be able to edit the resources on the third fleet dispatch page. Even now the editing is somewhat limited - you can't mark numbers by Shift-Arrows - but I think we can live with that.)

Hmm... Fixing the federation page is not trivial... Apparently, its pseudo-window is not an iFrame, as I thought, but is generated on-the-fly, so the URL of the document remains what it was (page=movement)...

BTW, the trading with the Merchant has a similar problem. This script isn't supposed to work there - but it does...

Wait a minute, I have an idea... I think I know how to do it. It's another ugly kludge, but it ought to work... I'll try to do it tomorrow, it's already late here now and I'm tired.

OK, should be fixed now.

also leaving a moon or a planet, when writing password o new name there is the same behaviour.

I can't know "inside" what I am. All I can do is disable it if the URL of the page contains something, or if there is some particular ID in the HTML code of the page - that sort of thing.

OK, I figured out how to determine where the keydown event occurs - but it doesn't help. That script you mentioned has the user enter the search data not in a TEXTAREA but in an INPUT field. And I can't disable my script in INPUT fields, because this is where the cursor is on the third fleet dispatch page when loading the resources - and then the A/N keys won't work to load/unload the resources.

It is possible to disable it in INPUT fields - but I have yet to find a way for figuring out in which INPUT field the cursor is. If you know of such a way - I'm open to suggestions.

Because, as I explained above, I can't disable it in all INPUT fields - or I won't be able to load the resources with a keypress and this is more important to me than supporting some third-party script.

The document.getElementsByName() returns all elements in the whole document that have a particular name= attribute. It doesn't tell me in which element the cursor is.

Now, when the keydown event occurs, I check the nodeName of the target. It tells me the kind of HTML node it was in which the event occurred. So, I check whether it was an INPUT or a TEXTAREA node.

What exactly do you want me to do? You don't have to know JavaScript - just try to express it in a precise human language. I can't know if the cursor is inside the INPUT element of your favorite script, because I don't know how to detect it. I can't check if the cursor happens to be in every possible element on the page on which it is OK for the script to trigger - there are simply too many of them. So, I now simply check if the cursor is inside an INPUT field or in a TEXTAREA and disable only the Shift-Arrow keys there.

What exactly do you want me to do? Disable everything in INPUT fields unless those are the fields for loading resources? But those aren't the only important ones. On the first fleet dispatch page, there are heaps of INPUT fields - one for each ship type. I have to support the "A" and "N" keys there. Should I also check if the INPUT field in which the keypress event occurred happens to be one of them and not disabled the script then? (I'm not sure that's even easy - I haven't looked if each one of them has its own ID by which it can be accessed.) How many other INPUT fields there might be in the game where the script should do something but won't if I forget to explicitly permit it? Oh, yes, the coordinates for the target, for instance - on the second fleet dispatch page - each one of them is an INPUT field and I have to support the hotkeys for the target type and the speed of the fleet. And God knows what else.

No, sorry, but that's way too much trouble for the simple reason of achieving compatibility with some third-party script which isn't properly written in the first place! Why doesn't that INPUT field have an ID, for instance?

Sigh... OK, I'll turn off the script of Antigame's options dialog is opened. (Thank goodness, it has its own ID, so I can detect that it is opened.)