Several Problems Part II

[Walker Sigismund <wws@cix.compulink.co.uk>]

Thank-you for all the quick responses to my prior problem report.  I
have
 had a connection problem which has now been sorted out... APOLOGIES
for my own tardy response.

;;;;>>>>>>>>>>>>>>>>>>>>>>>>>>>
to Mark Preece  who writes in response to the floating point bug:

>? (/ 0.0)
>1.797693134862316E+308

>> Is this on a IIci (I know that's what you normally use)? We've
never 
>> seen (or seen reports of) this behavior except on PowerBook 170s
(due
>> to a PB bug that's described in the MCL 2.0 Release Notes).

>> Mark

Yes, this is on a MacIIci, 20Meg RAM, Internal Video and Portrait
monitor
>> ;;;;>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> From: Osiris on Sun, 11 Jul 1993
>> Subject: Re: New PTABLE

>> I had this problem before in another context.  I can't remember
for sure, but
>> I either fixed it by going to the Monitors cdev and changing the
monitor to
>> 1-bit color and back to 8 bit (this makes it create a new resource 
(the old
>> one may be corrupted)), or by re-installing my system.  Don't
forget
>> that it may not be the init's fault.  It could be another problem
that only
>> shows up when the init is active...
>> 
>> Hope this helps...

Thanks for the suggestion.  Unfortunately this did not seem to solve
my problem, but it does seem to shed more light on it.  When I change 
to from 16 shades to B&W only, the affected band at the bottom grows
higher (about 4 times) to the size of the init icons.  As soon as the 
ptable icon loadsPeven when it is the only extension or initPthe
grey-pattern band occurs across the bottom occurs and the items which 
should be in this band are found at the top of the monitor.  This
includes the ptable init but not anything that may have loaded before 
it.  Since this occurs at startup it must be an interaction between
the hardware (as above) and the system or finder B-7.0.1. 

Given the behavior just described it appears that the problem is in
PTABLE as the amount of memory overlap is constant rather than
proportional.  In other words since the area grows higher with B&W it 
indicates that the absolute amount of memory affected is the same. 
So Ptable probably miscalculates the amount of memory used by the
monitor by a given offset.  With B&W this leads to a larger
percentage of the desktop being affected than with 16 shades.   If
the problem was with the system, on the other hand, I would expect
that the band would stay the same size as changing to B&W forces
parameters to recalculate in proportion to the amount of space
needed.  Does this make sense?

>> ;;;;>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> From: "Mark A. Tapia"  Mon, 12 Jul 1993
>>
>> c) Why is it that MCL crashes when WINDOW-HARDCOPY is sent a TRUE
>> optional show-dialog? argument?
>> Since you're trying to use window-hardcopy to print graphical
windows,
>> you might be interested in print-u.lisp.hqx in the
/pub/MCL2/contrib
>> directory. This utility enables you to associate a "remembered"
print
>> (page setup) record with each file. Set the global variable
ccl::*debugging*
>> to t and you'll receive more debugging information about your
problem

Okay my mistake on this one.  I meant to write WINDOW-HARDCOPY is
sent a FALSE show-dialog? which avoids putting up the printing
dialog-box which requires human intervention.  So my problem is
actually one of getting a series of windows--for example fred source
files using provided source for FRED window-hardcopy, as well as data 
analysis pictures using my window-hardcopy (below)--to print without
having to hit return all the time.  I can print them fine now one at
a time if the optional argument is TRUE.  

Still I have ftp-ed print-u.lisp.hqx which is quite impressive and
want to spend more time with it.  The documentation states, however,
that it ignores show-dialog?  

Also, you may need to modify certain routines for your stuff to work
on an Imagewriter which I find to have some quirks not found on
Laserwriters.  Bill StClair recently helped me get Imagewriter
printing to work again following patch 2, and I believe has forwarded 
the patch to you Mark for release in an updated version of your
utilities.  But since I do not see signs of it in the current file
let me copy it below:

(defmethod window-hardcopy ((w *Graphic-Window*) &optional
(show-dialog t))
  (unwind-protect
    (progn
      (#_PrOpen)
      (prchk ccl::$err-printer-load)  ;; prchk from FRED-Window
      (let ((pRec (get-print-record)))
        (#_SetCursor *ARROW-CURSOR*)
        (when (or (and (not show-dialog)
                       (progn (#_prjobmerge pRec pRec) t))
                  (#_PrJobDialog pRec)
                  (throw :cancel :cancel))
          ;_PrOpenDoc puts up a dialog window which causes the event
system
          ;to get confused.  So we do the whole thing without
interrupts, and
          ;make sure to clean up before handling errors.
          (handler-case
            (let ((ccl::*break-on-errors* nil) ;; holdover from
original Allegro source code 
                  )
            
              (with-macptrs (saved-port saved-device)   ; from Bill
StClair at Apple
                (ccl::get-gworld saved-port saved-device)
                (without-interrupts
                 (unwind-protect
                   (with-macptrs ((hardcopy-ptr (#_PrOpenDoc pRec
(%null-ptr) (%null-ptr))))
                     (ccl::set-gworld hardcopy-ptr)
                     (unwind-protect
                       (with-dereferenced-handles ((ppRec pRec))
                         ppRec          ; otherwise compiler warning
                         (prchk ccl::$err-printer-start)
                         (unwind-protect
                           (progn
                             (#_PrOpenPage hardcopy-ptr (%null-ptr))
;; or (CCL::%GETPORT)
                             (ccl::prchk ccl::$err-printer-start)
                             (view-Print-contents w)    ; draws
picture
                             )
                           (#_PrClosePage hardcopy-ptr)
                           ))
                       (#_PrCloseDoc hardcopy-ptr)))
                   (ccl::set-gworld saved-port saved-device)   ; from 
Bill StClair at Apple
                   ))
                (when (eql (href pRec :tPrint.prJob.bJDocLoop)
#$bSpoolLoop)
                  (prchk)
                  (rlet ((StRec :tPrStatus))
                    (unwind-protect
                      (progn
                        (#_PrPicFile pRec (%null-ptr) (%null-ptr)
(%null-ptr) StRec)
                        ;; (MY_PrPicFile pRec StRec) ;; eventually do 
above, maybe pass
                        ;; a pointer to a printing update function
(although from the recent
                        ;;  comment in MCL-digest a def-pascal
function should crash there)
                        (prchk))
                      ;; This set-gworld from Bill St-Clair shouldn't 
be necessary
                      ;; but it fixesa bug in the ImageWriter driver
                      (ccl::set-gworld saved-port saved-device))))))
            (error (c) (error c)))
          t)))
    (#_PrClose))
  )

BillUs help was to add the  (with-macptrs (saved-port saved-device)
(ccl::get-gworld saved-port saved-device) and the (ccl::set-gworld
saved-port saved-device)) type of stuff without which the above (on
an Imagewriter but not on a Laserwriter) will crash after printing. 
Any of the poor programming is my own but I have not had time to
streamline this again after getting it to work as is..


>> 
>> d) Opening application documents
>>    To retrieve the name of the file which "launched" the
application,
>>    you need to use (finder-parameters). Here is a partial example
from
>>    the binhex.lisp file in the binhex folder in the examples
folder:
>>        (let ((file-list (finder-parameters)))
>>       (when (eq (car file-list) :open)
>>         (dolist (f (cdr file-list))
>>           (let ((type (mac-file-type f)))
>>             (if (eq type :text)
>>               (binhex-decode f)
>>               ; this should never happen because binhex won't be
the creator
>>               ; of any non-text files
>>               (binhex-encode-get-outfile f))))))))
>>     In your toplevel function you need to call (finder-parameters) 
and
>>     the handle each of the files.

Yes, That works nicely. Merci Beaucoup!!

>> ;;; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
THANK-YOU   Walker