Bugzilla – Full Text Bug Listing
| Summary: | [Dialogs] NPE in CTabFolderLayout | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Schindl <tom.schindl> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | gheorghe, remy.suen, susan |
| Version: | 3.6.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | stalebug | ||
|
Description
Thomas Schindl
Bogdan, is this maybe a regression introduced through the new CTabFolder-Rendering? On a second thought I think the Dialog code is wrong because it tries to compute a new layout while we are disposing the widgets I agree with your conclusion. ;) As suggested by Bogdan I'm moving this to UI. We should probably check if we are bringing the dialog down before acutally doing a relayout. Tom, do you see this frequently and do you have a way to consistently reproduce? All of my naive test cases (close the dialog and then set the message) will fail much earlier than the layout, because disposed message labels will be touched. If only the CTabFolder is destroyed, there is no failure. So I think it's a specific timing/disposal problem that may well depend on the individual dialog. I could check for disposal of the work area and not do the layout, but I'm reticent to apply a band-aid when I can't force it to happen in a test. See also bug 333684 which may be related. I can see several places where a band-aid could be applied. (Such as bailing out of TitleAreaDialog#layoutForNewMessage when the dialog area is disposed). The problem here is reproducing the sequence that causes the problem. I don't know if the band-aid will work (depending on where we are in the dispose sequence, etc.) Looking at the stack, it seems as if the client dialog is setting an error message in the middle of its dispose handling. com.bizerba.retail.control.ui.views.emf.store.dialogs.DeviceDialog.updateDialogState(DeviceDialog.java:164) I agree that we could handle this better, but I'll need a snippet that shows the problem in an SDK dialog. (In reply to comment #6) > See also bug 333684 which may be related. This is similar, but not the same. In that one, it appears that the bounds are being set in the middle of handling a close event, so a layout on a partially disposed widget tree is occurring. I'll comment in that bug. Tom, do you know whose dialog that is? This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |