Bug 33557 - ClassCastException from CloneViewAction
ClassCastException from CloneViewAction
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Window System
3.x
All All
: P1 (vote)
: 3.x
Assigned To: Peter Zavadsky
issues@platform
:
: 33129 (view as bug list)
Depends on:
Blocks: 33116 33117 33126 33224 33514
  Show dependency treegraph
 
Reported: 2003-05-13 13:34 UTC by David Strupl
Modified: 2008-12-23 09:39 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Diff of patch (2.57 KB, patch)
2003-05-13 16:39 UTC, Peter Zavadsky
Details | Diff
Patch for release 3.5 (put into lib/patches) (27.07 KB, application/zip)
2003-05-14 15:00 UTC, Peter Zavadsky
Details
Diff of patch for release35 (2.53 KB, patch)
2003-05-14 15:01 UTC, Peter Zavadsky
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2003-05-13 13:34:26 UTC
Tested on 3.5 beta. Might be fixed already. Please 
confirm. I even suggest fixing this for 3.5.

1. Right click project tab ("Project Default"). 
2. Select "Clone view"
Exception occurs.

The issues 33126, 33224 and 33514 are probably nonsense. 
The root cause of the exception is in 
DefaultContainerImpl. It does not work for the 
TopComponents that are not cloneble!

Proposed fix (please note that the diff is screwed - you 
have to reformat it (or read it and apply similar diff)) 
to 
src/org/netbeans/core/windows/frames/DefaultContainerImpl.j
ava

895c895
<         if (selected instanceof TopComponent.Cloneable)
---
>         if (selected instanceof TopComponent.Cloneable) {
896c897,899
>         } else {
>             clone.setActionPerformer(null);
>         }
1518c1521,1523
<         am.put(clone.getActionMapKey(), new 
PerformerAction(container, TYPE_CLONE_ACTION, selected));
---
>         if (selected instanceof TopComponent.Cloneable) {
>             am.put(clone.getActionMapKey(), new 
PerformerAction(container, TYPE_CLONE_ACTION, selected));
>         }
Comment 1 mslama 2003-05-13 13:57:21 UTC
It depends on position: It can be handled either by TopComponent (if
TopComponent provides CloneViewAction it should also implement
TopComponent.Cloneable interface - here the problem is that
TopComponent default action set contains CloneViewAction). Perhaps it
should be handled in winsys code too. Anyway it is nonsense to provide
action which is never enabled so suggested fix is just workaround. All
known TopComponents already fixed this problem. This problem was
already fixed for Project tab.


*** This issue has been marked as a duplicate of 33116 ***
Comment 2 David Strupl 2003-05-13 14:54:33 UTC
Nope! The TopComponent itself provides the action. If you 
just create a TopComponent like this:

MyTC extends TopComponent { }

Please try to use this as an example. I did not supply 
CloneAction. Please point me to the doc where it says that 
you have to override getActions in TopComponent. It says 
you should. That means you should. Feel free to decrease 
the priority when it was fixed for the projects tab.
Comment 3 mslama 2003-05-13 15:03:07 UTC
Some authority should provide us with correct behaviour. As I said
before: Providing CloneViewAction as default action of TopComponent IS
problem because TopComponent does NOT implement
TopComponent.Cloneable. Unfortunately removing this default action
could break functionality of some TopComponent subclasses which rely
on this.

Correct solution IMO is to remove CloneViewAction from TopComponent.
-> Subclass which wants to support CloneViuewAction MUST implement
TopComponent.Cloneable AND overwrite getActions().
Comment 4 Jesse Glick 2003-05-13 15:37:48 UTC
I agree that TopComponent.getActions should not include
CloneViewAction. Or it could just include CloneViewAction if and only
if this instanceof TC.Cloneable.

"removing this default action could break functionality of some
TopComponent subclasses  which rely on this" - "break functionality"
is a pretty strong term for that I think. The Javadoc does mention
that the default impl includes the clone action. However the clone
action is also always available in the Windows menu. Even if the
action is removed from *every* popup menu no functionality is being lost.

In any event, the window system should of course just disable the
action if the selected component is not clonable, rather than throwing
a CCE.
Comment 5 Peter Zavadsky 2003-05-13 16:26:42 UTC
Well, it is regression (probably introduced when new actions put in).
Before clone view action was disabled for TC's which didn't implement
the TC.Cloneable. It should be repaired.

Comment 6 Peter Zavadsky 2003-05-13 16:39:04 UTC
Fixed in [trunk]

core/windows/../frames/DefaultContainerImpl.java 1.3
               /util/WindowUtils.java 1.3

Note: Yes it is regression introduced when merged new actions. The fix
makes the behaviour like before, and also adds check for the CCE.
Comment 7 Peter Zavadsky 2003-05-13 16:39:54 UTC
Created attachment 10285 [details]
Diff of patch
Comment 8 David Strupl 2003-05-13 16:49:26 UTC
Cool. At least for the trunk. I will update all our 
modules for 3.5 to always either implement cloneable and 
contain clone action or not to contain clone action.

Thanks.
Comment 9 mslama 2003-05-13 16:54:30 UTC
Peter I suggest to modify also TopComponent as Jesse suggested:

> I agree that TopComponent.getActions should not include
> CloneViewAction. Or it could just include CloneViewAction if and
> only if this instanceof TC.Cloneable.
Comment 10 Marian Mirilovic 2003-05-14 09:53:28 UTC
[s1s5](030502)

Invoke Clone View action on some top components (Debugger window issue
33224, Welcome issue 33126, Form issue 33514, - already workarounded
Explorer Projects tab 33116, Output tab issue 33117)->
ClassCastException rises (see attachment
http://www.netbeans.org/issues/showattachment.cgi?attach_id=10254&file=exc.txt
)

It's regression against NB3.4, there is Clone View action disabled and
we prefer disabling action istead of removing.
Comment 11 mslama 2003-05-14 11:07:46 UTC
Second part of fix for main trunk: TopComponent now does not provide
CloneViewAction when it does not implement TopComponent.Cloneable. It
means that workaround done in subclasses (removing CloneViewAction)
can be reverted in trunk. I will do that.

openide/src/org/openide/windows/TopComponent.java r.1.98
Comment 12 mslama 2003-05-14 12:33:27 UTC
*** Issue 33129 has been marked as a duplicate of this issue. ***
Comment 13 Peter Zavadsky 2003-05-14 15:00:40 UTC
Created attachment 10297 [details]
Patch for release 3.5 (put into lib/patches)
Comment 14 Peter Zavadsky 2003-05-14 15:01:28 UTC
Created attachment 10298 [details]
Diff of patch for release35
Comment 15 Marian Mirilovic 2003-05-14 15:29:15 UTC
patch verified
Comment 16 mslama 2003-05-14 16:36:48 UTC
I had to fix previous commit to TopComponent. Fixed TopComponent is
trunk is now r.1.99

openide/src/org/openide/windows/TopComponent.java r.1.99
Comment 17 mslama 2003-05-14 16:38:37 UTC
Diff looks ok. Verified.
Comment 18 _ ttran 2003-05-14 23:44:00 UTC
approved for 3.5
Comment 19 Peter Zavadsky 2003-05-15 08:37:57 UTC
Merged into [release35]

core/../windows/frames/DefaultContainerImpl.java 1.75.2.1
               /util/WindowUtils.java 1.48.28.1
Comment 20 Marian Mirilovic 2003-05-19 16:58:35 UTC
verified in [s1s5](030518)


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