Is it possible to remove questions? I have figured out how to do this by looking at a program made by another member. I have realized that the Greenfoot.getKey() only returns a string, if a key is pressed. I believed that it would always return the key that was last pressed. I have used the following code:

You have to write: In this case you can use null instead of 'any'

Just because a question is solved doesn't mean it should be removed, it's good to have an archive of such threads for other people who might be stuck on similar issues! Also bear in mind that the above code won't account for the arrow keys and the function keys which will put "up", "down", etc. (the name of the key) in the box unless you change the functionality to something else.

I don't think it's correct that using null as a parameter will tell you if any key is down. The API documentation is pretty clear: you have to provide the name of a key.

@davmac Just tested it. You're Right @manster2008 Sorry, I for my mistake, this will work:

I had just written some code a few days ago; it is generalized here. Hope it helps!

I haven't run the above code - but even if nothing else is wrong you're comparing strings with == which is wrong (as in it's highly likely to return false even when they are equal.) So instead of: (and every other occurrence like this) it should be:

Now, that I was NOT aware of! Though, I did know that sometimes (usually with Strings of length only of one) the comparison seems to fail. I will go through my work and make the appropriate corrections.

It's to do with the underlying difference between == and .equals(), the former compares whether the two objects are exactly the same object whereas the latter says whether they're meaningfully equal (even if they're two different objects.) You can have two separate string objects that have exactly the same contents - in this case .equals() will return true (almost always what you want) and == will return false. Sometimes == does appear to work, but if it does it's just a side effect of some of the optimisation Java makes under the hood (there's all sorts of rules you can look up if you like; all you really need to know though is that .equals() should always be used with strings.) One other point, it's generally good habit (well, I think it is anyway) to put the literal first in such comparisons, i.e: not: Why? If myStr happens to be null then the first will return false, the second will throw an exception at runtime (since you're trying to call a method on null, not a string object.)

@mjrb4: Your input was appreciated. Thank you for pointing out that which you consider a good habit. I will try to remember that, and follow in your footsteps in that regard. (though, in the code above, it has been dealt with by line # 10 which ensures that 'myKey' is not null when making further comparisons, which, of course, should still be written with '.equals()' and not '=='). Thanks, again.

No problem! This is the one exception - if you're comparing to null you can safely use ==. In fact you can't safely use equals() here since if myKey is indeed null, you'll be trying to call a method on it which will cause a NullPointerException.