Community
Participate
Working Groups
It would be very comfortable to be able to print the contents of widgets like a list, a table, ... in an easy way. Nice features: - possibility to zoom the widget to one page - possibility to decide what should happen if the content fills more than one page 1. should it be printed in z-order (from left to right, then top to bottom) or 2. should it be printed from top to bottom, then left to right Thank you very much! Peter
Feature request Steve to investigate and advise
There is some support for native widgets on Windows and Motif but very little. For example, it may not be possible to zoom etc. For Custom Widgets, we would need to get them to paint to a printer GC. It could be a lot of work in an area that is very platform specific meaning we need to be extremely careful with the API. Low priority. We could do this for 3.0.
The Visual Editor for Java in WSxx 5.0 family has a Swing/AWT editor that uses the Swing Component.printAll(Graphics g) to screen scrape the image of a component (and sub coponents) from a target (rendering) VM, and paint the image inside the IDE. The lack of this faciliity in SWT inhibits the Visual Editor's implimantation support of SWT components. Is it possible to get a printAll like support for 2.1.
Grant, can you link up the other "widget printing" PR's to this PR and investigate and advise? Can the Visual Editor be changed to use live components for SWT?
There are many reasons for the Visual Editor to not run live components inside the IDE, but rather to use a target VM. The most important ones: Target VM can be spawn on various JDK levels, locales etc. Target VM can be recycled with ease (class shape changes etc.) Target VM may be running remotely (e.g., pervasive device) From an design point of view, allowing live components in the Visual Editor is a major architectural change which does not meet its long term goals.
For cross reference - this is basically the same PR as 24362
The reasons the Visual Editor doesn't use live widgets are 1 - The live widgets want to act as live widgets, buttons want to be pressed and text controls want to grab the cursor and accept text input. You need some way of faking them out so they draw themselves but don't act as live widgets. VAJava did this for AWT because it actually had its own component peer layer but in SWT I don't know how this could be achieved 2 - if you use live widgets these need to be parented by the editor part control's itself making it hard to do composition of a shell without emulating its title bar and decorations ( which is what VAJava did and leads to all the problems the emulation does ) 3 - There are times when you need to draw over the widgets such as drawing selection or resize handles. This can be done with a paintEvent callback but I think ( from a newsgroup post of Veronika ) that the paint order is OS dependent and on Mac for example the native paints on top of any drawing done on the GC of the paint event 4 - If you run the SWT controls in the same VM as the IDE then you are bound to the same code base. For the Visual Editor we let the user drop any control that's in their build path, including having a JRE that's different to the Eclipse detected one. Likewise for SWT the user might create their own extended SWT control and want to include this in a class. The extended SWT control could be in the same project, another one in the build path, or anywhere that the JDT can see it and they'd expect to be able to drop it and use it and see it drawn. This could be possibly done with funky class loaders but it'd be messy, and with the Visual Editor if the user is using a class that they are changing at the same time ( to get iterative design / test / fix feedback ) then we know when the class changes shape and we can drop the target VM and just re-create the new instance. This is also what VAJava did with the concept of execution contexts where each VCE used a fresh EC that had its own classpath and set of classes. Having the SWT controls running inside the IDE also causes problems because things such as statics will be shared and also if any of the controls gets into trouble it can bring the IDE to its knees - the same reasons why it's not a good idea to debug code you're writing in the editor you're writing with. 5 - By using GEF as a lightweight framework to just render the image of the SWT controls we also benefit from being able to do cartoon layouts where the user doesn't just get a boring Visual Basic looking WYSIWYG design view. WYSIWYG works great for some situations, but good editors put annotations and other detail on the composition surface to separate the design time from the runtime experience. A good example of this would be a composite in SWT Grid or Form layout where you might want to put spaces and grid lines and connectors between the controls in design mode ( something that's very hard to do with live controls as the size and position is determined by the live layout manager ) I think that right now we can create a GC over a control and grab its image. This would work for a while for us, except I'm not sure what happens about child controls ( I think they are not included in the image so we would need to recurse the children which isn't so bad ) but if the control is clipped or obscured by another window what happens to it ? I think that if the control is clipped or obscured by another window then we can't get its image just from the GC.
*** Bug 29292 has been marked as a duplicate of this bug. ***
Can I assume that this support will be available in 3.0 as Steve noted above?
Gili, SWT is the widget toolkit for Eclipse. Our work is driven by the Eclipse plan. If "printing the contents of widgets" is unimportant to Eclipse, then we have a hard time justifying spending time working on it. Right now, it's not on the Eclipse 3.0 plan.
*** Bug 24362 has been marked as a duplicate of this bug. ***
I'm not sure it's possible to get a screen shot of a widget on all platforms. Therefore, we can't really offer the API because we can't implement it. I haven't looked in a while so the situation may have changed. Somebody needs to comb the API for GTK, Motif, Mac and Photon to see that it can be done. I know it works on Windows. Just paste in the names of the API calls in this PR. Thanks.
rejected for 3.0
Joe, please attach your code to this problem report if there are no IP issues. 1) It seems that you should be calling Widget.notifyListeners() instead of doing all that crazy reflection. 2) I have released an implementation of WM_PRINTCLIENT for Windows that can print custom widgets. You will still need platform specific code to send the WM_PRINT message. I have tested it briefly with StyledText, Shell and Table (it seems to draw the header properly). What this means is that on Windows, we are supporting the WM_PRINTCLIENT message. Native code or code that uses com.ibm.swt.internal.win32 to send this message should be able to print the contents of controls. There is still no general solution for all platforms.
Created attachment 6687 [details] Code to print the contents of a widget (WINDOWS ONLY)
Actually, it occurs to me that you no longer need to send a fake SWT.Paint event. This should now automatically be handled by WM_PRINTCLIENT.
Steve - thanks very much for the code. Where is the implementation of WM_PRINTCLIENT you mention ? Do I need an updated SWT build, and what's the internal code I need to call to get it sent ? Also, in the snippit you posted that uses WM_PRINT the z-order of overlapping controls also seems to be reversed, so if you have overlapping controls the image is of them in their reverse z-order. Best regards and many thanks - JRW
1) You need the latest SWT. 2) The snippet uses internal methods to send WM_PRINT. You have your choice of using the internal methods to call WM_PRINT the same way I did (bad) or writing your own C DLL that sends WM_PRINT (slightly better, but a pain). The advantage of the C DLL is that you won't be broken by changes to the internal classes. 3) I have no idea about the z-order problem. The only test code I wrote is in this problem report. If you provide a test case, I could look at it but you are in the unsupported territory of Windows only code.
Steve - I've got the build SWT-I20031111-win32. The method on Control for print client is empty LRESULT WM_PRINTCLIENT (int wParam, int lParam) { return null; } I'd have expected this to have code in it to create the GC and callback the paint listeners, similar to WM_PAINT.
Did you actually try the code I attached? The Control.WM_PRINTCLIENT() returns null to indicate that the default window proc for the control should run. Composite.WM_PRINTCLIENT() should have the code you expected.
My bad - I had the build path set up using an older SWT version. The Composite code works a treat. Many thanks for your help Steve - JRW
*** Bug 82087 has been marked as a duplicate of this bug. ***
*** Bug 88329 has been marked as a duplicate of this bug. ***
Is anything happening on this one ? It's been almost 3 years since it was initially reported. If not, do anybody know of 3rd party tools for eclipse that makes printing easier ? Regards Kim
Nothing much. Comment #12 is as true today as to was 3 years ago. Sorry about that. If you have some code you'd like to contribute, we'd love to see it. Other than that, you can use the Windows only patch that is in this bug report.
Just an update that there is an ongoing effort to capture SWT widgets on MAC OSX Carbon implementation in bug 47716. Almost all widgets except Text are captured, and the problem with SWT Text seems to be that it is not painting to the buffer passed in, for which bug 108635 has been opened.
*** Bug 146538 has been marked as a duplicate of this bug. ***
Fixed > 20080227 See Control.print(GC)
