Community
Participate
Working Groups
I have an editor that needs to confirm closure with the user (and give the user the option to cancel closure) even if it isn't dirty. This could be achieved by having WorkbenchPage.closeEditor call a method such as boolean IEditor.confirmClosure(), which would by default return true, but could be over-ridden by subclasses. My reason for wanting this is that my editor interacts with non-Eclipse processes. These need to be informed when the editor closes - which prompts certain actions. Currently I have subclassed IEditor.dispose to notify the user of the implications of closing an editor. However this means that the user has no control over these actions, since dispose is called too late for the close command to be cancelled.
Interesting. So your editor is not dirty, i.e. the user has not done something to have initiated a change somewhere? And saving what is in the editor is not actually what you are doing, but rather when the user is done with the editor it will propegate changes to other processes. I'm still not clear why this is not dirtyness, or in this case you're not really an editor but more like a view (the navigator for example) manipulating the file system for example.
Short response: On reflection, I think I can use the dirty flag and over-ride doSave to achieve the functionality I'm after. Longer Response: My application is a script editor. Users edit scripts as text files (making them dirty in the usual way). They can also 'play' the script, sending bits of it out to an external process (in this case, a theorem prover sitting on a different machine). This is similar to stepping in a debugger. It does not dirty the file, and no save is required. The external process needs to know which script files it's processed/is processing, and will only work on 1 script at a time. When my users close a script editor, they are given a choice between processing the rest of that script or retracting the bits already processed. Since they might not have realised/remembered this would happen, it would be nice to also give them an option to cancel the close.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
