Community
Participate
Working Groups
1) create junit project and import source (as in smoke test) 2) modify any source file but don't save it 3) delete underlying JUnit project 4) click into dirty editor 5) when asked whether to save the contents say "Yes" Observe: a completely empty Save As dialog appears 6) dismiss dialog with "Cancel" Observe: outliner is still there 7) delete elements from outliner Observe: sometimes you get an error dialog sometimes the action is silently ignored 8) perform "Organize imports" from context menu Observe: Walkback, which is not reported in log (see below) Error alert with strange titel "AddGetterSetterActionFailed" java.lang.reflect.InvocationTargetException: Java Model Exception: Java Model St atus [ does not exist.] at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(Java Element.java:442) at org.eclipse.jdt.internal.core.PackageFragmentRoot.getUnderlyingResour ce(PackageFragmentRoot.java:255) at org.eclipse.jdt.internal.core.PackageFragment.getUnderlyingResource(P ackageFragment.java(Compiled Code)) at org.eclipse.jdt.internal.core.Openable.getUnderlyingResource(Openable .java:212) at org.eclipse.jdt.internal.ui.util.DocumentManager.getUnderlyingResourc e(DocumentManager.java:48) at org.eclipse.jdt.internal.ui.util.DocumentManager.<init>(DocumentManag er.java:41) at org.eclipse.jdt.internal.ui.codemanipulation.ImportsStructure.create( ImportsStructure.java:238) at org.eclipse.jdt.internal.ui.codemanipulation.OrganizeImportsOperation .execute(OrganizeImportsOperation.java:141) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModify Operation.java:66) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1183 ) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOp eration.java:78) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:266) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDi alog.java:354) at org.eclipse.jdt.internal.ui.javaeditor.OrganizeImportsAction.run(Orga nizeImportsAction.java:64) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:423) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(Act ionContributionItem.java(Compiled Code)) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handle Event(ActionContributionItem.java(Compiled Code)) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handle Event(ActionContributionItem.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java(Compiled C ode)) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java(Compiled C ode)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java(Compil ed Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code)) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java(Compile d Code)) at org.eclipse.ui.internal.Workbench.run(Workbench.java:732) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoa der.java:815) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:285) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:69) at org.eclipse.core.launcher.Main.run(Main.java:311) at org.eclipse.core.launcher.UIMain.main(UIMain.java:43) NOTES: EG (6/7/2001 11:15:22 AM) deleting a project should close all its editors. We had this behaviour in the tech preview. Without this change many strange followup errors can occur. Suggest fix JW (6/7/01 5:33:18 PM) Ok to fix. EG (6/7/2001 1:07:26 PM) see also 1GEWU4O: ITPUI:WIN2000 - SEVERE - Changes lost while closing workbench 1GEYMVK: ITPJUI:WINNT - strange SaveAs dialog when deleting project EG (6/7/2001 9:50:05 PM) This can be fixed in the AbstractTextEditor, however this would require that PDE and other editors have to copy the code. Moving to ITPUI KH (6/8/2001 5:27:53 AM) Fixing it in the UI would solve the more likely scenario. However, if instead of deleting the project from within eclipse the project was deleted externally (eg. use the file explorer). The exact same case arrises and there is nothing that the workbench could do to solve this problem. The editor is already partially handling this case. Until Core provides notification of external callbacks a full fix would be for editors to handle this case. [... now we can have the discussion about every editor vs workbench editor framework handling it] EG (6/8/2001 12:00:12 AM) [and the discussion starts again...] Regarding workbench vs. editor responsibility. The workbench should not show editors from a deleted project. This rule has to be established by the workbench and not the individual editors. The problem of delegating establishing this rules to the editor means: * the API for implementing an Editor becomes more and more fad (serious) * code duplication (not serious) * likely inconsistent UI and strange errors situations that are filed against the workbench instead of the editor implementors (serious) DS (6/8/01 10:42:45 AM) In the workbench this problem may be handled in 2 places: in each individual action or in the workbench framework. 1. If we do it in the workbench framework we will fail. The workbench does not know what relationship exists between a given object and the editors which may be open on it. We understand IResources. That's it. Unfortunately, many plugins go well beyond this. - Take the Package View, where you can open up classes in an external jar. These are not IFiles. If a project with external jars is closed how can we possibly infer any relationship between the project and the editor? - Take the Repository View, where you can open up IStorage items. These are not IFiles. If a repository is closed how can we infer any relationship between the repository and the editor? 2. If we do it in each individual action we will encounter the same ambiguity as found in the workbench framework. it will also lead to code duplication within each action and inconsistent behavior between actions. One action may forget to do the editor close check. Another may implement a "better, special" algorithm. I thoroughly believe the place to do this is the editor. It contains the domain knowledge required to interpret model specific events appropriately, and provides centralization to reduce code duplication. The behavior for each editor type will be consistent. The behavior across editor types may be slightly inconsistent, but there are two points which minimize my concern in this area. (a) The typical user may invoke hundreds of actions and only use a handful of editors ( 1 to 5 ? As a java developer I may only use 1 ). A slight inconsistency among 1 to 5 familiar editors is much better than a slight inconsistency among 100 rarely used actions. (b) The editor framework gives us a great way to provide the default behavior for free. KH (6/8/2001 11:20:15 AM) The Workbench's editor framework is "thin". As a post June activity it should be improved so that editor implementors do NOT have to handle this case. Maybe we could even get support from core so we can do it right?! KH (6/8/2001 11:53:40 AM) This must be fixed post June. EG (6/8/2001 7:12:19 AM) Discussed with KUM and we came to the conclusion that the safest route is to make this change in the editor (for now). It is important that this is revisited after June. KH (6/8/2001 1:19:52 PM) Yes. KUM (6/9/01 1:21:43 PM) Adapted AbstractTextEditor so that the stale state cannot occur. Build > 121. EG (6/9/2001 12:33:48 PM) reviewed KH (6/12/2001 7:03:33 AM) Must address editor framework issues.
PRODUCT VERSION: Smoke 120
Consider additional improvements post 2.0
reopened for investigation
Main issues are solved.
