Bugzilla – Full Text Bug Listing
| Summary: | Pressed & disabled toolbar button looks enabled | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tetsuro Asahata <asahata> |
| Component: | SWT | Assignee: | Grant Gayed <grant_gayed> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bso, jeff_brown, kitlo, lmcwil, n.a.edgar |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| Whiteboard: | |||
|
Description
Tetsuro Asahata
Tod pls try this case in the latest 2.0 builds. Still an issue in 20020501. The next and previous problem buttons gray out but not the Text Hover. This is a known problem in SWT or Windows. Couldn't find corresponding SWT PR. This is platform behavior. Many applications (example, Word) have worked around this by implementing their own toolbar widgets, but the native widget does not support it. *** Bug 4619 has been marked as a duplicate of this bug. *** *** Bug 4850 has been marked as a duplicate of this bug. *** *** Bug 8303 has been marked as a duplicate of this bug. *** Also occurs in Eclipse 3.0M7 (Build ID: 200402122000) on HP-UX 11.11 and Solaris 9 platforms. Not sure how it could do this because this is a Windows only limitation. Is the problem you are seeing something to do with the Eclipse icons? I think Eclipse had a work around for this. Did the work around go away? Occurs in Eclipse 3.0M8 (Build ID: 200403261517) on HP-UX 11.11 and Solaris 9 platforms with [SWT Examples] SWT Controls->Toolbar. Occurs in Eclipse 3.0M9 (Build ID: 200405211200) on AIX 5.30 with [SWT Examples] SWT Controls->Toolbar Interesting that they claim this happens on AIX. Is it a color depth issue with the code that grays tool bar items? Fixed > 20050405 (on Windows) Please open a new bug report for AIX and/or HP-UX if this is not fixed for you. As a side note, I've verified that this works in a stand-alone snipet on linux-
motif and solaris-motif (snippet is below).
However, note that the originally-described behaviour still occurs when using
eclipse because the CHECK ToolItem is having its selection changed by jface
whenever it changes enablement (by ActionContributionItem.update(String)). So
this is happening as a result of a ui-level design, not an swt bug.
public static void main(String[] args) {
Display display = new Display();
Image image = new Image(display, "/opt/smiley.ico");
Shell shell = new Shell(display);
shell.setBounds(10,10,200,200);
ToolBar bar = new ToolBar(shell, SWT.FLAT | SWT.BORDER);
bar.setBounds(10,10,150,50);
final ToolItem item = new ToolItem(bar, SWT.CHECK);
item.setImage(image);
item.setSelection(true);
item.setEnabled(false);
final ToolItem item2 = new ToolItem(bar, SWT.CHECK);
item2.setImage(image);
item2.setEnabled(false);
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
image.dispose();
display.dispose();
}
I've filed bug 90852 to check out the logic in ActionContributionItem. From comment 14: > the originally-described behaviour still occurs when using eclipse because > the CHECK ToolItem is having its selection changed by jface whenever it > changes enablement (by ActionContributionItem.update(String)) Please see comments in bug 90852. ActionContributionItem.update only changes the item's selection and enablement state when necessary. Even if it did change it unnecessarily, I would not expect changing the selection to have any impact on how the icon appears. There should be no ordering constraint here. The icon should be grayed out if the item is disabled, even if the selection state changes while disabled. It appears to work this way now on Win2K in N20050505. Revisiting the case, I misspoke about the behaviour I saw. It's not that the item's image keeps its colour when it's disabled (which was what was described in comment 0), but that disabling it in eclipse makes it lose its selected status. This is the selection change I was referring to that originates in ActionContributionItem. However I believe that this is being done by design for aestetic purposes, so there's no action required here. Sorry for the misleading comment in comment 14. Just to be clear, which action did you see having its selected state changed when disabled? If it's a retargetable action, the item will be unselected if the new part has no handling action. This is done to reflect the actual state from the part, not for aesthetics. Toggle Mark Occurrences and Show Source Of Selected Element Only These are both retargetable, so having the selection change is expected. |