pittenger-laurence@cs.yale.edu (Laurence Arthur Pittenger) (04/28/91)
Here are 2 unrelated (except that they're both problems in my code)
problems w/ the toolbox, where Macintosh, as usual, has completely
insufficient documentation for anyone doing anything the least bit out
of the ordinary:
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. IM IV-3 says something about having to
put the rom resource map before the system resource map prior to
making the call to the ResourceManager, but it gives no information as
to exactly what this means or how to do it. When I copy the cdef (id
= 1 in this case) from the System into my application, however, the
exact same code works fine. Therefore:
--- How do I access resources in ROM? ---
2. Drawing objects directly onto the screen
I have some non-window based graphics objects I need to display in a
multi-finder environment. Therefore, every time I move or delete one
of these objects, I have to take care of updating the things behind it
myself, since I'm not doing it through the Window Manager. How do I
send an update event to all the programs/windows in the background,
and how do I make sure the desktop display is also updated? I can't
call PostEvent, because update events are handled in a special way
(apparently) and calling PostEvent w/ UpdateEvt bombs. 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?; from what I can tell, update events
are only sent to windows. Therefore:
--- How do I post an Update event? ---
--- How do I get update events for a non-window based display? ---
Thanks in advance,
LP
--
Laurence A. Pittenger
CSNET : pittenger-laurence@cs.yale.edu
BITNET : pitlaua@yalevm , pittenger-laurence@yalecsrang@cs.wisc.edu (Anton Rang) (04/29/91)
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!" | +---------------------------+------------------+-------------+----------------+
pittenger-laurence@cs.yale.edu (Laurence Arthur Pittenger) (05/01/91)
Answers to my previous post indicate that the toolbox provides no way to handle directly drawing onto the screen. It is assume that all output will be managed through windows. So, my new question: the reason I wanted to bypass the WindowManager was because of severe restrictions on time & space; I wanted to avoid the window structures and the calls. Now, it seems, I have to implement my interface via windows. There are several ways to do this. One which I would like is to set the objects up as windows, but have them share common memory for their display. I would assume that this is done by assigning the appropriate field in the CWindowRecord so that they all access the same PixPat (and by making the appropriate adjustments when deleting, so one doesn't delete the common structure). Is this possible? Has anyone tried it before? What pitfalls await? Etc etc. Thanks, LP -- Laurence A. Pittenger CSNET : pittenger-laurence@cs.yale.edu BITNET : pitlaua@yalevm , pittenger-laurence@yalecs