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.
| Summary: | USER TEST: Not clear which object the execute toolbar button will execute | ||
|---|---|---|---|
| Product: | java | Reporter: | jhoffman <jhoffman> |
| Component: | Unsupported | Assignee: | issues@java <issues> |
| Status: | CLOSED WONTFIX | ||
| Severity: | normal | CC: | cledantec, druiz, jmzourek, mvenkatraman |
| Priority: | P4 | ||
| Version: | 3.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
|
Description
jhoffman
2000-11-10 02:36:30 UTC
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 |