Community
Participate
Working Groups
Created attachment 133971 [details] Snippet to reproduce issue It is possible to get an NPE from StatusLineManager:188. public void setCanceled(boolean value) { //Don't bother updating for disposed status if (statusLine.isDisposed()) { // <--- 188 return; } progressDelegate.setCanceled(value); } The problem is that the dispose() method sets statusLine to null: public void dispose() { if (statusLineExist()) { statusLine.dispose(); } statusLine = null; ... } The attached snippet contains code to reproduce. Reproducible on 3.5M6. Originally reported here: http://dev.eclipse.org/mhonarc/lists/riena-dev/msg00573.html
The question is, what disposed the SLM and still allowed the window#run(*) to be called? PW
Please attach a stack trace (either mod the code or add a conditional breakpoint) of what is calling the SLM.dispose() PW
Hi Todd, i'm not sure how to reproduce this inside a typical Riena application. The Riena SWT ExampleApplication does not invoke StatusLineManager.dispose() or reference this class. Could you provide a few more details how to reproduce this? Thanks, Elias.
I faced the same problem when developping an RCP application when I don't want to use a status line (ie I do not call getWindowConfigurer().createStatusLineControl(shell) in my WorkbenchWindowAdvisor). Then, in such case, statusline == null, and then I get this NPE. Adding the test for null would be about 3 seconds, can we hope to get this fixed soon in JFace?
(In reply to comment #4) > I faced the same problem when developping an RCP application when I don't want > to use a status line (ie I do not call > getWindowConfigurer().createStatusLineControl(shell) in my > WorkbenchWindowAdvisor). > > Then, in such case, statusline == null, and then I get this NPE. > Adding the test for null would be about 3 seconds, can we hope to get this > fixed soon in JFace? Is it just the result of calling run(boolean, boolean, IRunnableWithProgress)? Could you attach a stack trace? If you are interested in attaching a patch yourself, please see below: http://wiki.eclipse.org/Platform_UI/How_to_Contribute
Created attachment 147549 [details] Screenshot of the issue which display a stacktrace This is the result of a GMF-based editor when getWindowConfigurer().createStatusLineControl(shell) is *not* called in WorkbenchWindowAdvisor.createWindowContents().
Created attachment 147552 [details] Proposed patch
> Is it just the result of calling run(boolean, boolean, IRunnableWithProgress)? > Could you attach a stack trace? You can see the stacktrace in its context in the attached screenshot > If you are interested in attaching a patch yourself, please see below: > http://wiki.eclipse.org/Platform_UI/How_to_Contribute Please find as attachement a proposed patch. It solves the issue in my context of a GMF editor without status line.
Thanx for the patch, I'll get it into 3.6. It should use " if (statusLineExist()) {" just to be consistent with the rest of the class. PW
I've tried to reproduce this but haven't had any luck. It is not clear to me why the StatusLineManager is disposed in the first place. If it was never created then this wouldn't happen. Mickael, can you set breakpoints in StatusLineManager's dispose() method and see where it's getting called from?
Released to HEAD >20091013 PW
This doesn't look like it will solve anything: public void setCanceled(boolean value) { //Don't bother updating for disposed status if (statusLineExist()) { return; } progressDelegate.setCanceled(value); } I bungled the conditional. PW
Released for I20091028-1300 PW
In I20091028-1300 PW
Thanks, that's about 30 pixels more for the model editor area!
*** Bug 296151 has been marked as a duplicate of this bug. ***
