Community
Participate
Working Groups
When setting an items font to bold using the new TreeItem.setFont() then the width of the item isn't adjusted properly. See the attached screen shot. This is how the bold font is computed that it then passed to the TreeItem.setFont(). Font defaultFont = JFaceResources.getDefaultFont(); FontData[] data = defaultFont.getFontData(); for (int i = 0; i < data.length; i++) { data[i].setStyle(SWT.BOLD); } categoryFont = new Font(display, data);
Created attachment 9206 [details] screenshot with clipped items
CAR, this is important because Eclipse is not using this feature as much as they would becuase of this bug. I couldn't get the ControlExample to fail. Please hack up a simple case and we'll debug it. Thanks. Erich, do you have a clue as to why is would be failing some place in Eclipse and not in others?
Hmmm... if I set the text for "Node 1" to be "a much longer string", then it fails in the ControlExample exactly the way Erich describes. ControlExample seems to be allowing extra room for some reason. Anyhow, here's a simple guy that shows the failure: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.events.*; import org.eclipse.swt.graphics.*; public class TreeItemFontTest { static Display display; static Shell shell; static Tree tree; static TreeItem treeItem0; static Button check; static Font normalFont, boldFont; public static void main(String[] args) { display = new Display(); shell = new Shell(display); shell.setLayout(new GridLayout()); shell.setText("Tree"); tree = new Tree(shell, SWT.BORDER); for (int i = 0; i < 5; i++) { TreeItem treeItem = new TreeItem(tree, SWT.NONE); treeItem.setText("item" + i); for (int j = 0; j < 3; j++) { new TreeItem(treeItem, SWT.NONE).setText ("item" + i + j); } if (i == 0) { treeItem0 = treeItem; normalFont = treeItem0.getFont(); FontData fd = normalFont.getFontData()[0]; boldFont = new Font(display, fd.getName(), fd.getHeight(), SWT.BOLD); } } check = new Button(shell, SWT.CHECK); check.setText("item0 Bold"); check.setSelection(false); check.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { treeItem0.setFont(check.getSelection() ? boldFont : normalFont); } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
Not sure if it's related, but if you set the item font to have a larger point size (go up several points) then the text is clipped vertically also. Same for Table. (Table doesn't have the horizontal clipping problem because you just re- pack the column and it figures out the new size).
Fixed > 20040415 (Thanks Windows!)
Thanks CAR.
cool - thanks!
Steve, any idea what happened here? There seems to be a regression - the snippet in comment 3 fails again. See bug 63735, opened yesterday. Here's what we changed on 04/15: We added _setText and called it from setText and setFont. The comment is: * Bug in Windows. When the font is changed for an item, * the bounds for the item are not updated, causing the text * to be clipped. The fix is to re-set the text, causing * Windows to compute the new bounds using the new font.
Oddly, the snippet in comment 3 works fine for me here at home. WinXP, COMCTL32_MAJOR=6, COMCTL32_MINOR=0, buildNum=2800, platID=2 The modified ControlExample (see top of comment 3) works fine, too. Also, the following modified snippet (does not use a layout) works at home. There is some unknown difference between my work machine and my home machine... import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.events.*; import org.eclipse.swt.graphics.*; public class TreeItemFontTest { static Display display; static Shell shell; static Tree tree; static TreeItem treeItem0, treeItem00; static Button check; static Font normalFont, boldFont; public static void main(String[] args) { display = new Display(); shell = new Shell(display); //shell.setLayout(new GridLayout()); //shell.setLayout(new FillLayout()); shell.setText("Tree"); tree = new Tree(shell, SWT.BORDER); //tree.setLayoutData(new GridData(GridData.FILL_HORIZONTAL)); tree.setSize(200, 200); for (int i = 0; i < 5; i++) { TreeItem treeItem = new TreeItem(tree, SWT.NONE); treeItem.setText("item" + i); for (int j = 0; j < 3; j++) { TreeItem item = new TreeItem(treeItem, SWT.NONE); item.setText("item" + i + j); if (i == 0 && j == 0) { treeItem00 = item; normalFont = treeItem00.getFont(); FontData fd = normalFont.getFontData() [0]; boldFont = new Font(display, fd.getName (), fd.getHeight(), SWT.BOLD); } } if (i == 0) { treeItem0 = treeItem; // normalFont = treeItem0.getFont(); // FontData fd = normalFont.getFontData()[0]; // boldFont = new Font(display, fd.getName(), fd.getHeight(), SWT.BOLD); } //if (i == 2) treeItem.setText("item2111"); } check = new Button(shell, SWT.CHECK); check.setBounds(10, 200, 100, 24); check.setText("item0 and item00 Bold"); check.setSelection(false); check.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { treeItem0.setFont(check.getSelection() ? boldFont : normalFont); treeItem00.setFont(check.getSelection() ? boldFont : normalFont); } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
*** Bug 63735 has been marked as a duplicate of this bug. ***
I am starting to get the feeling that it may depend on the fonts one has loaded on one's machine, and perhaps different fonts may be used for TreeItems on different machines?? Martin, do you actually set the "normal" font on your tree or tree items, or do you just use the swt default? I added a System.out.println(fd); to the snippet, and my home machine prints: 1|Tahoma|8|0|WINDOWS|1|-11|0|0|0|400|0|0|0|1|0|0|0|0|Tahoma I will check what my work machine prints for this snippet tomorrow.
Same font at work. Maybe this stopped working because I changed screen resolution?
It's not screen resolution, and Win2K fails also. However, I am running a different version of comctl32.dll at work: COMCTL32_MAJOR=5, COMCTL32_MINOR=82, buildNum=2800, platID=2 I DO have javaw.exe.manifest installed in my jre/bin, so I don't know why it's not being picked up when I run this snippet. I've checked all possible eclipse preferences and selected JRE's and etc. Anyhow, bottom line is that that's the difference. If it's running the 6.0 version of the common controls dll then our original workaround works. Otherwise, it doesn't. We can work with this and provide an additional workaround if the dll version is less than 6.0. There may be an eclipse bug in here somewhere, but I'm not sure where. Stand by for the swt fix.
Fixed > 20040526. It was ok for versions of the common controls dll >= 6.0, but now it works for 5.xx versions of the dll as well.
*** Bug 64480 has been marked as a duplicate of this bug. ***
Car, is there a workaround for this bug for those using M9? Is it an ordering problem? If the text is set again after setting the font, does that work?
Yes, an easy workaround if you are on Windows XP. (No for Win2K). You need to make sure that you are running version 6.0 of the comctl32.dll. To do this on XP, you have to take the file javaw.exe.manifest and put it in the same directory as you launch eclipse from. Typically, this is your jdk/jre/bin but it might be your jdk/bin, so copy the manifest into both places to be safe. javaw.exe.manifest is in eclipse\plugins\org.eclipse.swt.win32_3.0.0\os\win32 \x86 Here's the SWT FAQ for it is more info is required: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt- home/faq.html#xpthemes Note that if you use java.exe to launch eclipse instead of javaw.exe, you need to rename the manifest file accordingly.
