Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uwm.edu!lll-winken!cert!netnews.upenn.edu!msuinfo!rang
From: rang@cs.wisc.edu (Anton Rang)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ToolBox Questions -- HELP!
Summary: 1) Use RomMapInsert; 2) Update events are never posted.
Message-ID: <RANG.91Apr28164807@nexus.cs.wisc.edu>
Date: 28 Apr 91 20:48:07 GMT
References: <1991Apr28.045855.7644@cs.yale.edu>
Sender: news@msuinfo.cl.msu.edu
Distribution: usa
Organization: UW-Madison CS department
Lines: 69
In-Reply-To: pittenger-laurence@cs.yale.edu's message of 28 Apr 91 04:58:55 GMT

In article <1991Apr28.045855.7644@cs.yale.edu> pittenger-laurence@cs.yale.edu (Laurence Arthur Pittenger) writes:
>1. Resource Manager getting CDEFs
>
>    I want to do some debugging by pulling in the cdef that a control
>will be using.  So I get it with GetResource ('CDEF', (procID >> 4)),
>as suggested in I.M., that is to say I get the cdef whose id is the
>control's procID/16.  Well and good.  And when the cdef is one that
>isn't in ROM, it works fine.  But when it is in ROM, it pulls in a
>completely incorrect value.

  Check out Inside Mac, page IV-19.  To search the ROM resources on a
Resource Manager call, you have to turn on RomMapInsert.  Some code
more or less like the following should work.  (Obviously, if the
constants are already defined in some include file, use them.)

	const RomMapInsert = $B9E;	{ IM IV-19, IV-309 }
	      mapTrue = $FFFF;		{ IM IV-19, IV-21 }

        type PtrToInt = ^integer;	{ Pointer to two bytes }

	...

	PtrToInt(RomMapInsert)^ := mapTrue;  { Search ROM, with ResLoad true }
	some_handle := GetResource('CDEF',some_id)

	...

>2. Drawing objects directly onto the screen

  I won't say "you shouldn't do this" because I'm not sure what you're
doing it for.  However, I'll sort of say it:

>  I have some non-window based graphics objects I need to display in a
>multi-finder environment.

  Have you considered using a custom WDEF and displaying these as
windows (one object per window)?  You'd have a much better chance of
getting things to work this way, I think.

>I can't call PostEvent, because update events are handled in a
>special way (apparently) and calling PostEvent w/ UpdateEvt bombs.

  I think you'd have to traverse the window list, checking which
windows need to be updated, and calling InvalRgn() whenever you find
one which needs to be taken care of.  This is a Bad Idea, but I don't
think you can bypass the window manager any other way....

>Second, suppose my display consists only of this non-window object.
>How do I make sure that I will get the update events sent to my
>application so that I can update its display?

  You won't ever get an update event.  Update events indicate that a
window needs to be updated.  There's no way that the system knows
there's something on the screen if it's not in a window or part of the
desktop.

>               --- How do I post an Update event? ---

  See above.  You can't post them, but you can InvalRgn() a window
which you don't own.

>  --- How do I get update events for a non-window based display? ---

  You don't.  Think again, seriously, about why you're not using
windows for this.  (Presumably there's a good reason; maybe if we had
more information, we could come up with alternatives or better ideas
for how to deal with your problems here.)

	Anton
   
+---------------------------+------------------+-------------+----------------+
| Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | "VMS Forever!" |
+---------------------------+------------------+-------------+----------------+