Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!odawa From: odawa@well.UUCP (Michael Odawa) Newsgroups: comp.sys.mac.programmer Subject: Re: Making a control in the Print Job Dialog inactive Message-ID: <12990@well.UUCP> Date: 3 Aug 89 05:08:26 GMT References: <56212@tut.cis.ohio-state.edu> <12928@well.UUCP> Reply-To: odawa@well.UUCP (Michael Odawa) Distribution: all Organization: Simple Software, Mill Valley, CA Lines: 35 In article <12928@well.UUCP> I wrote: >In article <56212@tut.cis.ohio-state.edu> Scott Sutherland writes: >>Since my application can't print in draft mode...I'd like to dim the >>Draft radio button [in the PrJobDialog]... > >We had to do the same thing in DocuComp, and we used the techniques >outlined in Tech Note #95. The Draft Mode button is Item #8 in the >Imagewriter PrJobDialog. Hilite it as Inactive... Since my original posting of this technique, several perceptive people have pointed out that I failed to follow one of the caveats of Tech Note #95, which said, o Don't count on an item retaining its current position in the list. If you depend on the Draft button being a particular number in the ImageWriter's style dialog [sic] item list, and we change the Draft button's item number for some reason, your program may no longer function properly. They are correct; I was wrong, and my penalty is that I will probably have to revise the product when the new print architecture comes out. At the time I wrote the code (over a year ago) it seemed like a reasonable risk to take. In retrospect I do not regret the decision, as (1) my users will have been spared two years of getting garbage when they choose the Draft print mode, and (2) it will be time for a new rev anyway. However with the announced coming of System 7 and all that portends I would not now write code which violated the caveat so blatantly. Hence I too must caution, DO NOT USE TECH NOTE #95 TO DISABLE DRAFT PRINTING (anymore). Michael Odawa Simple Software odawa@well.uucp