| ClassCastException in FillLayout.flushCache() [message #104816] |
Fri, 12 September 2008 18:41  |
Eclipse User |
|
|
|
Originally posted by: felix.mayer.erdas.com
In RAP 1.1.1, calls to Display.sleep() alwasy seem to end up in a
ClassCastException. It seems that FillLayout.flushCache() assumes it has
FillData, but actually it has GridData. Should I open a bug for this?
Sep 12, 2008 2:38:32 PM org.eclipse.rwt.internal.lifecycle.RWTLifeCycle
afterPhaseExecution
SEVERE: Could not execute PhaseListener after phase 'PROCESS_ACTION'.
java.lang.ClassCastException: org.eclipse.swt.layout.GridData
at org.eclipse.swt.layout.FillLayout.flushCache(FillLayout.java :180)
at org.eclipse.swt.widgets.Composite.changed(Composite.java:495 )
at
org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er$1.doVisit(TextSizeDeterminationHandler.java:81)
at
org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:32)
at
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:46)
at
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
at
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
at
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
at
org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
at
org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er.afterPhase(TextSizeDeterminationHandler.java:128)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.afterPhaseEx ecution(RWTLifeCycle.java:390)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:191)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:297)
at org.eclipse.swt.widgets.Display.sleep(Display.java:703)
at
org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(Wo rkbenchAdvisor.java:361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2389)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2347)
at org.eclipse.ui.internal.Workbench.access$5(Workbench.java:22 00)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:425)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:408)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:157)
at com.lggi.esp.rcp.EntryPoint.createUI(EntryPoint.java:29)
at
org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:228)
at
org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:116)
at java.lang.Thread.run(Thread.java:595)
|
|
|
| Re: ClassCastException in FillLayout.flushCache() [message #104826 is a reply to message #104816] |
Sun, 14 September 2008 12:49  |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
Hi Felix,
this is most likely a bug in your code. Unless of course you
encounter the Exception while you are running the ControlsDemo or
WorkbenchDemo that comes with RAP.
This will happen if you pass a GridData instance to setlayoutData()
on a Widget that is in a FillLayout. The exception does not occur
immediately, but just when the Widgets are (re-)layouted. Thus you
unfortunately loose the stack-trace to the actual source of the problem.
For example:
Shell shell = new Shell( display );
shell.setlayout( new FillLayout() );
Button button = new Button( shell, SWT.PUSH );
button.setLayoutData( new GridData() ); // BAD!!!
Cheers,
Rüdiger
Felix LJ Mayer wrote:
> In RAP 1.1.1, calls to Display.sleep() alwasy seem to end up in a
> ClassCastException. It seems that FillLayout.flushCache() assumes it has
> FillData, but actually it has GridData. Should I open a bug for this?
>
> Sep 12, 2008 2:38:32 PM org.eclipse.rwt.internal.lifecycle.RWTLifeCycle
> afterPhaseExecution
> SEVERE: Could not execute PhaseListener after phase 'PROCESS_ACTION'.
> java.lang.ClassCastException: org.eclipse.swt.layout.GridData
> at org.eclipse.swt.layout.FillLayout.flushCache(FillLayout.java :180)
> at org.eclipse.swt.widgets.Composite.changed(Composite.java:495 )
> at
> org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er$1.doVisit(TextSizeDeterminationHandler.java:81)
> at
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:32)
> at
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:46)
> at
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
> at
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
> at
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
> at
> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
> at
> org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er.afterPhase(TextSizeDeterminationHandler.java:128)
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.afterPhaseEx ecution(RWTLifeCycle.java:390)
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:191)
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:297)
> at org.eclipse.swt.widgets.Display.sleep(Display.java:703)
> at
> org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(Wo rkbenchAdvisor.java:361)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2389)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2347)
> at org.eclipse.ui.internal.Workbench.access$5(Workbench.java:22 00)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:425)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:408)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:157)
> at com.lggi.esp.rcp.EntryPoint.createUI(EntryPoint.java:29)
> at
> org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:228)
> at
> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:116)
> at java.lang.Thread.run(Thread.java:595)
>
>
|
|
|
|
| Re: ClassCastException in FillLayout.flushCache() [message #105139 is a reply to message #105100] |
Tue, 16 September 2008 14:22 |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
Hi Felix,
I am prety sure about this, as the layout code was copied without
modification from SWT.
As you mentioned, the reason why you don't see the exception in SWT
is because flushCache() isn't executed. RAP in contrary causes
flushCache() to be called when a Shell is opened.
If you force flushCache() in SWT, you will probably see the
exception. Calling layout(Control[]) with Composite#getChildren() as
its argument on every Composite (and derived classes) will do.
HTH
Rüdiger
Felix LJ Mayer wrote:
> Hi Rüdiger,
>
> Are you sure about this? The same application runs fine when deployed on SWT
> instead of RAP. I also checked and we create FillLayout in just 2 places,
> both of which do not get executed in this case. I debugged both versions and
> found that in the SWT deployment, FillLayout.flushCache() does not get
> executed at all. In the RAP deployment, a Composite with FillLayout calls
> its flushCache() method with a Composite that has a GridLayout and
> corresponding GridData; the former Composite is created by Eclipse, the
> latter by us. The code doing this looks the same in SWT and RAP, but somehow
> SWT avoids using the wrong layout data.
>
> Felix
>
> " Herrmann" <rherrmann@innoopract.com> wrote in message
> news:gaj18n$ce9$1@build.eclipse.org...
>> Hi Felix,
>>
>> this is most likely a bug in your code. Unless of course you encounter the
>> Exception while you are running the ControlsDemo or WorkbenchDemo that
>> comes with RAP.
>>
>> This will happen if you pass a GridData instance to setlayoutData() on a
>> Widget that is in a FillLayout. The exception does not occur immediately,
>> but just when the Widgets are (re-)layouted. Thus you unfortunately loose
>> the stack-trace to the actual source of the problem.
>>
>> For example:
>> Shell shell = new Shell( display );
>> shell.setlayout( new FillLayout() );
>> Button button = new Button( shell, SWT.PUSH );
>> button.setLayoutData( new GridData() ); // BAD!!!
>>
>> Cheers,
>> Rüdiger
>>
>> Felix LJ Mayer wrote:
>>> In RAP 1.1.1, calls to Display.sleep() alwasy seem to end up in a
>>> ClassCastException. It seems that FillLayout.flushCache() assumes it has
>>> FillData, but actually it has GridData. Should I open a bug for this?
>>>
>>> Sep 12, 2008 2:38:32 PM org.eclipse.rwt.internal.lifecycle.RWTLifeCycle
>>> afterPhaseExecution
>>> SEVERE: Could not execute PhaseListener after phase 'PROCESS_ACTION'.
>>> java.lang.ClassCastException: org.eclipse.swt.layout.GridData
>>> at org.eclipse.swt.layout.FillLayout.flushCache(FillLayout.java :180)
>>> at org.eclipse.swt.widgets.Composite.changed(Composite.java:495 )
>>> at
>>> org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er$1.doVisit(TextSizeDeterminationHandler.java:81)
>>> at
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:32)
>>> at
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:46)
>>> at
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>> at
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>> at
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>> at
>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>> at
>>> org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er.afterPhase(TextSizeDeterminationHandler.java:128)
>>> at
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.afterPhaseEx ecution(RWTLifeCycle.java:390)
>>> at
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:191)
>>> at
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:297)
>>> at org.eclipse.swt.widgets.Display.sleep(Display.java:703)
>>> at
>>> org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(Wo rkbenchAdvisor.java:361)
>>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2389)
>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2347)
>>> at org.eclipse.ui.internal.Workbench.access$5(Workbench.java:22 00)
>>> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:425)
>>> at
>>> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>>> at
>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:408)
>>> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:157)
>>> at com.lggi.esp.rcp.EntryPoint.createUI(EntryPoint.java:29)
>>> at
>>> org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
>>> at
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:228)
>>> at
>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:116)
>>> at java.lang.Thread.run(Thread.java:595)
>>>
>
|
|
|
|
| Re: ClassCastException in FillLayout.flushCache() [message #105473 is a reply to message #105454] |
Wed, 17 September 2008 14:19 |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
Felix,
your conclusion is right.
For a more thorough understanding of SWT/RWT layouts, see also:
http://www.eclipse.org/articles/article.php?file=Article-Und erstanding-Layouts/index.html
Here is a list of docs and articles about SWT in general, but you
may also find information on layouts:
http://www.eclipse.org/swt/docs.php
HTH
Rüdiger
Felix LJ Mayer wrote:
> Okay, then I have one more question just to clarify: The layout data of a
> particular layout comes from the children of the widget which has the
> layout?
>
> "Rüdiger Herrmann" <rherrmann@innoopract.com> wrote in message
> news:gaofg2$qcq$1@build.eclipse.org...
>> Hi Felix,
>>
>> I am prety sure about this, as the layout code was copied without
>> modification from SWT.
>> As you mentioned, the reason why you don't see the exception in SWT is
>> because flushCache() isn't executed. RAP in contrary causes flushCache()
>> to be called when a Shell is opened.
>> If you force flushCache() in SWT, you will probably see the exception.
>> Calling layout(Control[]) with Composite#getChildren() as its argument on
>> every Composite (and derived classes) will do.
>>
>> HTH
>> Rüdiger
>>
>> Felix LJ Mayer wrote:
>>> Hi Rüdiger,
>>>
>>> Are you sure about this? The same application runs fine when deployed on
>>> SWT instead of RAP. I also checked and we create FillLayout in just 2
>>> places, both of which do not get executed in this case. I debugged both
>>> versions and found that in the SWT deployment, FillLayout.flushCache()
>>> does not get executed at all. In the RAP deployment, a Composite with
>>> FillLayout calls its flushCache() method with a Composite that has a
>>> GridLayout and corresponding GridData; the former Composite is created by
>>> Eclipse, the latter by us. The code doing this looks the same in SWT and
>>> RAP, but somehow SWT avoids using the wrong layout data.
>>>
>>> Felix
>>>
>>> " Herrmann" <rherrmann@innoopract.com> wrote in message
>>> news:gaj18n$ce9$1@build.eclipse.org...
>>>> Hi Felix,
>>>>
>>>> this is most likely a bug in your code. Unless of course you encounter
>>>> the Exception while you are running the ControlsDemo or WorkbenchDemo
>>>> that comes with RAP.
>>>>
>>>> This will happen if you pass a GridData instance to setlayoutData() on a
>>>> Widget that is in a FillLayout. The exception does not occur
>>>> immediately, but just when the Widgets are (re-)layouted. Thus you
>>>> unfortunately loose the stack-trace to the actual source of the problem.
>>>>
>>>> For example:
>>>> Shell shell = new Shell( display );
>>>> shell.setlayout( new FillLayout() );
>>>> Button button = new Button( shell, SWT.PUSH );
>>>> button.setLayoutData( new GridData() ); // BAD!!!
>>>>
>>>> Cheers,
>>>> Rüdiger
>>>>
>>>> Felix LJ Mayer wrote:
>>>>> In RAP 1.1.1, calls to Display.sleep() alwasy seem to end up in a
>>>>> ClassCastException. It seems that FillLayout.flushCache() assumes it
>>>>> has FillData, but actually it has GridData. Should I open a bug for
>>>>> this?
>>>>>
>>>>> Sep 12, 2008 2:38:32 PM org.eclipse.rwt.internal.lifecycle.RWTLifeCycle
>>>>> afterPhaseExecution
>>>>> SEVERE: Could not execute PhaseListener after phase 'PROCESS_ACTION'.
>>>>> java.lang.ClassCastException: org.eclipse.swt.layout.GridData
>>>>> at org.eclipse.swt.layout.FillLayout.flushCache(FillLayout.java :180)
>>>>> at org.eclipse.swt.widgets.Composite.changed(Composite.java:495 )
>>>>> at
>>>>> org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er$1.doVisit(TextSizeDeterminationHandler.java:81)
>>>>> at
>>>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor$AllWidget TreeVisitor.visit(WidgetTreeVisitor.java:32)
>>>>> at
>>>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:46)
>>>>> at
>>>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>>> at
>>>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>>> at
>>>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>>> at
>>>>> org.eclipse.swt.internal.widgets.WidgetTreeVisitor.accept(Wi dgetTreeVisitor.java:51)
>>>>> at
>>>>> org.eclipse.swt.internal.graphics.TextSizeDeterminationHandl er.afterPhase(TextSizeDeterminationHandler.java:128)
>>>>> at
>>>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.afterPhaseEx ecution(RWTLifeCycle.java:390)
>>>>> at
>>>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.continueLife Cycle(RWTLifeCycle.java:191)
>>>>> at
>>>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.sleep(RWTLif eCycle.java:297)
>>>>> at org.eclipse.swt.widgets.Display.sleep(Display.java:703)
>>>>> at
>>>>> org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(Wo rkbenchAdvisor.java:361)
>>>>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2389)
>>>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2347)
>>>>> at org.eclipse.ui.internal.Workbench.access$5(Workbench.java:22 00)
>>>>> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:425)
>>>>> at
>>>>> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>>>>> at
>>>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:408)
>>>>> at
>>>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:157)
>>>>> at com.lggi.esp.rcp.EntryPoint.createUI(EntryPoint.java:29)
>>>>> at
>>>>> org.eclipse.rwt.internal.lifecycle.EntryPointManager.createU I(EntryPointManager.java:92)
>>>>> at
>>>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWT LifeCycle.java:228)
>>>>> at
>>>>> org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadCont roller.run(RWTLifeCycle.java:116)
>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03550 seconds
] 
Search
Help
Register
Login
Home
