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.
From the FFJ user test: The user clicks the Execute toolbar button with non-executable class in focus in the editor, but executable class selected in the explorer (but not in focus). However, it is not clear to the user that the executable class in the explorer is not "in focus" and they expect it to be executed. The user is then confused by the error that appears in the output window in the Running workspace when the IDE attempts to execute the non-executable class The Execute command/toolbar button should be disabled if the class in focus (whether in the editor or in the explorer window) is not executable. Also, the selected node in the explorer should be altered (perhaps gray) when the explorer is not in focus.
This bug is enhacement. Core team has not responsibility to this bug. Disabling execution command is not the best idea. Excution action for example do at first time compilation.
"Executability" is not straightforward; it means different things for ordinary Java classes, for classes deployed on an application server etc. The user can specify its own execution method that even don't look for void main(String[]) so executability detection can't be hardcoded into IDE's base.
i think what the concern is here is that execute is enabled on classes when they will produce an error. we should do some basic checking that if there isn't any user or other-module defined execution setting on the class and there isn't a main method then execute should not be an enabled action.
Chris is correct. But I also believe that somehow graying or hiding the selection in the explorer (since it's currently not relevant when you're in another top level window) would make it clearer which object is in focus.
I hate to said that, but I don't think that source parsing is reliable enough so action enabling should depend on it. Consider a source with errors; user wants to run it so he triggers Run action, the source will be compiled and the errors will be shown to the user. The parser might not even see main() method in source that has some serious errors - so if the action is available depending on presence/absence of run() (in the default case, of course), the user won't be able to trigger the action and will need to explicitly invoke compilation. Is that acceptable ?
No response; closing as WONTFIX. I think that Run action should be available at all times on all nodes that supports an Executor. It is Executor's task to print out some reasonable message.
I can live with not disabling Execute. It would, however, be nice for the IDE to warn the user that she is about to do something that is a known error (i.e., execute something without a main procedure). Otherwise, it confuses the user and makes us look a bit silly! So here's my suggestion. If the user tries to execute something without a main procedure (and that has no other means of execution), we pop up a warning dialog that says: "Executing <filename> will fail, since it does not have a main procedure. Would you rather Build it instead?" [Build] [Execute] [Cancel] I imagine this should also have a checkbox that says, "Don't show this message again."
After some more thinking: If the file is not built (it has some errors or something), the Execute action will notice that and will try to compile the file - resulting in errors. If the file is up-to-date (for some reason), it can be reliably scanned and the executor can detect that something is wrong. The point is, that only the executor can detect this situation, not the java (or whatever other) object itself, since it can be configured to do something completely custom by the user. Nice approach would be that used in filesystem-object node communication: give the executor a chance to affect the node's icon (or overall presentation). If possible, compiler should be given the same option. What about moving this discussion to nbdev@/nbui@ ?
Resolved for 3.3.x or earlier, no new info since then -> closing.
Resolved for 3.4.x or earlier, no new info since then -> closing.
Reorganization of java component