Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 8343 - USER TEST: Not clear which object the execute toolbar button will execute
USER TEST: Not clear which object the execute toolbar button will execute
Status: CLOSED WONTFIX
Product: java
Classification: Unclassified
Component: Unsupported
3.x
All All
: P4 (vote)
: TBD
Assigned To: issues@java
issues@java
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-10 02:36 UTC by jhoffman
Modified: 2007-09-26 09:14 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jhoffman 2000-11-10 02:36:30 UTC
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.
Comment 1 pzajac 2000-11-13 11:01:59 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.
Comment 2 Svata Dedic 2000-11-13 11:48:59 UTC
"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.
Comment 3 Chris Ledantec 2000-11-13 12:17:59 UTC
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.
Comment 4 jhoffman 2000-11-13 16:33:59 UTC
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.
Comment 5 Svata Dedic 2000-11-13 16:41:59 UTC
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 ?
Comment 6 Svata Dedic 2001-04-09 16:22:24 UTC
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.
Comment 7 Dirk Ruiz 2001-04-10 19:38:43 UTC
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."
Comment 8 Svata Dedic 2001-04-10 20:02:18 UTC
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@ ?
Comment 9 Quality Engineering 2003-07-01 13:12:32 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.
Comment 10 Quality Engineering 2003-07-01 13:17:45 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 11 Quality Engineering 2007-09-20 10:09:52 UTC
Reorganization of java component


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo