Summary: | [model] [watch/edit] reword prompt preference to indicate that it may not prompt in all cases | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Martin Aeschlimann <martinae> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | dirk_baeumer, jean-michel_lemieux, philippe_mulet |
Version: | 3.0 | ||
Target Milestone: | 3.3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Martin Aeschlimann
2004-06-15 04:23:54 EDT
I don't know about #performEdit. We do call #validateEdit on classpath file iff it is read-only. Furthermore, we cannot pass a UI context to VCM as we are sitting in a core component. There isn't much we can do here. I suspect that when null and some UI is around, VCM should provide its own context or way to surface a dialog to user as it promised in its preferences. Moving to team for further investigation. The spec for validateEdit says that if a null context is provider the implementer should perform the validateEdit in a headless manner. I've verified that changing the build patch *does* call validateEdit correctly but as Philippe noted it provides a null context. The watch/edit preference could be re-worded to say "when possible". why not use the active shell if null is passed? The spec says that we can't. Even though JDT Core is invoking the validatEdit hook, it is not being invoked in a headless environment so it is a bug not to pass a UI context. Either JDT Core should provide API for their clients to pass a Shell through as an object (as is done by the validateEdit hook itself and by refactoring) or the client that is causing the change should perform the validateEdit up front before making the change. I understand that neither of these is ideal but this is how validate Edit is specified and we're stuck with it. Moving back to JDT Core. This would need a new API. Post 3.2. As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |