Bug 184475 - [Viewers] Handler conflicts when viewer types change
Summary: [Viewers] Handler conflicts when viewer types change
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M6   Edit
Assignee: Tomasz Zarna CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 196036 203461 212020 225519 230048 231794 234613 250804 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-27 12:31 EDT by Markus Keller CLA
Modified: 2009-03-03 07:23 EST (History)
7 users (show)

See Also:


Attachments
Patch v01 (3.86 KB, patch)
2009-02-17 08:34 EST, Tomasz Zarna CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2007-04-27 12:31:52 EDT
I20070427-0010

Found these in the log (sorry, no steps):

!ENTRY org.eclipse.ui.workbench 2 0 2007-04-27 16:45:21.578
!MESSAGE Conflict for 'org.eclipse.compare.copyAllRightToLeft': HandlerActivation(commandId=org.eclipse.compare.copyAllRightToLeft,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.ContentMergeViewer$8@186faea),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408): HandlerActivation(commandId=org.eclipse.compare.copyAllRightToLeft,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.ContentMergeViewer$8@c33c4f),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408)

!ENTRY org.eclipse.ui.workbench 2 0 2007-04-27 16:45:21.671
!MESSAGE Conflict for 'org.eclipse.compare.selectNextChange': HandlerActivation(commandId=org.eclipse.compare.selectNextChange,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.TextMergeViewer$31@1cee967),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408): HandlerActivation(commandId=org.eclipse.compare.selectNextChange,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.TextMergeViewer$31@13da390),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408)

!ENTRY org.eclipse.ui.workbench 2 0 2007-04-27 16:45:21.671
!MESSAGE Conflict for 'org.eclipse.compare.selectPreviousChange': HandlerActivation(commandId=org.eclipse.compare.selectPreviousChange,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.TextMergeViewer$32@1d48add),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408): HandlerActivation(commandId=org.eclipse.compare.selectPreviousChange,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.TextMergeViewer$32@e8da0f),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408)

!ENTRY org.eclipse.ui.workbench 2 0 2007-04-27 16:45:21.687
!MESSAGE Conflict for 'org.eclipse.compare.copyRightToLeft': HandlerActivation(commandId=org.eclipse.compare.copyRightToLeft,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.TextMergeViewer$34@1bd69bf),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408): HandlerActivation(commandId=org.eclipse.compare.copyRightToLeft,handler=ActionHandler(org.eclipse.compare.contentmergeviewer.TextMergeViewer$34@69b4ef),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408)

!ENTRY org.eclipse.ui.workbench 2 0 2007-04-27 16:45:21.703
!MESSAGE Conflict for 'org.eclipse.compare.ignoreWhiteSpace': HandlerActivation(commandId=org.eclipse.compare.ignoreWhiteSpace,handler=ActionHandler(org.eclipse.compare.internal.ChangePropertyAction@153c9b),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408): HandlerActivation(commandId=org.eclipse.compare.ignoreWhiteSpace,handler=ActionHandler(org.eclipse.compare.internal.ChangePropertyAction@3e01e7),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408)

!ENTRY org.eclipse.ui.workbench 2 0 2007-04-27 16:45:21.703
!MESSAGE Conflict for 'org.eclipse.ui.edit.text.toggleShowWhitespaceCharacters': HandlerActivation(commandId=org.eclipse.ui.edit.text.toggleShowWhitespaceCharacters,handler=ActionHandler(org.eclipse.compare.internal.ShowWhitespaceAction@168c9a3),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408): HandlerActivation(commandId=org.eclipse.ui.edit.text.toggleShowWhitespaceCharacters,handler=ActionHandler(org.eclipse.compare.internal.ShowWhitespaceAction@8dfc71),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408)

!ENTRY org.eclipse.ui.workbench 2 0 2007-04-27 16:45:21.718
!MESSAGE Conflict for 'org.eclipse.ui.editors.lineNumberToggle': HandlerActivation(commandId=org.eclipse.ui.editors.lineNumberToggle,handler=ActionHandler(org.eclipse.compare.internal.TextEditorPropertyAction@8d189f),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408): HandlerActivation(commandId=org.eclipse.ui.editors.lineNumberToggle,handler=ActionHandler(org.eclipse.compare.internal.TextEditorPropertyAction@14ba145),expression=ActiveShellExpression(Shell {Apply Patch}),sourcePriority=17408)
Comment 1 Michael Valenta CLA 2007-04-27 15:31:42 EDT
This occurs when the viewer type is switched in the Apply Patch wizard. The CompareViewerSwithcingPane needs to create the new viewer before disposing the old one. This means there is a small window of time (i.e a few milliseconds) for which there are conflicting key bindings. I'll try and give this some thought in RC1 to see if there is some way to avoid generating the log messages. If I can't come up with something, we'll just have to live with the messages.
Comment 2 Michael Valenta CLA 2007-05-03 11:55:41 EDT
Bug 179049 has a patch that removes most of the warnings. Unfortunately, we need API to remove the others. Bascially, we need API on ContentMergeViewer that we can call to indicate that a viewer change is about to take place. I worked around this in 3.3 by adapting TextMergeViewer to an internal class in order to deactivate the handlers (This doesn't work for ContentMergeViewer since it doesn't implement IAdaptable). However, I think the best API to add in 3.4 is just a method on ContentMergeViewer that gets called before the viewer switch happens.
Comment 3 Michael Valenta CLA 2007-07-11 10:29:36 EDT
*** Bug 196036 has been marked as a duplicate of this bug. ***
Comment 4 Michael Valenta CLA 2007-12-06 07:36:06 EST
*** Bug 212020 has been marked as a duplicate of this bug. ***
Comment 5 Szymon Brandys CLA 2008-04-15 09:18:36 EDT
Since it involves API changes, it will not be fixed for 3.4. Reassigning to 3.5 for further investigation.
Comment 6 Michael Valenta CLA 2008-05-05 10:24:42 EDT
*** Bug 230048 has been marked as a duplicate of this bug. ***
Comment 7 Martin Oberhuber CLA 2008-05-05 10:50:28 EDT
(In reply to comment #2)
> order to deactivate the handlers (This doesn't work for ContentMergeViewer
> since it doesn't implement IAdaptable).

With an AdapterFactory and Platform.getAdapterManager().getAdapter(), it's possible to adapt even non-adaptable objects. If the Adapter Factory is a private nested class within ContentMergeViewer, it should be capable of creating adapters that have access to the internals of the ContentMergeViewer. The factory likely doesn't even need to be an inner class and one adapter instance is likely sufficient, because the methods in the adapter can be fed with the ContentMergeViewer instance.

Only requirement is that the private nested adapter class implements some "known" interface from the "outside".

Would that open the door for a workaround in 3.4 ?

Comment 8 Michael Valenta CLA 2008-05-05 11:36:04 EDT
Perhaps but, given the place we are in the 3.4 release cycle and the effects of this (i.e. there haven't been any reports of lost functionality only a log message the first time it happens), I don't think it is worth the effort. Do you have a compelling reason why this needs to be addressed for 3.4?
Comment 9 Martin Oberhuber CLA 2008-05-05 11:38:17 EDT
No, just the brain teaser of sneaking in the non-API :-)

But, if you agree that a solution is technically possible without changing API, it might be worthwile changing the target milestone to something that indicates that a solution is possible in the 3.4 stream or 3.4 maintenance stream.
Comment 10 Michael Valenta CLA 2008-05-05 12:16:02 EDT
Again, without a compelling reason to change it, I think the milestone of 3.5 is acceptable (even though Szymon sets those things now and not me). It has nothing to do with whether a fix can be done without an API change (i.e. yes, it may be possible to fix this without an API change but given that there is no compelling reason to do so, the best course of action is to wait until 3.5 and fix the problem the right way). Just my 0.02c.
Comment 11 Tomasz Zarna CLA 2008-07-15 08:42:08 EDT
*** Bug 231794 has been marked as a duplicate of this bug. ***
Comment 12 Markus Keller CLA 2009-01-13 05:57:35 EST
In I20090106-1323, I get these when I
- open a Java editor
- start an Extract Method refactoring
- click Preview
- click Back
- click Preview
Comment 13 Paul Webster CLA 2009-01-13 08:07:33 EST
*** Bug 234613 has been marked as a duplicate of this bug. ***
Comment 14 Tomasz Zarna CLA 2009-01-14 05:59:12 EST
*** Bug 203461 has been marked as a duplicate of this bug. ***
Comment 15 Tomasz Zarna CLA 2009-02-17 06:55:07 EST
(In reply to comment #12)
> In I20090106-1323, I get these when I
> - open a Java editor
> - start an Extract Method refactoring
> - click Preview
> - click Back
> - click Preview

This particular case has been fixed in bug 259413.

Comment 16 Tomasz Zarna CLA 2009-02-17 08:34:26 EST
Created attachment 125885 [details]
Patch v01

Patch proposal for fixing the issue without an API change. This is an extract from "Patch v02" for bug 201116.
Comment 17 Tomasz Zarna CLA 2009-02-27 10:02:01 EST
*** Bug 250804 has been marked as a duplicate of this bug. ***
Comment 18 Tomasz Zarna CLA 2009-02-27 10:02:10 EST
*** Bug 225519 has been marked as a duplicate of this bug. ***
Comment 19 Tomasz Zarna CLA 2009-03-03 07:23:32 EST
Released to HEAD, but filed bug 266840 for the new API on ContentMergeViewer. Available in builds >N20090302-2000.