Community
Participate
Working Groups
The editor and the console (styled text) do not change their colors when I change the colour outside (i.e. window screen properties). This is ugly because all other (i.e. the native) widgets immediately use the new color. It works when I restart Eclipse. I would expect that all colors change immediately or all colors stay until I restart Eclipse. NOTES: KH (9/14/2001 11:51:41 AM) Moving to SWT for comment. SN (9/18/01 5:28:13 PM) The problem is in the StyledText constructor. It uses NO_BACKGROUND so it shouldn't set the background color. LK (9/19/01 11:26:19 AM) Actually I don't think this has anything to do with NO_BACKGROUND or StyledText. If I run the test case below using a Canvas and change the system background color, the canvas bg color does not change. Shouldn't it? Also, StyledText is explicitly setting the bg color to be white (vs. the default gray that we get for some reason). If you explicitly set the color, changing the system settings will not work (which is correct behavior). So to support this we would need Canvas to work properly and to initialize its background color to the system window background color (which by default is white). import org.eclipse.swt.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.widgets.*; public class Test { Shell shell; Canvas canvas; Font boldFont; Font normalFont; public void create() { shell = new Shell(); Display display = shell.getDisplay(); canvas = new Canvas(shell, SWT.BORDER); shell.setLayout(new FillLayout()); shell.open(); shell.setSize(300, 200); } public static void main(String[] args) { Test test = new Test(); test.create(); test.run(); } public void run() { Display display = shell.getDisplay (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } } }
*** Bug 4824 has been marked as a duplicate of this bug. ***
We need to respond to changes in system colors. This is a requirement for accessibility. McQ.
PRODUCT VERSION: 0.131
In order to get the StyledText to have the same behavior as the native text wrt. changing system colors you need to have your own background color field and never set the background color in SWT. You need to do the same thing with the foreground color. I quickly hacked StyledText to do this and the approach seems to work. Here are my hacks (I leave the real implementation to the owner): public StyledText(Composite parent, int style) { // use NO_BACKGROUND style when implemented by SWT. // always need to draw background in drawLine when using NO_BACKGROUND! super(parent, checkStyle(style | SWT.NO_REDRAW_RESIZE | SWT.NO_BACKGROUND)); Display display = getDisplay(); String codePage = System.getProperty("file.encoding").toUpperCase(); boolean isWindows = System.getProperty("os.name").startsWith("Windows"); // Running on Windows and with Hebrew or Arabic codepage? isBidi = isWindows && ("CP1255".equals(codePage) || "CP1256".equals (codePage)); if ((style & SWT.READ_ONLY) != 0) { setEditable(false); } clipboard = new Clipboard(display); calculateLineHeight(); calculateTabWidth(); installDefaultContent(); setForeground(display.getSystemColor(SWT.COLOR_LIST_FOREGROUND)); // setBackground(display.getSystemColor(SWT.COLOR_LIST_BACKGROUND)); initializeFonts(); contentWidth = new ContentWidthCache(this, content.getLineCount()); if (isBidi() == false) { Caret caret = new Caret(this, SWT.NULL); caret.setSize(1, caret.getSize().y); } else { createCaretBitmaps(); createBidiCaret(); Runnable runnable = new Runnable() { public void run() { // setBidiCaretLocation calculates caret location like during // cursor movement and takes keyboard language into account. // Fixes 1GKPYMK setBidiCaretLocation(null); } }; StyledTextBidi.addLanguageListener(this, runnable); } // set the caret width, the height of the caret will default to the line height calculateScrollBars(); createKeyBindings(); ibeamCursor = new Cursor(display, SWT.CURSOR_IBEAM); setCursor(ibeamCursor); installListeners(); installDefaultLineStyler(); } Color background = null; public void setBackground (Color color) { background = color; redraw (); } public Color getBackground () { if (background == null) { return getDisplay().getSystemColor(SWT.COLOR_LIST_BACKGROUND); } return background; }
Can we get this fixed? A lot of Eclipse users are coming across this problem when they try to change the background color of the text editor. Like LK writes, Canvas does not take on the new window background color if you change it in the Windows control panel.
I have comment on this and included sample code for StyledText to use. What more would you like me to do?
Okay, we can do what is suggested, but shouldn't Canvas honor the system color settings if no color has been specified?
It does. You are setting the background color in StyledText. Part of my work around was to comment this out in your code. Am I missing something? If not, can I mark this fixed?
Sorry Steve, I didn't see your code. I think Lynne is talking about the case where someone uses a plain Canvas without any tricks or subclassing. In this case the background color is gray and not the system window background color and it will never pick up changes to the system window color. The question is should we need to put in the workaround vs. should SWT do this? I believe both Lynne and I think SWT should handle this.
Released workaround. Leaving bug report open until we determine whether this is the right thing to do or whether Canvas should handle this.
I just ran the exmaple code provided by LK. When I changed the Appearance to be 'Plum (High Color)', the canvas background changed. I can't see the bug. I'm running 98. Does it fail on NT? So, the way it is working is that as long as you don't set the background color, you get the system default. In the case of StyledText, the system default for a Canvas was not the same as the default for a Text widget so StyledText had to implement special code to handle this. I agree that we need API to be notified when a system color has changed. That way, programs that cache system colors instead of querying them ever time could work. Alternately, as long as the color is queried every time (and this is not slow), SWT need not implement the "notified system color changing" code and clients like StyledText need not implement code that listens for color changes ... everybody wins ... less is more.
You have to change the '3D Objects' color. Windows applications generally don't use the 'Window' color as the background color of a window.
So we're talking about two different background colors. The Canvas is using the background color of the message box and not of the window. We expected the Canvas to use the "Window" background color. Since the Window background color is applied to all native widgets in Eclipse you would expect the same behavior for emulated widgets. Changing the "3D Objects" color is not an option. It affects every surface (except for "Window" surfaces) and makes the UI look ugly. This behavior is weird since a Canvas would normally be used as the client area of an app or widget and not as a message box. Why is Canvas using the "Message Box" color and not the "Window" color? Is this something that you could change in SWT? I tried wordpad (doesn't really count, it's just the RichText widget), Word and J++ and they all use the Window background color.
While not strictly correct to use COLOR_3DFACE instead of COLOR_WINDOW, there is precident in the MSDN for this. Believe me, changing it back you cause the universe to howl. Try it and see what Eclipse looks like! So, the original bug is fixed. If you want to enter a DCR wrt. COLOR_3DFACE vs. COLOR_WINDOW, go ahead. We need to track this separate issue somewhere. I'm marking this fixed. You can unmark it if you disagree.
