[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Drawing Cursor or Cursor to PICT

>Not sure if this is a re-send or not, sorry.
>Does anyone have code that will draw a cursor in a grafport?
>Or, failing that, does anyone have code that will cram a cursor into a
>I want to provide a tool-pallette class.

Here's a quick 15 minute hack:


; draw-cursor.lisp
; Drawing a cursor to a grafport.
; Does not handle the mask.
; May fail if the cursor resource is purgeable.

(in-package :ccl)

(export 'draw-cursor)

(defun draw-cursor (cursor h &optional v)
  (let ((p (make-point h v))
        (cursor-handle (if (fixnump cursor)
                         (#_GetCursor cursor)
    (when (%null-ptr-p cursor-handle)
      (error "~s does not specify a valid cursor" cursor))
    (rlet ((srcrect :rect :topleft #@(0 0) :botRight #@(16 16))
           (dstrect :rect :topleft p :botright (add-points p #@(16 16)))
           (bitmap :bitmap
                   :bounds srcrect
                   :rowbytes 2
                   :baseaddr (%get-ptr cursor-handle)))
      (with-macptrs ((port (ccl::%getport)))
         (rref port :grafport.portbits)
(defparameter *w* (make-instance 'window))

(defun draw-cursors (&optional (cursors
                                '#.(list #$iBeamCursor
  (with-focused-view *w*
    (let ((point #@(10 50)))
      (dolist (cursor cursors)
        (draw-cursor cursor point)
        (setq point (add-points point #@(24 0)))))))



>While I'm on the topic, does anyone have a good way of getting a few
>resources bundled with an independent module?
>The choices seem to be:
>  A.  Provide a separate resource file.
>  B.  Put the resources in the resource fork of the source.
>  C.  Put hex values in the source.
>  D.  Other__________
>B.  seems ideal in theory, but in practice...when you open a fred-window to
>the source to fix a bug, MCL opens the resource fork in such a way that if
>it was already open, BAD THINGS happen.  [I forget if it was a crash or
>just all my handles going walkabout.]  Also, it has the same problems as A
>when it comes to saved applications.
>A.  would be OK, but it's a hassle for the client programmer to haul this
>stupid little resource file around with his code and saved applications,
>not to mention that it has to be somewhere I can *find* it, as opposed to
>where he/she thinks it should go.
>C.  *HACK!!!!*   'nuff said

The usual way to do this is to use option A during development and
then put the resources in the resource fork of the distributed
application for delivery. This can be done with the the :resources
keyword to save-application (which was not documented for 2.0b1).