sarrel@osu-eddie.UUCP (06/05/87)
I am writing a short program that will, as part of its function, print out a standard form. However, the form is 'sideways' on the page. I have the form in a window, but now I want to print it out. I figured the best way to print something sideways is to change the default orientation switch in the Page Setup dialog. What's the best way to do this? Can I just save a copy of the dialog resource (with the switch set the way I want) in the application's resource fork? Is it that easy, or am I hallucinating? I'm not _that_ expierienced a MacProgrammer, so have some mercy with your answers. advTHANKSance
han@apple.UUCP (06/05/87)
In article <3654@osu-eddie.UUCP>, sarrel@osu-eddie.UUCP (Scoop) writes: > I am writing a short program that will, as part of its function, print out > a standard form. However, the form is 'sideways' on the page. I have the > form in a window, but now I want to print it out. I figured the best way > to print something sideways is to change the default orientation switch in > the Page Setup dialog. > > What's the best way to do this? Can I just save a copy of the dialog resource > (with the switch set the way I want) in the application's resource fork? Is > it that easy, or am I hallucinating? I'm not _that_ expierienced a > MacProgrammer, so have some mercy with your answers. > > advTHANKSance The easiest way is to store the print record. In your program you probably have hPrint = THPrint(NewHandle(SIZEOF(TPrint))); if PrValidate(hPrint) then begin end; After calling PrStlDialog(hPrint) to get the proper defaults, you will then probably want to write it out to the resource fork of the application. Note that self-modifying applications (changing your own resource fork) is not really smiled upon - makes your program not completely Appleshare compatible (i.e. you cannot be a shared application ready for multiple launches). So to write it out to the resource fork, make sure that the top resource file is the application (or document) file, and then call AddResource(Handle(hPrint), 'XXXX', theID, 'Resource Name'); where theID is an integer, and XXXX is the resource type. Note that there are many pre-defined resource types which you will want to stay away from. And all lower-case resource types are reserved by Apple. Thereafter, when you launch your program, it should check to see if your custom print record resource is there, if not, it should go through the creation of a fresh print record, validation, etc... Otherwise, read it the resource via hPrint = THPrint(GetResource('XXXX', theID)) and you should be on your way. Hope this helps. ===================================================================== Byron Han | UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han Apple Computer, Inc. | CSNET: han@apple.csnet 20525 Mariani Ave, | ATTNet: 408-973-6450 Cupertino, CA 95014 | GENIE: BYRONHAN MS 27Y | CSERVE: 72167,1664 ===================================================================== All opinions and statements do not necessarily represent those of my employer, Apple Computer Inc. =====================================================================
dplatt@teknowledge-vaxc.UUCP (06/06/87)
This is in reference to Byron Han's reply to Scoop's query about storing the print record in the application's resource fork. It seems to me that another way to handle this might be to store the appropriate print record in the resource fork of the documents being formatted, rather than in the resource fork of the application. This might be safer (the application wouldn't need to be self-modifying). This trick could be combined with the "style sheet" concept that I seem to recall floating by in a technote a couple of months ago. Different style-sheet documents could be created; each one would have an empty data fork and a single "XXXX" (or whatever) resource in the resource fork, containing the appropriate print record. The "New..." dialog would probably want to pop up an SFGetFile to select the appropriate style sheet. Does this make any sense at all in your situation, Scoop?
jww@sdcsvax.UUCP (06/06/87)
PrintRecords are normally stored in a resource of type 'PREC' when
they're not stored in the data fork. You should use an id > 10
(probably > 127, to follow the rules to the letter) to avoid
conflicting with the 'PREC' resources used by the printer drivers.
--
Joel West
{ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel if I ever fix news)
jww@sdcsvax.ucsd.edu if you musthan@apple.UUCP (06/07/87)
In article <3279@sdcsvax.UCSD.EDU>, jww@sdcsvax.UCSD.EDU (Joel West) writes: > PrintRecords are normally stored in a resource of type 'PREC' when > they're not stored in the data fork. You should use an id > 10 > (probably > 127, to follow the rules to the letter) to avoid > conflicting with the 'PREC' resources used by the printer drivers. > -- > Joel West > {ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel if I ever fix news) > jww@sdcsvax.ucsd.edu if you must You do not want to use the PREC resource type. This resource is for internal Apple use in conjunction with the Print Manager. If you intend to store your print record, use a custom resource. By using the PREC resource type for storing your own information, you run the risk of breaking on future software updates. Granted using an ID >=128 should be okay but it is not a good idea to use a reserved resource type. PREC's of different ID's mean different things to the print manager. And they in general are not used to store print records. PREC ID=03 is usually used for determining page size layout information for the Imagewriter printers. Different printers, such as the Laserwriter, Daisywriter, and other future printers, use other PREC's for other purposes. ===================================================================== Byron Han | UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han Apple Computer, Inc. | CSNET: han@apple.csnet 20525 Mariani Ave, | ATTNet: 408-973-6450 Cupertino, CA 95014 | GENIE: BYRONHAN MS 27Y | CSERVE: 72167,1664 ===================================================================== All opinions and statements do not necessarily represent those of my employer, Apple Computer Inc. =====================================================================
jww@sdcsvax.UUCP (06/07/87)
MacPaint, MacDraw and MacWrite store the print record in the first
512 bytes of the data fork.
MORE stores it in a 'PREC' resource; MacTerminal uses a 'Prec' resource.
Resource id's > 127 are available to applications, so I would guess it
to be safe. However, although Inside Macintosh recommends storing
print records in a resource fork, it doesn't say in what resource.
I think it would be a good idea for Tech Support to register (and
publish) a recommended resource type, to assure consistency among
all developers.
--
Joel West
{ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel if I ever fix news)
jww@sdcsvax.ucsd.edu if you mustsarrel@osu-eddie.UUCP (06/07/87)
In article <13458@teknowledge-vaxc.ARPA> dplatt@teknowledge-vaxc.ARPA (Dave Platt) writes: >It seems to me that another way to handle this might be to store the >appropriate print record in the resource fork of the documents being >formatted, rather than in the resource fork of the application. This >might be safer (the application wouldn't need to be self-modifying). Storing the print record in the document file may take up some more disk space, but I'd trade that to keep my application from being self-modifying. Sounds like a good idea for me. >This trick could be combined with the "style sheet" concept that I >seem to recall floating by in a technote a couple of months ago. >Different style-sheet documents could be created; each one would have >an empty data fork and a single "XXXX" (or whatever) resource in the >resource fork, containing the appropriate print record. The "New..." >dialog would probably want to pop up an SFGetFile to select the >appropriate style sheet. I don't really need all that power. I need only one "style-sheet". Although, a reference to the tech-note in question might be enlightening. Thanks a lot,
stew@endor.UUCP (06/08/87)
In article <933@apple.UUCP> han@apple.UUCP (Byron Han) writes: >In article <3654@osu-eddie.UUCP>, sarrel@osu-eddie.UUCP (Scoop) writes: >> I am writing a short program that will, as part of its function, print out >> a standard form. However, the form is 'sideways' on the page. I have the >> form in a window, but now I want to print it out. I figured the best way >> to print something sideways is to change the default orientation switch in >> the Page Setup dialog. >> >> What's the best way to do this? Can I just save a copy of the dialog resource >> (with the switch set the way I want) in the application's resource fork? Is >> it that easy, or am I hallucinating? I'm not _that_ expierienced a >> MacProgrammer, so have some mercy with your answers. >> >> advTHANKSance > >The easiest way is to store the print record. In your program you probably >have > hPrint = THPrint(NewHandle(SIZEOF(TPrint))); > if PrValidate(hPrint) then begin > end; [remainder of this probably irrelevant reply deleted] You folks are missing the point, I think. Read Scoop's message again. He is asking the same question thousands of Macintosh developers have asked before, "How do I change or override the Standard Print Dialogs?" In this case, he wants the dialog to default to landscape mode. The right way to do this would be a SetRotn opcode to the new PrGeneral procedure. Unfortunately, Apple forgot to implement this. I hope it was only a correctable oversight. Apple's response has always been, "Don't do this. Let the user select the desired options from the standard dialogs." Quoting from TN 122: Summary To be compatible with future printer-like devices, it is essential that your application print in a device-independant manner. Avoid testing undocumented fields, setting fields in the print record directly and bypassing the existing print dialogs. Use the Printing Manager dialogs, PrintDefault and PrValidate to set up the print record for you. There is great virtue in consistency; I am certainly a big fan of the consistent Macintosh user interface and regard the User Interface Guidelines as gospel. However, the lack of a programmatic interface to the print manager is a longstanding deficiency. In recent TechNotes, Apple has sactioned methods to add to Print Dialogs (TN 95) and added some further print manager functions (TN 128). One of the added functions is the GetRotn opcode to PrGeneral, which will let you test whether the user has selected Landscape mode, after the fact. So the best you can do, if you want to be compatible with future printer drivers, is put up a window saying, "Please select Landscape Mode" along with the standard Style Dialog, and then issue an error or warning message if Landscape mode has not been selected. In my opinion, this looks like a real kludge to the end user; it's confusing and it's unnecessarily time consuming. The PrGeneral call is a step in the right direction, but it's not complete. Please add a SetRotn opCode to the next release of PrGeneral. Stew Rubenstein Cambridge Scientific Computing, Inc. UUCPnet: seismo!harvard!rubenstein Internet: rubenstein@harvard.harvard.edu CompuServe: 76525,421 MCIMail: CSC Stew Rubenstein Cambridge Scientific Computing, Inc. UUCPnet: seismo!harvard!rubenstein Internet: rubenstein@harvard.harvard.edu CompuServe: 76525,421 MCIMail: CSC
han@apple.UUCP (06/08/87)
In article <2234@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes: > In article <933@apple.UUCP> han@apple.UUCP (Byron Han) writes: > >In article <3654@osu-eddie.UUCP>, sarrel@osu-eddie.UUCP (Scoop) writes: > >> I am writing a short program that will, as part of its function, print out > >> a standard form. However, the form is 'sideways' on the page. I have the > >> form in a window, but now I want to print it out. I figured the best way > >> to print something sideways is to change the default orientation switch in > >> the Page Setup dialog. > >> > >> What's the best way to do this? Can I just save a copy of the dialog resource > >> (with the switch set the way I want) in the application's resource fork? Is > >> it that easy, or am I hallucinating? I'm not _that_ expierienced a > >> MacProgrammer, so have some mercy with your answers. > >> > >> advTHANKSance > > > >The easiest way is to store the print record. In your program you probably > >have > > hPrint = THPrint(NewHandle(SIZEOF(TPrint))); > > if PrValidate(hPrint) then begin > > end; > > [remainder of this probably irrelevant reply deleted] > > You folks are missing the point, I think. Read Scoop's message again. > He is asking the same question thousands of Macintosh developers have > asked before, "How do I change or override the Standard Print Dialogs?" > In this case, he wants the dialog to default to landscape mode. > > The right way to do this would be a SetRotn opcode to the new > PrGeneral procedure. Unfortunately, Apple forgot to implement > this. I hope it was only a correctable oversight. > > Apple's response has always been, "Don't do this. Let the user select > the desired options from the standard dialogs." Quoting from TN 122: > > Summary > > To be compatible with future printer-like devices, it is essential > that your application print in a device-independant manner. Avoid > testing undocumented fields, setting fields in the print record > directly and bypassing the existing print dialogs. Use the Printing > Manager dialogs, PrintDefault and PrValidate to set up the print > record for you. > > There is great virtue in consistency; I am certainly a big fan of the > consistent Macintosh user interface and regard the User Interface > Guidelines as gospel. However, the lack of a programmatic interface > to the print manager is a longstanding deficiency. In recent > TechNotes, Apple has sactioned methods to add to Print Dialogs (TN 95) > and added some further print manager functions (TN 128). One of the > added functions is the GetRotn opcode to PrGeneral, which will let you > test whether the user has selected Landscape mode, after the fact. So > the best you can do, if you want to be compatible with future printer > drivers, is put up a window saying, "Please select Landscape Mode" > along with the standard Style Dialog, and then issue an error or > warning message if Landscape mode has not been selected. > > In my opinion, this looks like a real kludge to the end user; it's > confusing and it's unnecessarily time consuming. The PrGeneral call > is a step in the right direction, but it's not complete. Please add a > SetRotn opCode to the next release of PrGeneral. > > Stew Rubenstein > Cambridge Scientific Computing, Inc. > UUCPnet: seismo!harvard!rubenstein > Internet: rubenstein@harvard.harvard.edu > CompuServe: 76525,421 > MCIMail: CSC > Stew Rubenstein > Cambridge Scientific Computing, Inc. > UUCPnet: seismo!harvard!rubenstein > Internet: rubenstein@harvard.harvard.edu > CompuServe: 76525,421 > MCIMail: CSC The result of my reply was indeed relevant. If you had bothered to read it, you would have realized it was. By following the techniques I described, you then will have a print dialog which would default to whatever the programmer wants. One allocates a default print record, validates it, and then via the standard Style dialog (Page Setup) sets the attributes desired. This is then written out to the document's resource fork as a user defined resource. Upon launch of the application, the application checks the document for a print record under the user defined resource type and then uses it. The print record read in contains the defaults desired - which not only include orientation, but page size, special effects such as tall adjusted, reduction, or gaps between pages. Thereby, when the user brings up Page Setup, the proper defaults are already selected. It would be a simple matter to write a small program which creates a default print record with the Apple defaults, uses the PrStlDialog routine to set the defaults desired, and then writes out a custom resource to a target file. This would work independent of any printer driver and works with many different attributes. In my opinion, this is a close to Apple kosher as one can get. We go through standard dialogs for printing for a reason. It is to provide a common interface. I dislike Microsoft Word 3.0 for this very reason. It is non standard. I have written printing code where it was desirable to bypass the PrJobDialog on each job (it was a high frequency printing application, with little or no chance in job parameters on each job). It was easily done and did not involve massive programming convolutions. But this should only be done in certain circumstances that warrant it. And there was also a facility to force a PrJobDialog (holding down the mouse button when executing the Print command) But it is important to realize that the *user* is in control and should have the ultimate last word. That is what lies behind the Apple user interface. ===================================================================== Byron Han | UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han Apple Computer, Inc. | CSNET: han@apple.csnet 20525 Mariani Ave, | ATTNet: 408-973-6450 Cupertino, CA 95014 | GENIE: BYRONHAN MS 27Y | CSERVE: 72167,1664 ===================================================================== All opinions and statements do not necessarily represent those of my employer, Apple Computer Inc. =====================================================================