overriding

I have used a bit of Android code to override the "Done" button in my EditText field: myEditField.setOnEditorActionListener(new TextView.OnEditorActionListener() { @Override public boolean onEditorAction(TextView v, int actionId, KeyEvent event) { if (actionId == EditorInfo.IME_ACTION_DONE) { mySubroutine(); return true; } return false; } }); Activating the field calls up the keyboard, and pressing "Done" evaluates mySubroutine() successfully. However, the keyboard no longer goes away when I press "Done". How do I restore this default behaviour to the routine? just_another_coder Why not:

Why it is not possible to override mutable variable in scala ? class Abs(var name: String){ } class AbsImpl(override var name: String) extends Abs(name){ } Above code gives following compile time error :- variable name cannot override a mutable variable If name is declared val, then above code works fine. If you could override a var with a var, then the overriding member could have a narrower type. (That's how overriding is defined.) You could then assign a value of a wider type and then read it expecting the narrower type, and fail. Illustration of the setter involved: scala> class A ; class

When I override the function noise , the function gets replaced by the new one. But when I override a property with an observer, the old and new value gets both executed. In playground: class Vehicle { func noise(sound: String) { println("Vehicle sound sounds like \(sound)") } } class Train: Vehicle { override func noise(sound: String) { println("A train does: \(sound)") } } Output: var oldTrain = Train() bulletTrain.noise("tjoek tjoek") // Prints: "A train does: tjoek tjoek" But when I do the same with an property with an observer: In playground: class Foo { var something: Int! { didSet {

I have a class that is a super-class to many other classes. I would like to know (in the init () of my super-class if the subclass has overridden a specific method. I tried to accomplish this with a class method, but the results were wrong: class Super: def __init__(self): if self.method == Super.method: print 'same' else: print 'different' @classmethod def method(cls): pass class Sub1(Super): def method(self): print 'hi' class Sub2(Super): pass Super() # should be same Sub1() # should be different Sub2() # should be same >>> same >>> different >>> different Is there any way for a super-class

I'm working on a simple extension for my store and it needs to override a template file. The template in question is used to generate each line item in the list of items in an order. To see what I'm talking about, you can go to My Account->My Orders, select an order, and then scroll down to see the table under "Items Ordered." The default template file I'm trying to replace is sales/order/items/renderer/default.phtml. I have successfully set up the extension to use its own layout.xml file. I can, for example, turn off various blocks on the page. My code for changing the template, however, isn

I'm aware that a params modifier (which turns in one parameter of array type into a so-called "parameter array") is specifically not a part of the method signature. Now consider this example: class Giraffid { public virtual void Eat(int[] leaves) { Console.WriteLine("G"); } } class Okapi : Giraffid { public override void Eat(params int[] leaves) { Console.WriteLine("O"); } } This compiles with no warnings. Then saying: var okapi = new Okapi(); okapi.Eat(2, 4, 6); // will not compile! gives an error( No overload for method 'Eat' takes 3 arguments ). Now, I know that the compiler translates the

Is there a reason one can change the access modifier of an overridden method? For instance, abstract class Foo{ void start(){...} } And then change the package-private access modifier to public , final class Bar extends Foo{ @Override public void start(){...} } I'm just asking this question out of curiosity. Java doesn't let you make the access modifier more restrictive , because that would violate the rule that a subclass instance should be useable in place of a superclass instance. But when it comes to making the access less restrictive... well, perhaps the superclass was written by a