Community
Participate
Working Groups
Build Identifier: SWT N20100120 When printing a component, there are various side effects. This is a follow up on the discussions from bug 299714. Other related bugs are bug 223590, bug 223800, bug 267466, bug 267468 and maybe bug 225091. 1. Windows XP (tested on 32 bit computer JDK6u18) - Painting artifacts when a window is dragged over the control. - The control is reparented at the wrong location if the window is moving. - These can be fixed with this "improved method": Rectangle bounds = control.getBounds(); control.print(gc); control.setLocation(bounds.x, bounds.y); control.redraw(0, 0, bounds.width, bounds.height, true); control.update(); -> But I think the containers in the control hierarchy can occasionaly get painting artifacts too which are not cleared by this approach. Still, it is way better. - The NativeSwing hack works fine but incurs a performance penalty. 2. Windows 7 (tested on 64 bit computer with 32-bit JDK6u18 and 32-bit JDK6u11, and on 32 bit computer JDK6u11) - When print happens, the window is brought to front. There is some sort of focus stealing/restoring. This is a big issue because you cannot work with other windows when a component is being printed. - The NativeSwing hack has the same focus issue. If fixPrintWindow is forced to false in Control.printWidget(int, int, GC), then the hack works fine (but with that aforementioned performance penalty). -> It seems that activating the NativeSwing hack in addition to the SWT fix (fixPrintWindow not forced to false) can result in the unusable state (bug 299714) so they have to be exclusive. We need a way out, even a temporary solution. Could there be an undocumented system property that would force fixPrintWindow to false? That way, we could activate the hack of our choice depending on the OS and configuration without having to alter the SWT sources. This would greatly help while waiting for a fix. Reproducible: Always Steps to Reproduce: 1. Control.print(gc)
Created attachment 157324 [details] An all in one test case This test case is an SWT_AWT test case. It has 2 variables at the top to select what to test. First, "testType" can show the result on screen or to an image on disk: This allows to ensure that there are no missing bits due to clipping. It can also perform a stress test by frequently printing, which allows to notice all potential clipping issues, painting artifacts or bad control relocation. Second, PrintMode allows to switch beteen the SWT implementation, the NativeSwing hack and 2 slightly improved versions of the SWT version.
Hi, I am having the same bug when I am using DJNativeSwing to capture a screenshot of a webpage (http://djproject.sourceforge.net/ns/). Really serious problem for me as the window blinks every time I call the function.
Hi, I attempted to work out what is causing this bug that I experience. The problem is that the frame of the window (if it is not maximized) looses focus and then re-gains focus in a very short amount of time when I attempt to print the component to a image. This is a unacceptable user experience for my customer. So I looked into the Control.java within SWT jar and did some debugging, I found the following. In Control.java the method void printWidget (int /*long*/ hwnd, int /*long*/ hdc, GC gc) { Inside printWidget, this call actually de-focuses my applications window. OS.SetParent (hwnd, 0); Also if you commented out the first OS.SetParent then this one also de-focuses the application window. Anyway, print does not work without the first one, so both de-focus the window. if ((bits1 & OS.WS_VISIBLE) == 0) { OS.ShowWindow (hwnd, OS.SW_SHOW); } Removal of the above code means the windows title and frame does not flash (flicker). The one returns the focus to the main window, there-by completing the flashing of the frame of this window. if ((bits1 & OS.WS_VISIBLE) == 0) { OS.ShowWindow (hwnd, OS.SW_HIDE); } Setting fixPrintWindow to false doesn't help as then the printing to graphics does not work. I am on Windows Visa service pack 2. I need a workaround or a patch urgently, I found the lines which cause the problem, so hopefully someone can continue to investigate this.
Is there some sort of combination of SetWindowPos, SetActiveWindow, SetForegroundWindow ... that can fix it?
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
