This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Steps to reproduce: - Copy the code to the editor: --------------------------------------------------------- public class A{ public var attr: Number; public function f () { } } public class C extends A{ } --------------------------------------------------------- - Position the cursor to the scope of C class and type 'override var' --------------------------------------------------------- public class C extends A{ override var } --------------------------------------------------------- - Press <Ctrl + space> The 'attr' attribute is not suggested The same is for the function name: --------------------------------------------------------- public class C extends A{ override function } ---------------------------------------------------------
Reassigned to Petr Nejedly, owner of code completion. Please assign all further code completion issues to him.
Overriden vars (currently) have different AST tree kind (not a VariableTree). This is a known issue with the compiler. We've been promised a possibility of parser change that would get the overriden variables in line with normal variables, but the target milestone for such a change is open.
Updated compiler now makes overriden variable a VariableTree, but it caused NPE in completion code (as the overriden variable tree can't have a Type tree associated). The NPE is fixed in http://hg.netbeans.org/javafx/rev/b7e3787b5b3d so that it now partially works in case the identifier is at least started: public class C extends A{ override var a| }
Added a test covering both NPE and the already working subcase to prevent regressions. http://hg.netbeans.org/javafx/rev/19664d6168b4
The remaining part is rather P3. What is missing is filtering the identifiers to the things that could really be overriden (i.e. superclass members). And also recognizing the construct in case there's no identifier yet, but that may be covered by some work Jan did yesterday (there was a bug in sanitization).
Reassigning javafx bugs to Adam.
Closing all bugs filed against JavaFX 1.x as wontfix. We will support JavaFX 2.0 - please keep opened only bugs against the new release. Thanks.