Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 315332

Summary: [Viewers] [Provider] ClassCastException happened at jface when selecting tree with using picture-capture software.
Product: [Eclipse Project] Platform Reporter: KAM <kazuaki.matsuba>
Component: UIAssignee: Platform UI Triaged <platform-ui-triaged>
Status: RESOLVED FIXED QA Contact: Hitesh <hsoliwal>
Severity: normal    
Priority: P3 CC: bokowski, hidenobu.shinozuka, kazuaki.matsuba, soichiro.yoshimura, youhei.hina
Version: 4.0   
Target Milestone: 3.7 M1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Snippets for causing Jface bug
none
Patch V01 none

Description KAM CLA 2010-06-01 21:59:38 EDT 
Build Identifier: M20090917-0800

We are manipulating two software - one is our developing software and the other is picture-capture software.
When we select tree at our developing software, then ClassCastException happend.

This is the stack trace(scroll below)

java.lang.ClassCastException: org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider cannot be cast to org.eclipse.jface.viewers.ColumnLabelProvider
	at org.eclipse.jface.viewers.SWTFocusCellManager$4.getName(SWTFocusCellManager.java:190)
	at org.eclipse.swt.accessibility.Accessible.get_accName(Accessible.java:932)
	at org.eclipse.swt.accessibility.Accessible$1.method10(Accessible.java:87)
	at org.eclipse.swt.internal.ole.win32.COMObject.callback10(COMObject.java:155)
	at org.eclipse.swt.internal.win32.OS.CallNextHookEx(Native Method)
	at org.eclipse.swt.ole.win32.OleFrame.getMsgProc(OleFrame.java:307)
	at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:2975)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3468)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)

Reproducible: Always
Comment 1 Boris Bokowski CLA 2010-06-02 14:10:00 EDT 
We should fix this for 3.6.1.

KAM, would you be able to attach a small snippet that shows how the JFace viewer is set up?
Comment 2 KAM CLA 2010-06-02 22:19:32 EDT 
Created attachment 170906 [details]
Snippets for causing Jface bug

This attachment file is a simple snippets making a simple tree structure, which cause ClassCastException.

Please unzip this attachment file and import.
Comment 3 Hitesh CLA 2010-06-03 03:04:42 EDT 
Created attachment 170916 [details]
Patch V01

(In reply to comment #1)
> We should fix this for 3.6.1.
> 
> KAM, would you be able to attach a small snippet that shows how the JFace
> viewer is set up?

CellLabelProvider labelProvider = viewPart.getLabelProvider();
if (labelProvider instanceof ILabelProvider)
   event.result = ((ILabelProvider) labelProvider).getText(element);

The above should fix the CCE.

Boris, do we not need to take care of IStyledLabelProvider ?
Comment 4 Boris Bokowski CLA 2010-06-03 09:28:16 EDT 
Yes, we should test for IStyledLabelProvider as well.

However, there are other cases that would still be unaccounted for, for example org.eclipse.ui.internal.ide.dialogs.PathVariablesGroup.ValueLabelProvider.

Another approach would be to create a ViewerCell object and call CellLabelProvider.update(viewerCell), and then only using whatever was passed to viewerCell.setText().
Comment 5 Hitesh CLA 2010-06-11 07:43:55 EDT 
(In reply to comment #4)
> Yes, we should test for IStyledLabelProvider as well.
> 
> However, there are other cases that would still be unaccounted for, for example
> org.eclipse.ui.internal.ide.dialogs.PathVariablesGroup.ValueLabelProvider.
> 
> Another approach would be to create a ViewerCell object and call
> CellLabelProvider.update(viewerCell), and then only using whatever was passed
> to viewerCell.setText().


Something along the lines of 

labelProvider.update(cell);
event.result = cell.getText();

Why create a new viewercell? and this may have some additional cost although a small one .
Comment 6 Boris Bokowski CLA 2010-06-11 11:02:31 EDT 
(In reply to comment #5)
> Why create a new viewercell? and this may have some additional cost although a
> small one .

Do we already have a ViewerCell object? (sorry, don't have the code in front of me right now)

The reason for going with update(ViewerCell) and then calling viewerCell.getText() would be that we would be out of the business of doing instanceof checks against the label provider and instead use the existing logic in the framework.
Comment 7 Hitesh CLA 2010-06-25 06:13:48 EDT 
(In reply to comment #6)
> The reason for going with update(ViewerCell) and then calling
> viewerCell.getText() would be that we would be out of the business of doing
> instanceof checks against the label provider and instead use the existing logic
> in the framework.


> 
> labelProvider.update(cell);
> event.result = cell.getText();
> 
Changes released to HEAD. Thanks Boris. 

See Bug 290461. Just wondering if we need to run any performance tests ?
Comment 8 Boris Bokowski CLA 2010-06-25 13:40:28 EDT 
(In reply to comment #7)
> See Bug 290461. Just wondering if we need to run any performance tests ?

The change is only in the method getName(AccessibleEvent), isn't it?  I don't think we have any performance tests for this, nor do I foresee any potential performance probelms since I don't think this method is going to be called in bulk on many tree items.
Comment 9 Boris Bokowski CLA 2010-06-25 13:51:23 EDT 
(In reply to comment #7)
> Changes released to HEAD. Thanks Boris. 

This bug is targeted for 3.6.1 but you said you released to HEAD. Could you please update the target milestone accordingly, and create another bugzilla for putting this fix in R3_6_maintenance as well? Thanks!
Comment 10 Hitesh CLA 2010-07-05 06:03:43 EDT 
(In reply to comment #9)
> (In reply to comment #7)
> > Changes released to HEAD. Thanks Boris. 
> 
> This bug is targeted for 3.6.1 but you said you released to HEAD. Could you
> please update the target milestone accordingly, and create another bugzilla for
> putting this fix in R3_6_maintenance as well? Thanks!

Thanks Boris. 

From some reason this slipped from my mind . I have create a clone of this ,Bug 318862 , for fix in 3.6.1. Marking this as fixed and updating the target milestone.