This is App-printing-problem in view mode; [Up]
Date: Sun 04-May-1989 20:27:56 From: Unknown Subject: App printing problem A few weeks ago I would have regarded myself as a relatively competant C programmer, but in my attempts to learn Obj-C I have returned to the state of being a programming novice. Hopefully this will change soon. Here is the current problem: I have just written my first App. I created a CustomView that basically emulates a graphics library that the people in my research group know and love. It was actually remarkably easy. I got the screen interface to an acceptable state. I then went to add in a print option to the main menu. I used the IB to add in the menu item which calls a -print: method in my CustomView. The print: method just calls [self printPSCode:self] This correctly fires up a print panel and spools a file to the printer. The problem is that it prints two blank pages, not what is on the screen. I traced the problem down to the fact that I had implemented a bunch of methods in my View that send PS to the current context via pswrap routines or PSxxxx() calls. I did not, however, create a drawSelf:: method. Evidently really want is to have something that takes all of the PS that I have sent to the window server and send it to the printer. I tried using the openSpoolFile:, ... beginPSOutput, ... endPSOutput... series and that correctly printed what I wanted but since that changes the current context to point at the spool file, my graphics did not appear on the screen. So the question is: apart from creating drawSelf:: method that keeps track of what I have been sending to my CustomView, is there any way to send my PS code to the display and the printer simultaneously? Other general topics I haven't heard discussed are: has there been any progress towards programming the DSP to emulate a 9600 baud modem? How about a fax receiving station? Also I have been thinking of writing a graphical interface for GDB ala dbxtool for the Suns (unfortunately I don't have the time so this probably won't get done in the forseeable future). Another interesting concept that seems to have been ignored lately, is that of what plans there are for the archiving methods that everything inherits from the Object class. I, for one, would love to see a "Checkpoint" or "Bookmark" command on the Workspace manager, which archives the current state of all running Apps so that you could jump back to a known state. For example, this would be great for logging out, letting someone else use the machine, and then logging back in to the exact state that you left the machine. All open files in the Editor would be restored, the IB windows would be all be set up, and whatever entry I had been looking at in the Librarian, would still be there, etc. I think this would extremely useful. Just thought I would stir the pot... ..Steve ** ________ ** "...Steve" is a registered trademark of the Trainoff Corporation ________ >From: ali@polya.Stanford.EDU (Ali T. Ozer)
Date: Sun 05-May-1989 14:51:12 From: Unknown Subject: Re: App printing problem In article <1601@hub.ucsb.edu> trainoff@sbphy.ucsb.edu writes: >I have just written my first App. I created a CustomView that >basically emulates a graphics library ... The print: method just >calls [self printPSCode:self] This correctly fires up a print panel >and spools a file to the printer. The problem is that it prints two >blank pages, not what is on the screen. I traced the problem down to >the fact that I had implemented a bunch of methods in my View that >send PS to the current context via pswrap routines or PSxxxx() calls. >I did not, however, create a drawSelf:: method. Evidently >printPSCode: calls display or drawSelf:: to create its page. Every view should implement drawSelf::, and drawSelf:: should be able to recreate whatever is visible in the view at the time it is called. It's possible to create views that do not have drawSelf:: methods, of course, but then you run into problems such as the above. If you do not create a drawSelf:: method, then you are probably using some other mechanism to draw in your view. That makes your view highly unportable; as you noticed, it becomes harder to print, and it will also be harder to do such things as put your view in an Interface Builder palette, or cut/copy PostScript from your view into the pasteboard, to put your view in a ScrollView, and so on. With a few lines (if any) of code. You might want to create a drawSelf:: method that calls your other drawing routines in the correct order to recreate what's in the view. Leave everything else as it is... Ali Ozer, NeXT Developer Support aozer@NeXT.com >From: edmoy@violet.berkeley.edu
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.