Hi,
I am aware of g.FirstPage and g.LastPage to identify whether or not a page range has been selected.
However, how do I tell whether or not print “All” is selected rather than a range?
With print “All” selected if I check g.firstPage it returned 1 and when I checked g.lastPage it returned 2147483647, clearly something wrong here.
Mac, OS X 10.9.3
All the best
Terry
No, that’s right. That big number is the max value for an integer.
Remember… you app has no idea how many pages there are or will be until you do something that calculates that…
So for “ALL” it will return the maximum possible range…
Thanks for your reply.
Cocoa uses a constant kPMPrintAllPages = -1 with which you set the page range.
Would it not be better to use a -1 to indicate that "All’’ has been selected and to document it.
Here’s Apples take on it.
All the best
Terry
Well, you don’t know what Xojo uses internally. But it may be simply Carbon Print Manager…
Well, a little disappointed if you are correct because I thought Xojo was Cocoa now?
Is it not?
Well, answering my own question and not paying much attention to the dialogue box NOT containing a print preview it would seem to be Carbon.
When will Xojo BE Cocoa?
All the best
Terry
I suppose this is a little primitive:
if g.LastPage = 2147483647 then
tFirstPage = 1
tLastPage = pNumOfPages ' my page calc
else
tFirstPage = g.FirstPage
tLastPage = g.LastPage
end if
I could make my own constant but it should really be part of Xojo.
All the best
Terry
It is Cocoa 
Cocoa uses Carbon Print Manager, too.
But there are different APIs to talk to it.
[quote=94251:@Christian Schmitz]It is Cocoa
Cocoa uses Carbon Print Manager, too.
But there are different APIs to talk to it.[/quote]
Really. So how do 64 bit Cocoa Apps. print then?
I actually believe that Carbon and Cocoa both use Apple’s “Core Printing”.
[quote]Core Printing is a C API that Mac apps and command line tools can use to perform printing tasks that dont display a user interface. Core Printing defines a set of opaque types and a rich set of operations on instances of these types. The Core Printing opaque types include:
PMPrintSession for general information about a print job
PMPrintSettings for print job parameters
PMPageFormat for the page format of a printed document
PMPaper for information about a type of paper
PMPrinter for information about a printer
In Carbon applications, Core Printing is used together with Carbon Printing to implement printing features. For more information about Carbon Printing, see Carbon Printing Reference.
In Cocoa applications, Core Printing can be used to extend the functionality in the Cocoa printing classes. The NSPrintInfo class provides direct access to some Core Printing objects.
Note: Core Printing is available to 64-bit applications, except for functions, data types, and constants that have been deprecated.
[/quote]
The dialogue boxes etc are provided by Carbon and by Cocoa which is why they look different but the core (forgive the pun) is actually provided to each system.
So, I suppose the question is to shorten the debate.
Why is Xojo using the Carbon API’s to get at “Printing” and NOT using the Cocoa API’s to get at “Printing”?
This is clearly the case as the printer Dialogue Box IS Carbon and NOT Cocoa.
All the best
Terry
Why care? Until they go to 64bit there is time to get it moved to Cocoa…
Out of interest here are screenshots of Carbon & Cocoa dialogue boxes.
Carbon:
Cocoa:
All the best
Terry
I was only asking why a Cocoa Xojo was still a Carbon Xojo?
All the best
Terry
Ah, that dialog is due to the second version is based on a view which can draw itself into the dialog.
But with Xojo printing, you don’t provide a view, but get back a graphics object.
Or in other words: The graphics is not available at the time of the dialog.
PS: You can get the desired behavior via MBS Plugin, I think.
I do not think so.
-1 have a special meaning in the ListBox control. Using it elsewhere with a different meaning will be confusing.
[quote=94265:@Christian Schmitz]Ah, that dialog is due to the second version is based on a view which can draw itself into the dialog.
But with Xojo printing, you don’t provide a view, but get back a graphics object.
Or in other words: The graphics is not available at the time of the dialog.
PS: You can get the desired behavior via MBS Plugin, I think.[/quote]
It seems with Cocoa it’s all done through NSPrintManager whose methods seem to rely on passing in an NSView.
I wonder how Xojo will overcome this?
If you are interested in plugins I could probably make an example for that.
I don’t know what all the hoopla is about…
from a technical point of view … it IS using -1
anyone that knows Binary Mathematics knows that 2147483647 is the 1’s complement of -1
So, 2147483647 = -1
yup