Community
Participate
Working Groups
Build Identifier: SWT N20100110 After printing a control, it is completely unusable. Our product relies on this feature and our users start to use Windows 7. We had to deactivate some of our features but we have to find a solution as soon as possible (unhappy users, etc.) Reproducible: Always Steps to Reproduce: 1. Have a control displayed on win 7. 2. control.print(gc) 3. try to use that control.
Created attachment 156179 [details] Test case that prints a control Launch the test case. A window appears partially showing a browser and a button. After a second a screenshot appears in a new window which you can close. Then try to use the browser or the button.
Looking at the SWT code, this seems to be related to the fixPrintWindow flag in Control.printWidget(int, int, GC)
Just tested on Vista and it happens there as well. WinXP seems to work fine however.
Interesting, the problem is the last call to WM_SETREDRAW, for some reason it does not turn redraw back on. I verifed that removing all calls to WM_SETREDRAW fixes the problem, but it also causes the controls to flash each time print() is called.
This is the code patterns that causes the problem to happen: OS.DefWindowProc (hwnd, OS.WM_SETREDRAW, 0, 0); OS.SetParent (hwnd, getShell().handle); OS.DefWindowProc (hwnd, OS.WM_SETREDRAW, 1, 0); System.out.println("print"); OS.DefWindowProc (hwnd, OS.WM_SETREDRAW, 0, 0); OS.SetParent (hwnd, hwndParent); OS.DefWindowProc (hwnd, OS.WM_SETREDRAW, 1, 0); The fix is to remove WS_CHILD and add WS_POPUP to the GWL_STYLE bits before reparenting the window to the desktop.
Created attachment 156565 [details] patch
Fixed in HEAD > 20100119
I verified that testcase works on win7, vista, and winxp sp3. Please verify the results with your product.
I tested with my product on windows7, vista, and XP-sp2. I get a flash every time print() is called on all platforms. On XP-sp2 I get a flash in the upper left hand corner of the monitor as well. I applied the patch to swt-3.6m3. I can try again with a nightly build once one becomes available. I was also able to duplicate using a small example which I'll attach. I tested the small example with window7 and XP-sp2 and get the exact same results as within my app.
Created attachment 156589 [details] example showing component flash
reopening due to component flashing
(In reply to comment #11) > reopening due to component flashing Philip, can you please try the code -without- the patch on XP ? I'm fairly sure the flashing is a old problem (i.e. the flashing was not introduced by the patch).
I don't see any flashing on I20100115-1100 without the patch on XP SP2. But maybe I'm not looking for the right thing(s)?
(In reply to comment #13) > I don't see any flashing on I20100115-1100 without the patch on XP SP2. But > maybe I'm not looking for the right thing(s)? But do you see flashing running HEAD (note, I only released the fix yesterday afternoon, so the fix is not in for this week I-build, you need HEAD or the latest N-build) ?
(In reply to comment #14) > But do you see flashing running HEAD (note, I only released the fix yesterday > afternoon, so the fix is not in for this week I-build, you need HEAD or the > latest N-build) ? Okay, I think misunderstood you, Felipe. Phillip said he tried the patch + 3.6M3 and it flashed. And then you asked him to try it without the patch so I assumed 0115 was okay (it doesn't have the patch). I just tried with eclipse-SDK-N20100119-2000-win32.zip and I can _confirm_ it is flashing on XP SP2.
I just tried the example again on WinXP-sp2 with a clean swt-3.6m3 (w/o the patch) and it does not flash.
I also made a swt source project from HEAD. Reverted the patch in my project and the flashing does _not_ occur.
(In reply to comment #17) > I also made a swt source project from HEAD. Reverted the patch in my project > and the flashing does _not_ occur. Yes, I can see the problem, we are already working on a fix.
Created attachment 156719 [details] patch 2
Fixed in HEAD > 20100120 Please try again, it worked fine for me on xp, vista, seven.
I'm getting different issues on win-xp-sp2 and vista/win7 in our product. And was able to duplicate to some degree with extra print() calls in the 2nd test case example. I'll attach that example. - On vista/win7 the flash still happens in my product a lot. In the test app it only happens from time to time. Maybe every 5 to 10 to 20 calls to print(). I modified the 2nd test example to call print() several times each second and that demonstrates the flash pretty well. - On winxp-sp2 there is no flashing that I can see. But there a strange issue where the component doesn't repaint properly. To see this issue use the newly attached example and slowly drag another window over the browser section of the example app. Notice that the google buttons do not paint properly.
Created attachment 156840 [details] PrintComponentSWT3.java example Example showing flashing on vista/win7 with extra print() statements. As well as repaint problem on winxp-sp2
(In reply to comment #21) > - On vista/win7 the flash still happens in my product a lot. I see flashing only on the browser and only when the browser is partially visible and the application calls print() a whole lot. > - On winxp-sp2 there is no flashing that I can see. On windows xp the code running is exactly the same we had before we started fixing this problem, so whatever problem you see now you saw then. I would think this very low priority right now, how bad is the flashing affecting your product ?
(In reply to comment #23) > I see flashing only on the browser and only when the browser is partially > visible and the application calls print() a whole lot. We use the DJNativeSwing package to embed an SWT web browser in JInternalFrames (MDI) in our Swing app. In order to achieve z-order properly with the Native browser DJNativeSwing uses windows clipping/shaping. That will cause a lot of partially displayed browsers (it's the nature of our app really). Our app has a thumbnail bar at the top showing a thumbnail of all opened JInternalFrames. That thumbnail is generated with a print() that can be called for all sorts of end user events (data changing, browser reloading, scrolling, etc..). We also update a "back buffer" or image of the browser to a panel behind the swt component so that any overlapping window with transparency (i.e. a shadow around the border, etc...) will seem to show it blended with the swt browser. This "back buffer" can be updated for various user events as well: usually just when the internal frame holding the browser is deactivated (i.e. no longer the selected JinternalFrame). It's not uncommon in our app to have 2+ browsers open and overlapping eachother. Just toggling between the JInternalFrames will cause _a lot_ of flashing due to updating the back buffer and thumbnail. > On windows xp the code running is exactly the same we had before we started > fixing this problem, so whatever problem you see now you saw then. I'll have to test that I guess, I was not seeing this issue before. In our product is was very apparent once I got the latest nightly build. I had never seen it before then. I was however using 3.5 so perhaps it's a difference between 3.5 and 3.6m3. > I would think this very low priority right now, how bad is the flashing > affecting your product ? Our app uses a lot of partially displayed browsers and can make many calls to the print() method. That makes this a very high priority for us.
Hi all, (In reply to comment #24) > > On windows xp the code running is exactly the same we had before we started > > fixing this problem, so whatever problem you see now you saw then. > > I'll have to test that I guess, I was not seeing this issue before. A bit of history: - SWT had an issue with printing with a clip (cf bug #223590), so I implemented an "insane" work around as detailed in that bug (comment 4). - Eventually, SWT took a similar approach at the native level to fix the issue. - After a few iterations and bug fixes, I removed my hack to rely fully on SWT. I think Phillip was using a version of Native Swing which was old enough to have my hack. Because of the Seven issue (this very bug) he upgraded to a more recent version of Native Swing that could work with more recent SWT versions. He now hits the repainting bug. I tried his test case against 3.6M3 and 3.5M7 and they both have the issue. If I am correct, then a new version of Native Swing with the hack back and a version of SWT with the Seven fix should work. The downside with this hack is performance. My hack takes some time, which can reach half a second for large windows. Phillip's app may not tolerate such a delay for each and every print(gc). In any case, the original issue of this bug is fixed but clearly there is some bug fixing to be done. Should we move the findings and test cases over to bug #223590 or re-open another bug?
(In reply to comment #25) > If I am correct, then a new version of Native Swing with the hack back and a > version of SWT with the Seven fix should work. Can someone try that ? > In any case, the original issue of this bug is fixed but clearly there is some > bug fixing to be done. Should we move the findings and test cases over to bug > #223590 or re-open another bug? I think this bug is fixed, someone should open a new bug about the flashing problem (as this one is only getting confusing).
(In reply to comment #26) > (In reply to comment #25) > > If I am correct, then a new version of Native Swing with the hack back and a > > version of SWT with the Seven fix should work. > > Can someone try that ? I tried that and it does not work. Using DJNativeSwing with it's hack and the seven fix causes the browser to go blank and not come back. The browser is still there and responding to input it just does not paint at all. > I think this bug is fixed, someone should open a new bug about the flashing > problem (as this one is only getting confusing). Yes, I think the control locking up is fixed. I can write up a new issue about the painting on xp and flashing on vista and win7.
I just opened bug 300894 which is a follow up on the issues mentioned in this bug. The original issue of this bug being fixed, I think you can close this bug.
closing
