Bug 25554 - DCR - PrintDialog - way to disable print selection option
Summary: DCR - PrintDialog - way to disable print selection option
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Felipe Heidrich CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 25901 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-10-30 14:34 EST by Lynne Kues CLA
Modified: 2019-09-06 16:16 EDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lynne Kues CLA 2002-10-30 14:34:42 EST
In the PrintDialog, "print selection" is an option.  Currently StyledText does 
not handle this.  We would therefore like to disable this option (until we do 
actually support it).

Is it possible for us to do this?
Comment 1 Steve Northover CLA 2002-10-31 14:24:48 EST
Felipe to investigate and advise
Comment 2 Felipe Heidrich CLA 2002-10-31 15:59:41 EST
PRINTDLG Structure, in the flag member you can set:
  PD_NOSELECTION
  Disables the Selection radio button.

I've test it and it works, I just need to talk to SN in order to know how this 
can be added to our API.

Note:
#define PD_NOSELECTION                 0x00000004
Comment 3 Felipe Heidrich CLA 2002-11-05 14:34:13 EST
Since it's a temporally situation it's not really need to add a new API I guess.
This could be handle from UI code using pop-up a message box or similar.

anyway, if you want I can talk to SN again..
Comment 4 Lynne Kues CLA 2002-11-05 15:12:37 EST
It may be a permanent solution in our case - who knows if we will ever get 
around to supporting printing of the selection.  

Please talk to SN again.  The item should be customizable.  Other users of 
PrintDialog may not want to support the print selection option either.  I can't 
imagine that this is a big deal to add support for...
Comment 5 Felipe Heidrich CLA 2002-11-07 16:31:32 EST
Steve, this is the PR about PrintDialog we have talked.

We don't need to add any new styles, we can reuse the ALL_PAGES, PAGE_RANGE, 
and SELECTION.

We just need to add a new method to allow the application specify with ones are 
enabled. PrinterDialog already has API to enabled/disable the option print to 
file.


Comment 6 Christophe Cornu CLA 2002-11-12 09:02:33 EST
*** Bug 25901 has been marked as a duplicate of this bug. ***
Comment 7 Lynne Kues CLA 2002-11-26 15:54:33 EST
Put in fix on our end - we no longer need to access the field on the dialog.
Comment 8 Felipe Heidrich CLA 2004-06-28 14:24:59 EDT
Car, we should either fix this problem or mark this problem as wontfix.
Do you think this feature is interesting to have ?
Comment 9 Carolyn MacLeod CLA 2004-06-28 15:31:25 EDT
Find out what print dialog does on the Mac.
Also, look at CDE - it has a print dialog we might use someday, who knows.
Also, check bug 24796, and figure out what dialog they use.

If it is possible to disable the "print selection" option on at least 2 
platforms, then perhaps we should add it. The best place to add it is to use a 
style bit on the PrintDialog class.

If, however, it makes no sense on any other platform, then I think this bug 
should just be closed.
Comment 10 Brannon CLA 2006-08-16 17:50:28 EDT
I think this bug needs to get resurrected now that we have GTK printing.

First, the "selection" support. The GTK doesn't even support printing a "selection", at least that's what I derive from five minutes in their documentation. (Correct me if I'm wrong, please!) I think that should be off by default on Windows as well; if you print a view, you won't have a selection, and that seems to be getting more common.

I'd like an option to shut off the collation opion and the page range option as well. Both of those are supported on GTK. That gives headway for this bug; we now have two platforms that support it!
Comment 11 Brannon CLA 2006-08-16 18:20:39 EDT
After looking at the Win32 PrintDialog.class source code, I think we should at least chop the open function into seveal subfunctions. The open() function should call a createPrintDlgData(lots of different params) function with default parameters and then call the open(printDlgData) function. That way the user could make their own print dialog settings object if needed or they could extend the class and not have to modify such a large (though simple) function as "open()".

BTW, the documentation for PrintDialog does not specify which styles are appropriate. As far as I can tell it is just SWT.APPLICATION_MODAL and SWT.SYSTEM_MODAL. And those both do the same thing. (What they do is not documented either, but I can make a good guess from their name.) I say that here because I had been considering using the style to disable "selection", page ranges, or collation.
Comment 12 Felipe Heidrich CLA 2006-08-17 11:11:30 EDT
We also have print support on the Mac.
Comment 13 Brannon CLA 2006-08-17 11:13:57 EDT
I don't use Macs. We need somebody who does to point us to the API in use so that we can determine a cross-platform subset of functionality that would be useful.
Comment 14 Carolyn MacLeod CLA 2006-08-17 14:56:58 EDT
comment 10:
>GTK doesn't even support printing a "selection"...

- correct, but they are considering adding it. See http://bugzilla.gnome.org/show_bug.cgi?id=344519

comment 11:
>BTW, the documentation for PrintDialog does not specify which styles...

- PrintDialog inherits APPLICATION_MODAL, PRIMARY_MODAL, and SYSTEM_MODAL from superclass Dialog, and they are documented in Dialog. Note that these styles are hints, meaning they do not necessarily all apply on all platforms. PrintDialog does not currently contribute any style bits of its own.

> ...they could extend the class...

- The SWT Dialog classes are not intended to be subclassed - see the comment at the top of the class.
Comment 15 Praveen CLA 2010-01-13 06:37:55 EST
It seems Windows and GTK supports disabling/enabling Selection option. Cocoa currently doesn't have any API to do this.
Comment 16 Carolyn MacLeod CLA 2010-01-13 14:36:18 EST
Re comment 15:
"Cocoa currently doesn't have any API to do this."

Please check into NSPrintPanelShowsPrintSelection in the NSPrintPanel options.
Does it do what we want here? I am not certain from reading the doc, but I think it does. Please try setting/clearing this bit in the panel.options() and see what happens.

Re comment 5:
"PrinterDialog already has API to enabled/disable the option print to file."

No, actually, it doesn't. The PrintDialog.setPrintToFile(boolean printToFile) method specifies whether to check or uncheck the Print To File checkbox when the dialog is opened. It doesn't control whether to hide or show the checkbox. Currently, the checkbox always shows. On win32, the option to hide the checkbox is PD_HIDEPRINTTOFILE.

Re comment 5:
"We just need to add a new method to allow the application specify with ones are enabled."

I don't think a new method is best here - I think this type of "create-only" thing is better suited to style bits. (Silenio, please comment). We can add some "NO_xxx" style bits to PrintDialog that allow hiding parts of the dialog. All of the printing-related style bits are currently defined in PrinterData, so perhaps that is the place to define them (rather than in SWT.java). Make sure the values do not conflict with any of the styles that PrintDialog inherits.

There are 2 style bits that we could provide first:
1) NO_SELECTION sets the PD_NOSELECTION bit on win32, gtk_print_unix_dialog_set_support_selection on GTK, and possibly NSPrintPanelShowsPrintSelection on Cocoa, should look into Carbon.

2) NO_PAGE_RANGE sets PD_NOPAGENUMS on win32. I can't see how to hide this on GTK... is there a way? Can possibly use NSPrintPanelShowsPageRange on Cocoa. Should look into Carbon.

Please make sure that the defaults are the way the dialogs look today.
Comment 17 Carolyn MacLeod CLA 2010-01-13 15:00:07 EST
Note that I have opened bug 299550 to make "print selection" available on GTK.
Comment 18 Eclipse Webmaster CLA 2019-09-06 16:16:18 EDT
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.

If you have further information on the current state of the bug, please add it. 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.