brian@ut-sally.UUCP (Brian H. Powell) (12/23/87)
In a program I'm working on, I load all the cursors that I am going to
use at the beginning of the program, move them to high memory, lock them down,
dereference the handles and use pointers to them for the duration of the
program. Fine.
After playing around with the control panel, I noticed that my watch
cursor had turned into mush. I tried a few other DAs, but I couldn't get them
to exhibit this behavior. I did a step spy on the handle and found out that
somebody is unlocking the handle. I'm not sure if it's the control panel or
the OpenDeskAcc code, but it happens in there somewhere.
This all reeks of good old Macintosh Technical Note #1, in which is
discussed the issue of DAs purging system resources, for example, oh, say the
watch cursor, that might be in use by the application. This makes me tend to
believe that the DA is wrong in unlocking my handle. (As opposed to me being
wrong expecting locked handles to system resources to stay locked.)
Any comments? I plan to refetch my cursors after the OpenDeskAcc call
now, rather than call GetCursor each time I want to use a cursor. Is this
safe? Are there any other things lurking about that want to unlock my
handles?
Brian H. Powell
UUCP: ...!uunet!ut-sally!brian
ARPA: brian@sally.UTEXAS.EDU
P.O. Box 5899
Austin, TX 78763-5899
(512) 346-0835singer@endor.harvard.edu (Rich Siegel) (12/24/87)
In article <9931@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: > > In a program I'm working on, I load all the cursors that I am going to >use at the beginning of the program, move them to high memory, lock them down, >dereference the handles and use pointers to them for the duration of the >program. Fine. No, this is not fine. I will explain. > After playing around with the control panel, I noticed that my watch >cursor had turned into mush. I tried a few other DAs, but I couldn't get them >to exhibit this behavior. I did a step spy on the handle and found out that >somebody is unlocking the handle. I'm not sure if it's the control panel or >the OpenDeskAcc code, but it happens in there somewhere. It's not good practice to lock a handle, then keep its master pointer around, because exactly that sort of thing can happen. The best way to get the same effect is to preload the CURS resources and keep the CursHandles as global variables. > This all reeks of good old Macintosh Technical Note #1, in which is >discussed the issue of DAs purging system resources, for example, oh, say the >watch cursor, that might be in use by the application. This makes me tend to >believe that the DA is wrong in unlocking my handle. (As opposed to me being >wrong expecting locked handles to system resources to stay locked.) Tech Note number 1 is clear on the subject of *purging* resources, but says nothing about locking or unlocking them. >Brian H. Powell --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *
brian@ut-sally.UUCP (Brian H. Powell) (12/25/87)
> In article <9931@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: >> >> In a program I'm working on, I load all the cursors that I am going to >>use at the beginning of the program, move them to high memory, lock them down, >>dereference the handles and use pointers to them for the duration of the >>program. Fine. In article <3646@husc6.harvard.edu>, singer@endor.harvard.edu (Rich Siegel) writes: < It's not good practice to lock a handle, then keep its master pointer < around, because exactly that sort of thing can happen. The best way to < get the same effect is to preload the CURS resources and keep the CursHandles < as global variables. That's sounds like a good idea, but I've got a question about it. I presume I should then have global handles to the cursors. I shouldn't have them locked. So, my call would be SetCursor(*watch_cursor_hdl); /* in C */ But what if the cursor relocates while the watch is being displayed? I guess the question is, "Does SetCursor make a copy of the cursor and use that, or does it use the actual cursor that it's given?" If it's the latter, I'll have to copy the cursor into a non-relocatable block of memory and use it there. What a waste. By the way, one of the recent tech notes about multifinder said that you shouldn't modify the attributes of any of the system resources that are in memory. This means that my idea of locking the cursors is officially verboten. Brian
tecot@apple.UUCP (Ed Tecot) (12/25/87)
In article <9948@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: >> In article <9931@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: >>> >>> In a program I'm working on, I load all the cursors that I am going to >>>use at the beginning of the program, move them to high memory, lock them down, >>>dereference the handles and use pointers to them for the duration of the >>>program. Fine. > >In article <3646@husc6.harvard.edu>, singer@endor.harvard.edu (Rich Siegel) writes: >< It's not good practice to lock a handle, then keep its master pointer >< around, because exactly that sort of thing can happen. The best way to >< get the same effect is to preload the CURS resources and keep the CursHandles >< as global variables. > > That's sounds like a good idea, but I've got a question about it. I >presume I should then have global handles to the cursors. I shouldn't have >them locked. So, my call would be > SetCursor(*watch_cursor_hdl); /* in C */ > > But what if the cursor relocates while the watch is being displayed? I >guess the question is, "Does SetCursor make a copy of the cursor and use that, >or does it use the actual cursor that it's given?" If it's the latter, I'll >have to copy the cursor into a non-relocatable block of memory and use it >there. What a waste. Yes, SetCursor does copy the cursor. I'd also recommend not using global variables, instead, simply use the following: theCursor = GetCursor(cursorID); if (theCursor != nil) SetCursor(*theCursor); or in Pascal: theCursor := GetCursor(cursorID); IF theCursor <> NIL THEN SetCursor(theCursor^^); _emt
singer@endor.harvard.edu (Rich Siegel) (12/28/87)
In article <9948@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: > SetCursor(*watch_cursor_hdl); /* in C */ > > But what if the cursor relocates while the watch is being displayed? I >guess the question is, "Does SetCursor make a copy of the cursor and use that, >or does it use the actual cursor that it's given?" If it's the latter, I'll >have to copy the cursor into a non-relocatable block of memory and use it >there. What a waste. > Strictly speaking, this could (and probably will) break in the future, sometime, but for now it's probably safe. If I had to guess I'd say that SetCursor will copy the cursor and use CopyBits to stamp its image on the screen. Some offical commentary might be useful here. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *
jimc@iscuva.ISCS.COM (Jim Cathey) (01/05/88)
In article <3670@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes: >In article <9948@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: >>guess the question is, "Does SetCursor make a copy of the cursor & use that, >>or does it use the actual cursor that it's given?" If it's the latter, I'll > Strictly speaking, this could (and probably will) break in the future, >sometime, but for now it's probably safe. If I had to guess I'd say that >SetCursor will copy the cursor and use CopyBits to stamp its image on >the screen. I can't speak for Color Quickdraw, but the older Mac ROMs copy the SetCursor data into low-memory globals where the low-level mouse handlers can use it. Copybits isn't used at all, the mouse driver itself is nearly autonomous (and was probably written and running before Quickdraw was). +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! Spokane, WA ! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!jimc ! II CCCCCC ! (509)927-5757 +----------------+ "With excitement like this, who is needing enemas?"