From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-041 Date: Sat, 2 Jul 1994 17:46:50 +0200 (MET DST) C.S.M.P. Digest Sat, 02 Jul 94 Volume 3 : Issue 41 Today's Topics: Detecting pre-68020 CPU for 68020 code Fast Animations (WAS: Fast full screen scrolling: impossible?) FlattenMovieData bug??? Here's how to get OpenDoc How to know the cursor is into a polygon? PowerPC load-store (was Re: Fast full screen scrolling: impossible?) Q: Default button & Return key in Modeless Dialog Questions about Tmon? Saving PICT files - Here's CODE!! Scroll Bars in DLOG? Why should't you move baseAddrs? cntl-opt-esc scroll bars in modal dialogs The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From nagle@netcom.com (John Nagle) Subject: Detecting pre-68020 CPU for 68020 code Date: Thu, 16 Jun 1994 16:44:14 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Now that Symantec C++ is finally generating 68020 code when asked to do so (for years, that switch did nothing), it's worth nothing that this creates a problem in C++. In C programs, even Think C type programs, the first code executed is in "main", so it's sufficient to check CPU type there. But in C++, static constructors run before "main". Now that TCL is starting to use constructors, and constructors are starting to work right in SC++, it's more likely that code with a 68020 instruction might be executed before "main". It's hard to deal with this in a way that's guaranteed to work from the user program. The check for 68020 needs to be made in "CODE 1", the startup code block cranked out by the compiler for every C++ program. The user can't do this; only Symantec can. Anybody still care about pre-68020 machines, anyway? John Nagle +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Thu, 16 Jun 1994 19:10:32 -0700 Organization: Internet for the Olympic Peninsula In article , nagle@netcom.com (John Nagle) wrote: > > Anybody still care about pre-68020 machines, anyway? I don't, and I have two of them (a Plus, and a first 100-days Mac now in 512KE form). However, there still are some Mac Portable owners around who do. By now, they must be used to programs which claim to require a 68020 or better crashing on their machine, but it certainly isn't a nice thing to do to them. Do the constructors for the static objects actually *use* any 68020 instructions on a regular basis? [Gestalt is available if you really want to check in each such constructor...or in a phoney or real object you arrange to have constructed first.] -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] No hablo Intel. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Fri, 17 Jun 1994 15:39:19 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) jwbaxter@olympus.net (John W. Baxter) writes: >Do the constructors for the static objects actually *use* any 68020 >instructions on a regular basis? [Gestalt is available if you really want >to check in each such constructor...or in a phoney or real object you >arrange to have constructed first.] If you do any subscript calculations involving 2D arrays or arrays of structures, you'll probably use the 32-bit multiply on a 68020. On 68000 machines, a subroutine is called for every 32-bit multiply. You can't have an object you "arrange to have constructed first". It's a feature of C++ that order of static constructor execution is random across file boundaries. ARM 12.6.1. You can't even call Gestalt from the constructor usefully unless your class is a base class. Base class constructors get called first, so if your class is derived from another class, its constructor will be called only after the base class constructor has already run. It won't help to override functions in the base class, either; the base class versions will be called when the base class constructor is called. So there really isn't a sound way to do this. John Nagle John Nagle --------------------------- >From cfranz@home.malg.imp.com (Christian Franz) Subject: Fast Animations (WAS: Fast full screen scrolling: impossible?) Date: Thu, 16 Jun 1994 09:14:27 GMT Organization: Union Bank of Switzerland, CH In article <1994Jun13.212936.24879@dal1>, seanmcd@ac.dal.ca wrote: > > In article , stay@park.uvsc.edu (Steve Taylor) writes: > > From article <1994Jun12.232257.24853@dal1>, by seanmcd@ac.dal.ca: > >> I think Chuck Yeager's Air Combat does this too. You can see interlacing > >> in the terrain if you rock the plane back and forth. > >> > >> Sean > > > > Could someone describe this technique in more detail? Are you talking > > about leaving the other lines there and blitting the other half or > > are you talking about doubling the height of the lines or what? > > Thanks. > > > Well the description given above makes AstroChase 3D sound like CYAC, > although the only thing I've seen in AstroChase 3D is the venetian blind > style, rendering the frame onto every other line. Deliverance also has the > option to do this, as does a game called Gate. It looks to me like CYAC > does interlacing, i.e., there are no black lines alternating with the > graphics, but if you rock the plane > or turn rapidly, you can see the interlacing effect fairly easy in large > polygons. I'm currently developing a 3D space game and of course, I have the same problems. I have tried many things, among them the alternate line modes used by Astrochase (draw every other line) and CYAC (draw even lines on even frames, odd lines on odd frames). All these algorithms make one main assumption: You draw the image in an off-screen buffer and after you are done drawing it, you blast the image to screen. It usually takes three steps: 1. erase offscreen buffer 2. draw new frame offscreen 3. blast offscreen image on-screen. Tuning step 3 can speed up your program, but usually only by 1/6 max (optimized blitting is usually one third of the time per frame and I assume you double the speed of blitting by halving the lines to copy). I have found out that there is a much better method (however, I doubt if this technique can be applied to moving backgrounds as is the main title of this thread). Actually I didn't find out myself but Juri Munkki, Mac Animations Guru DeLuxe, did. Since my program uses polygon-oriented graphics, you collect all your polygons as if you would draw them. Then you compare them with all polygons drawn in the last frame and output *the*difference* to screen. This eliminates the need to erase your offscreen map and since two successive frames are usually similar to each other, you just draw a fraction of what you usually do. Although the overhead for collecting the polygons is probably a bit more than drawing them, the subsequent elimination of 90% that needs to be redrawn makes up for this. Also, if you just output the difference, this eliminates the need to as this is included into the algorithm. Mhhh. On second thought, this doesn't work at all for a scrolling background... But then, neither CYAC nor AC3D have moving background. > I don't know enough about 3D graphics to know whether you could > actually render even/odd scanlines or whether he's just splitting an > off-screen drawing into two blits. Well, I have some experience with 3D graphics and there are to fundamental different approaches. On is called object-space, the other scan-space (well, at least in german. They seem to translate badly). In object space you calculate all surfaces of the objects and project them on your (off)screen using normal projection methods. To tune your animation you use object coherencies (you take advantage of the fact that an object doesn't change much between two frames). In this algorithm you can't render only for odd lines. You have to render the whole scene and then transfer every other line. In scan space you take the inverted approach. For each pixel you decide which surface is frontmost and set this pixel to the appropriate color/texture. To tune this algorithm you can use scan-line coherencies (the fact that two pixels in any direction usually don't change much in color, both in x and y direction). With scan-space, you *can* render every other line directly. The third possibility is a combination of both methods. It's what Juri's program does (as I suspect. I havn't seen a single line of his code, but the performance of the demos he sent me leave no other explanation). You use object space to pre-calculate all objects (i.e. all vertices that define your surfaces), collect them to polygons that are not drawn but *mathematically* compared to the last frame, collect the difference to other polygons and finally draw the new polygons (using scan coherencies). You can draw directly to screen since you change so few things that it seems instantaneous. Juri claims that his algorithm is a bit faster than the one used in FA-18 (I think they use a similar approach) and quite frankly, I believe every word of it. > > Sean OK, sorry to have held you up with this rather lengthy discussion of some arcane and irrelevant topic, but I have spent a lot of time investigating this and maybe someone can make some use out of it. Have a nice day. Cheers, Christian - - Christian Franz * Union Bank of Switzerland, CH cfranz@home.malg.imp.com <- at home -> +41-1-261 26 96 --------------------------- >From Frank Manshande Subject: FlattenMovieData bug??? Date: Mon, 13 Jun 1994 14:47:53 GMT Organization: AND Software BV Hi, According to the Q/A in Develop 16 (page 130)... "Since FlattenMovieData" will simply append to a data fork of a file, you can pass it any data file and it will append the movie data to that file. Quicktime doesn't care what's stored before or after the movie data, as long as you don't reposition the movie data within the data dile." Well, if I try this, and append a movie using FlattenMovieData", the first 8 bytes will be overwritten with 4 bytes and then 'mdat'. Even if I pass the flag 'flattenAddMovieToDataFork' ! It seems like this is a bug! I don't want that data stored before the movie overwritten. My solution now is to read the first 8 bytes, then FlattenMovieData one or more quicktimes movie files and then restore the first 8 bytes. But I am not certain that replacing those 8 bytes won't have any side effects. What I do is store the "Movie" structure, using PutMovieIntoDataFork at a specific offset. My datafile looks like this: - ------------------------------- | some data (other than movies) | - ------------------------------- | flattened movie | - ------------------------------- | "Movie" structure | - ------------------------------- | flattened movie | - ------------------------------- | "Movie" structure | - ------------------------------- | flattened movie | - ------------------------------- | "Movie" structure | - ------------------------------- This works. But the first 8 bytes are overwritten in "some data". Any info would be very much appreciated! Frank Manshande frankm@and.nl +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Mon, 13 Jun 1994 18:05:25 GMT Organization: The World Public Access UNIX, Brookline, MA Frank Manshande writes: >This works. But the first 8 bytes are overwritten in "some data". What happens is that QT stores the info in a Bento-like atomic form. The single-fork movie (flattened means "self-contained", not "single-fork"). must contain "atoms" in order for QT to properly navigate it. Atoms are structured as follows: { long atomSize; // includes atomSize+atomType OSType atomType; ... atom specific data ... } So for your multimovie file to work it needs to contain atom headers before each movie data atom of the right size. It also needs an atom header in front of your data to allow QT to traverse the movie. This isn't a bug AFAIK; it seems Develop 16 was wrong in the general case (you can't just append the movie data for single fork files). If you control the file format, however, and you can add the atom header yourself, then it is feasible to do what they say. Given this structure, however, I'd avoid "restoring" the first 8 bytes as you were doing, since it's bound to affect your ability to access the multiple movies... Additionally, you might want to check out John Wang's article in Develop 17 ("Somewhere in QuickTime"), since I seem to remember there is a bug in FlattenMovieData in which the size field is not properly set when using multiple movies, and a fix (BetterFlattenMovieData) is discussed in it. Hope this helps, -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From Frank Manshande Date: Tue, 14 Jun 1994 06:51:11 GMT Organization: AND Software BV In article Ivan M CaveroBelaunde, ivanski@world.std.com writes: >If you control the file format, however, and you can add the atom header >yourself, then it is feasible to do what they say. Given this structure, >however, I'd avoid "restoring" the first 8 bytes as you were doing, >since it's bound to affect your ability to access the multiple movies... Well, First of all thanks for your time! I have written two small programs. One that adds a movie to ANY kind of file, and displays the offset of the 'movie resource' using the PutMovieIntoDataFork call. And another program that can play the movies at the specified offsets. This does seem to work correctly. The only side-effect I have encountered so far is that the file which I added the movies to cannot be played by SimplePlayer. SimplePlayer can play the first movie if I don't save and restore the first 8 bytes of the file. But because I don't want to play the movies using a general movie player, but only from my own program, this should not be a problem. The reason I have to restore the first 8 bytes of the file is that the quicktime movies are added to a specific database file (the database file is of proprietary format), and the database engine doesn't work if the first 8 bytes are overwritten. The reason why I don't just create two seperate files (one with the database and one with all the quicktime movies) is that our customers (and our company) only wants ONE file, which contains all the data. Does anybody know if saving and restoring the first 8 bytes that FlattenMovieData overwrites has any other side effects then not allowing programs such as SimplePlayer to play a movie? Thanks! Frank Manshande frankm@and.nl +++++++++++++++++++++++++++ >From Peter Vanags Date: 15 Jun 1994 20:43:47 GMT Organization: UCB In article Frank Manshande, frankm@and.nl writes: >Does anybody know if saving and restoring the first 8 bytes that >FlattenMovieData overwrites has any other side effects then not >allowing programs such as SimplePlayer to play a movie? Nope, not a problem. The only caveat is you MUST use NewMoveFromDataFork() with the offset to the 'mdat' or 'moov' atom to retrieve the movie, if the other data in the data fork is not stored in "atom" form. To be clean about using FlattenMovieData(), you should use the following procedure: - store the first 8 bytes of the data fork - store the file's length - append a dummy 'mdat' atom to the end of the data fork - call FlattenMovieData() - check the offset to the end of the movie data, which is now in the first 4 bytes of the data fork, compare to the length before FlattenMovieData() was called and update your dummy atom - restore the first 8 bytes of the file's data fork I talked with John Wang at MacDTS (author of the "Somewhere in QuickTime" column in develop) quite a bit about this issue right before he published the article. Peter Vanags peterv@uclink.berkeley.edu +++++++++++++++++++++++++++ >From jywang@apple.com (John Wang) Date: 16 Jun 1994 00:27:12 GMT Organization: Apple Computer, Inc. FYI. The bug fix for the problem described in issue #17 of my article has been added to QuickTime 2.0. If you use my BetterFlattenMovie or BetterFlattenMovieData routine, you will be all set since BetterFlattenMovie only patches FlattenMovie when QuickTime 1.6.X or earlier is used. John --------------------------- >From Jens Alfke Subject: Here's how to get OpenDoc Date: Wed, 15 Jun 1994 23:30:31 GMT Organization: Apple Computer I just got off the phone with our evangelist, Mark "Rev. Billy-Bob" Thomas, to get the true facts about OpenDoc seeding. Here's the scoop. * The current (a6) version of OpenDoc is _not_ going to be distributed more widely than to the WWDC attendees. They decided against a blanket mailing to all registered developers because, as Mark put it, "You only get one chance to make a good first impression". The a6 build is still a bit flaky, requires MPW, and doesn't come with much in the way of documentation. Their fear was that, if everybody got it, many would play with it a little, run into problems, and not look at it again later when things are more polished. * The beta seed _is_ going to be distributed widely. It'll be on the developer CD. It'll be on the 'develop' bookmark CD, and we're hoping to get a number of OpenDoc articles in that issue of 'develop'. (Note that anyone can order single issues of 'develop' from APDA for $10.) This will probably be in September given the lead time involved in pressing CDs. By that time the code will be more stable, you'll be able to build with CodeWarrior (hope hope hope), and there will be at least draft versions of the official documentation for both OpenDoc and the framework. * But! If you're interested in getting started with OpenDoc _now_ (and how can I blame you?) you can send mail to OpenDoc@applelink.apple.com and get a CD with version a6 in return for filling out a short form. * Feel free to post OpenDoc questions here; I'll try to answer them. There is an OpenDoc mailing list; send mail to with body "subscribe opendoc-interest" to subscribe. There is also a discussion board on AppleLink somewhere. I hope this answers your questions. Sorry about any misinformation I've posted in the past ... --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From chuck@molecule.Physics.Drexel.Edu (Chuck Browne) Date: Thu, 16 Jun 1994 16:35:00 GMT Organization: Drexel University Jens Alfke (jens_alfke@powertalk.apple.com) wrote: : I just got off the phone with our evangelist, Mark "Rev. Billy-Bob" Thomas, : to get the true facts about OpenDoc seeding. Here's the scoop. : * The beta seed _is_ going to be distributed widely. It'll be on the : developer CD. It'll be on the 'develop' bookmark CD, and we're hoping to get Thanks, Jens Is there any problem with lending it to Metrowerks for shipping on the DR4 CD, which roughly comes out at the same time? (Not that I'm trying to save a couple of bucks or anything... :-) ) Chuck +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 16 Jun 1994 22:55:44 GMT Organization: Apple Computer Chuck Browne, chuck@molecule.Physics.Drexel.Edu writes: > Is there any problem with lending it to Metrowerks for shipping on the > DR4 CD, which roughly comes out at the same time? I think Mark wants people to go directly to Apple to obtain it. He wants to keep tabs on how many people have it and who they are (in case we need to send out any mass mailings, or sell your names and addresses to The Sharper Image :) > (Not that I'm trying to save a couple of bucks or anything... :-) ) I don't think we're charging anything for the OpenDoc seed. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From chuck@molecule.Physics.Drexel.Edu (Chuck Browne) Date: Fri, 17 Jun 1994 00:58:43 GMT Organization: Drexel University Jens Alfke (jens_alfke@powertalk.apple.com) wrote: : Chuck Browne, chuck@molecule.Physics.Drexel.Edu writes: : > Is there any problem with lending it to Metrowerks for shipping on the : > DR4 CD, which roughly comes out at the same time? : I think Mark wants people to go directly to Apple to obtain it. He wants to : keep tabs on how many people have it and who they are (in case we need to : send out any mass mailings, or sell your names and addresses to The Sharper : Image :) : > (Not that I'm trying to save a couple of bucks or anything... :-) ) : I don't think we're charging anything for the OpenDoc seed. I meant the $10 for develop, but what you say is good to hear. (Not that I need OpenDoc or anything, I'm just curious about it and what it will mean to software in the next couple of years... maybe I'll try it out, if I manage to get my PhD on schedule..) Thanks, Chuck : --Jens Alfke : jens_alfke@powertalk Rebel girl, rebel girl, : .apple.com Rebel girl you are the queen of my world --------------------------- >From belanger@bach.ulaval.ca (Yves Belanger) Subject: How to know the cursor is into a polygon? Date: Tue, 14 Jun 1994 18:09:32 GMT Organization: Universite Laval, Ste-Foy (Quebec), Canada Hello, I am writing an application where districts are drawn on a geographic map. Districts are made with many points, like a polygon in MacDraw. Each point is given a longitude and a latitude. I have functions that translate back and forth these coordinates into screen coordinates. My problem is how to determine that a user has clicked inside one of those polygon or the click was outside them all? If the solution could work with longitude and latitude, that would be greater, since less computing would be involved. Thank you. S. Beaudry +++++++++++++++++++++++++++ >From Mark Hanrek Date: Tue, 14 Jun 1994 22:49:07 GMT Organization: The Information Workshop In article Yves Belanger, belanger@bach.ulaval.ca writes: > I am writing an application where districts are drawn on a geographic > map. Districts are made with many points, like a polygon in MacDraw. > Each point is given a longitude and a latitude. I have functions that > translate back and forth these coordinates into screen coordinates. The most common approach is to take advantage of the Macintosh's built-in region capabilities. They are incredibly powerful, and very easy to use. You can easily take any polygon and create the equivalent region from it, which is kept in a RegionHandle. Keep a list of these RegionHandles handy, one for each district, and when the user clicks, take the location of the click and then in a loop use the PtInRgn() toolbox call to test whether that point is within each of the regions. When the result is true, bingo. If there are overlapping regions, be sure they are set up and tested in front to back order. That's all there is to it, unless I misunderstood your situation. I forget the exact calls to make a region from a polygon, but the whole process is exceedingly simple. This is the only approach I know of, really. Mark Hanrek +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Tue, 14 Jun 1994 21:09:23 -0700 Organization: Internet for the Olympic Peninsula In article , belanger@bach.ulaval.ca (Yves Belanger) wrote: > Hello, > > I am writing an application where districts are drawn on a geographic > map. Districts are made with many points, like a polygon in MacDraw. > Each point is given a longitude and a latitude. I have functions that > translate back and forth these coordinates into screen coordinates. > > My problem is how to determine that a user has clicked inside one of > those polygon or the click was outside them all? If the solution could > work with longitude and latitude, that would be greater, since less > computing would be involved. Thank you. My approach would be based on creating a QD region which covers the same "territory" as the polygon, and using the provided PtInRgn call against the region. Only if that were not "fast enough" would I probe further. Or...better...switch to QuickDraw GX, where you're likely to be working with a polygon shape, and you can easily hit-test that (or any other shape). That may put things a little more into the future than you want, though. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] No hablo Intel. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 15 Jun 1994 22:21:34 GMT Organization: Apple Computer In article Yves Belanger, belanger@bach.ulaval.ca writes: > My problem is how to determine that a user has clicked inside one of > those polygon or the click was outside them all? As has been said, the easiest solution is to create a region of the same shape as the polygon, then call PtInRegion. This does have the drawback that regions containing diagonal lines eat up lots of memory. (Think of the boundary of the region as a polygon, including little stairsteps at pixel edges on diagonal lines. The region then occupies about two to four bytes per vertex of that polygon.) Unfortunately, regions larger than 64kbytes will crash QuickDraw. This shouldn't be a problem unless your polygons are very large or complex. To create a region from a polygon: * Call OpenRgn * MoveTo the first point in the polygon, LineTo each succeeding point. Make sure to end with a LineTo back to the first point. * Call CloseRgn. Your other alternative is to use a real "point in polygon" test. You could either be the four millionth person this month to ask about this on comp.graphics.algorithms, or you could get a standard computer graphics textbook like "Computer Graphics: Principles and Practice" by Foley, Van Dam et al. There may also be source code available by ftp, but I have no idea where. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 16 Jun 1994 09:28:11 -0700 Organization: SRI International, Menlo Park, CA In article <1994Jun15.222134.21946@gallant.apple.com> Jens Alfke writes: >In article Yves Belanger, >belanger@bach.ulaval.ca writes: >> My problem is how to determine that a user has clicked inside one of >> those polygon or the click was outside them all? > >As has been said, the easiest solution is to create a region of the same >shape as the polygon, then call PtInRegion. This does have the drawback that >regions containing diagonal lines eat up lots of memory. (Think of the >boundary of the region as a polygon, including little stairsteps at pixel >edges on diagonal lines. The region then occupies about two to four bytes per >vertex of that polygon.) Unfortunately, regions larger than 64kbytes will >crash QuickDraw. This shouldn't be a problem unless your polygons are very >large or complex. > >To create a region from a polygon: >* Call OpenRgn >* MoveTo the first point in the polygon, LineTo each succeeding point. Make >sure to end with a LineTo back to the first point. >* Call CloseRgn. > >Your other alternative is to use a real "point in polygon" test. You could >either be the four millionth person this month to ask about this on >comp.graphics.algorithms, or you could get a standard computer graphics >textbook like "Computer Graphics: Principles and Practice" by Foley, Van Dam >et al. There may also be source code available by ftp, but I have no idea >where. >From the UMPG Vol II Subject: Re: Point in Polygon routine needed From: fry@zariski.harvard.edu (David Fry) In article <8fxkxAO00WB7M=nOFO@andrew.cmu.edu> Andrew Lewis Tepper writes: >I don't know if this routine is "standard", I just came up with it recently: > >For a polygon of points p1...pn, and a point P, make a table as follows: > >T(1)= angle from p1 to P to p2 >T(2)= angle from p2 to P to p3 >... >T(n)= angle from pn to P to p1 > >express all angles as: -PI < angle < PI. > >Add all entries in the table. If the sum = 0, the point is outside. If >the sum is +/- PI, the point is inside. If the point is +/- xPI, you >have a strange polygon. If ANY angle was = +/-PI, the point is on the >border. > >Does anyone know if this is considered a good (known?) algorithm? It >took a long time to come up with! You have the essence of the "good," standard algorithm, but if you're working with thousands of polygons, those floating point calculations will be too slow and will probably lead to round-off error at some point. Round-off error is a huge pain in computational geometry problems. The hard part is finding ways to avoid it. The trick is that you don't need to know the angle between the lines, you just need to know its sign, called the *circulation*. For every line AB in the polygon, form the triangle PAB and you want to know does it lie inside the polygon or not. That is, if you were riding a bike counterclockwise around the boundary of the polygon, would P lie on your left or your right when you crossed AB? You can find this by calculating PA x PB = (A.x-P.x)*(B.y-P.y) - (A.y-P.y)*(B.x-P.x). The circulation (the sign of PA x PB) can be found without doing a multiplication in many cases, but this is good enough. Remember, we've oriented the polygon so that you come to A before coming to B as your traverse its boundary. Then the algorithm is: In = 0 foreach edge AB in the polygon if A.y < P.y and B.y >= P.y and PA x PB > 0 In = In + 1 if A.y >= P.y and B.y < P.y and PA x PB < 0 In = In - 1 Then if In = 1, P is inside the polygon, and is outside if I = 0. This doesn't handle the case where P lies on some edge AB of the polygon. David Fry fry@math.harvard.edu Division of Applied Sciences fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138 - ---------- end of artile Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From Rick Wong Date: 16 Jun 1994 17:59:54 GMT Organization: Stanford University In article Yves Belanger, belanger@bach.ulaval.ca writes: > My problem is how to determine that a user has clicked inside one of > those polygon or the click was outside them all? One approach is to create an offscreen bitmap with its origin set up so that the bitmap is centered around the click locaction. The bitmap doesn't have to be very big at all, just enough for your hit tolerance. For each polygon you want to test, clear the bitmap, then draw the polygon into it (if you want to see if the point is inside the polygon, you should draw it with a black fill pattern). You can then examine the individual bits around the click location to see if any are set. Of course, such "cleverness" is unnecessary under QuickDraw GX.... --Rick Wong --------------------------- >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Subject: PowerPC load-store (was Re: Fast full screen scrolling: impossible?) Date: 15 Jun 1994 15:23:53 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article <1994Jun12.182803.1@west.cscwc.pima.edu> 103t_english@west.cscwc.pima.edu writes: > And finally, what happened to the load/store multiple instructions that are > (I assume?) faster on the 601, but will probably be slower "in future > implementations?" the load/store multiple instructions are not faster than a series of loads and stores (except perhaps if there are stalls from the instruction cache). they take 1 cycle per load or store. these instructions are present to make saving and restoring registers (GPRs only) to the stack a little bit easier. that's really the only benefit to them. many of the PowerPC architects do not like these instructions because they do not fit the RISC model very well, thus they complicate the processor implementation. don't expect IBM/Motorola to invest much time on these instructions. witness the lack of equivalent instructions for floating- point registers or for 64-bit GPRs. these instructions will become slower when they decide to eliminate them and handle them via trap-and-emulate. (hey, at least they're telling you all this up front) -gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Wed, 15 Jun 1994 20:34:44 GMT Organization: Adobe Systems Incorporated Gary Kacmarcik writes > the load/store multiple instructions are not faster than a series of loads > and stores (except perhaps if there are stalls from the instruction cache). > they take 1 cycle per load or store. Which will happen relatively often on the 601. (For example anytime you save 8 or more registers, its guaranteed to happen.) > these instructions are present to make saving and restoring registers > (GPRs only) to the stack a little bit easier. that's really the only benefit > to them. They improve code density somewhat. Given the size of native apps that's a concern. > many of the PowerPC architects do not like these instructions because they > do not fit the RISC model very well, thus they complicate the processor > implementation. don't expect IBM/Motorola to invest much time on these > instructions. witness the lack of equivalent instructions for floating- > point registers or for 64-bit GPRs. Bottom line: the architecture would be better without load/store multiple. However since the architects could not reach agreement to remove these instructions, the implementors should support them. As it stands now, some implementors will makes these instructions competitive and some won't. Applications developers will be stuck with a choice which way to go. For load/store multiple, this doesn't bother me that much. (One might take a minor speed hit to win on code space most places anyway.) However the manual says similar things about load/store update instructions vs. using a load/store and an add instruction. This causes a much bigger performance tradeoff right in the middle of your inner loops. A PowerPC implementation where the two instruction sequence is faster than an update form instruction would be braindead. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 `Wait a second! This is just an octahedron suspended in blue liquid.' - JT +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 16 Jun 1994 18:34:53 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article <1994Jun15.203444.3373@adobe.com> zstern@adobe.com (Zalman Stern) writes: > > Gary Kacmarcik writes > > these instructions are present to make saving and restoring registers > > (GPRs only) to the stack a little bit easier. that's really the only > > benefit to them. > > They improve code density somewhat. Given the size of native apps that's a > concern. but they don't affect code density all that much. the recommended way doing the load/store sequence of instructions is to have a series of loads (or stores) somewhere in the app or OS like lwz r13,0(r0) lwz r14,4(r0) ... lwz r31,68(r0) bcctr (or something like that - i believe that the standard save/restore glue does a few other things, but i don't have the exact sequence handy). then a function that wants to save a bunch of registers just calculates the address of where the first register should be saved and branches to appropriate lwz instruction. you have to do this anyway for floating- point and 64-bit reg's, so it's not a big deal. the end result is that if it's done this way, it won't have a big impact on code density. performance is basically to same too, since the branches (both of which are unconditional) are "free" and the glue code may already be in the i-cache (from previous functions). -gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Fri, 17 Jun 1994 04:23:38 +1200 (NZST) Organization: (none) platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes: > many of the PowerPC architects do not like these instructions because they > do not fit the RISC model very well, thus they complicate the processor > implementation. don't expect IBM/Motorola to invest much time on these > instructions. witness the lack of equivalent instructions for floating- > point registers or for 64-bit GPRs. > > these instructions will become slower when they decide to eliminate them > and handle them via trap-and-emulate. (hey, at least they're telling you > all this up front) That won't be too bad -- everyone sees it coming, and coming (fairly) soon, and if you're saving a number of registers the speed hit won't be *that* horrible (but horrible enough), and most people don't use it inside of tight loops, and it's no faster than the alternative anyway. The really, *really* horrible one will come when the "load with update" and "store with update" instructions get the trap-and-emulate treatment. For the non PPC-savvy folk, those instructions get used to implement the C constructs *++p and *--p (and *p++ and *p-- with a smart optomising compiler that can transform your code). They're used a *lot*, they're a big speed win on the 601 (less on the 603 and 604 if you don't mind tying up two units for a load and an addi in parallel becasue you've got nothing better to do with them), and they occur in speed-critical inner loops. -- Bruce --------------------------- >From efisch@cs.tamu.edu (Eric A Fisch) Subject: Q: Default button & Return key in Modeless Dialog Date: 16 Jun 1994 18:56:00 GMT Organization: Texas A&M Computer Science Department, College Station, TX I am working with modeless dialogs and am quite pleased with the results. I am having a problem defining a default button and making the return (or enter) key activate it. Right now, when the return key is pressed it is passed into the active editable text field. I do have the OK button at item number 1, but I am clearly missing something. Any thoughts? Thanks, Eric Fisch efisch@cs.tamu.edu +++++++++++++++++++++++++++ >From egurney@vcd.hp.com (Eddy J. Gurney) Date: Thu, 16 Jun 1994 20:01:29 GMT Organization: Hewlett-Packard VCD Eric A Fisch (efisch@cs.tamu.edu) wrote: >I am working with modeless dialogs and am quite pleased with the >results. I am having a problem defining a default button and making >the return (or enter) key activate it. Right now, when the return key >is pressed it is passed into the active editable text field. I do have >the OK button at item number 1, but I am clearly missing something. Any >thoughts? Yes. After calling IsDialogEvent() from your event loop and determining that this is an event for an open modeless dialog, you need to "pre-process" the event before passing it on to DialogSelect() and check for a "keyDown" or "autoKey" event when theEvent.message & charCodeMask is equal to the Enter or Return key and process it appropriately... being sure to NOT pass the event on to DialogSelect() afterwards. You need to do a similar thing anyway to catch Command-key equivalents, which DialogSelect() also just "pushes" through to TEKey... -- Eddy J. Gurney N8FPW Hewlett-Packard Company, Vancouver (USA!) Division egurney@vcd.hp.com #include "Failures are divided into two classes-- those who thought and never did, and those who did and never thought." John Charles Salak +++++++++++++++++++++++++++ >From dubois@primate.wisc.edu (Paul DuBois) Date: 16 Jun 1994 15:46:39 -0500 Organization: Castra Parvulorum >From article <2tq780$3i8@news.tamu.edu>, by efisch@cs.tamu.edu (Eric A Fisch): > I am working with modeless dialogs and am quite pleased with the > results. I am having a problem defining a default button and making > the return (or enter) key activate it. Right now, when the return key > is pressed it is passed into the active editable text field. I do have > the OK button at item number 1, but I am clearly missing something. Any > thoughts? You have to handle it yourself in a modeless dialog. -- Paul DuBois dubois@primate.wisc.edu --------------------------- >From apabla@hercules.cs.uregina.ca (jaime apablaza) Subject: Questions about Tmon? Date: Wed, 01 Jun 1994 03:19:37 GMT Organization: University of Regina How much does Tmon Pro cost and where can I order it from? I read in the faq that Tmon has a rather steep learning curve so I was wondering is that because the manual is rather cryptic. If so are there third party books on using Tmon? Email preferred. +++++++++++++++++++++++++++ >From hall_j@sat.mot.com (Joseph Hall) Date: Wed, 1 Jun 1994 05:42:03 GMT Organization: Motorola Inc., Satellite Communications Seems it was apabla@hercules.cs.uregina.ca (jaime apablaza) who said: >How much does Tmon Pro cost and where can I order it from? I read in the >faq that Tmon has a rather steep learning curve so I was wondering is >that because the manual is rather cryptic. If so are there third party >books on using Tmon? Email preferred. I'm not aware of any books on TMON (other than the fairly good documentation that comes with it), but at least TMON seems to have a future now. For a while it looked as if it had been dropped on the floor and left for dead. The current trend is STRONGLY toward Jasik's The Debugger, though. Obviously there is no TMON for PowerPC at this time. -- Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users Software Architect | a choice between the easy way and the right way. Gorca Systems Inc. | joseph@joebloe.maple-shade.nj.us (home) (on assignment) | (602) 732-2549 (work) Joseph_Hall-SC052C@email.mot.com +++++++++++++++++++++++++++ >From chewy@shell.portal.com (Paul F. Snively) Date: 1 Jun 1994 14:26:07 GMT Organization: tumbolia.com In article <1994Jun01.031937.138522@sue.cc.uregina.ca> apabla@hercules.cs.uregina.ca (jaime apablaza) writes: > How much does Tmon Pro cost and where can I order it from? I read in the > faq that Tmon has a rather steep learning curve so I was wondering is > that because the manual is rather cryptic. If so are there third party > books on using Tmon? Email preferred. I would mail, but others might want to read this, too... TMON Pro does have a significant learning curve, as does probably any reasonably capable object-level debugger on the Mac. The Mac is a complex beast itself; to create a debugger that can interact with heaps, resources, code, registers, etc. is difficult (says a guy who used to work at ICOM Simulations, Inc.) Having said that, here are my brief pointers for happiness in TMON Pro: 1) Whenever you have a TMON Pro window open, note the little square box in the upper right corner. It looks like a zoom box, and in a sense, it is: it will expand the window to show a variety of hidden (ugh) options for use in that window. 2) Learn--and I mean _really_ learn--TMON Pro's expression syntax. Easily 90% of the cool things that you can do with TMON involve non-trivial use of expressions. For example, TMON Pro's "Stack Crawl" window is just a Memory window with a moderately hairy expression used to crawl up the stack. There's an even hairier expression used to create a Memory window that gives the names of all of the windows in the current world (hairy to do because the titleHandle is at different offsets in b&w vs. color windows). In particular, make sure that you fully understand delayed vs. immediate evaluation. 3) Remember that TMON Pro does, in fact, have a command line. Command-space will open it. You may think, "but I hate command lines!" So do I, but it's the only way to do certain things in TMON Pro, e.g. type: "Step ´*LongPointer != Æ*LongPointer" (that is, step until the value at LongPointer changes). Like many old-hand TMON/TMON Pro users, I'm delighted to know that TMON Pro for the PowerMac is forthcoming. - --------------------------------------------------------------------- Paul F. Snively "Just because you're paranoid, it doesn't mean chewy@shell.portal.com that there's no one out to get you." +++++++++++++++++++++++++++ >From dshayer@netcom.com (David Shayer) Date: Wed, 1 Jun 1994 18:21:37 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) : > How much does Tmon Pro cost and where can I order it from? I read in the : > faq that Tmon has a rather steep learning curve so I was wondering is : > that because the manual is rather cryptic. If so are there third party : > books on using Tmon? Email preferred. TMON is a great low level debugger, I don't think its any harder to use than Macsbug, and it can certainly be easier to learn than Jasik. It comes with 2 manuals, a reference manual and a tutorial. I simply read the tutorial all the way thru, and did all the examples. It took about a week of working every evening. At the end, I was a TMON master. (Well ok, I'm pretty competent with TMON :-) There are no books I know of that explain how to use TMON. However, like all low level debuggers, if you don't know what's going on in the Mac's guts, you won't know what you're looking at. I highly recommend Scott Knaster's book, How to Write Mac Software. It actually does have some examples in TMON, but in TMON 2.8, which is very old. TMON 3.0 is available from APDA (800-282-2732) for $250. It suppoessedly has a few quirks on the PowerPC. Its been bought by a new company, which is doing a PPC upgrade, so hopefully we'll see a new version of TMON soon. +------------------------------------------------------------------------+ |David Shayer (415) 595-2523 | |Sentient Software / Symantec shayer@applelink.apple.com| |"They're not the best at what they do, Applelink: SHAYER | | but they're the only ones who do what they do." | +------------------------------------------------------------------------+ +++++++++++++++++++++++++++ >From roberts@insoftware.com (Robert Schwalbe) Date: Sat, 11 Jun 1994 09:53:24 -0800 Organization: IN SOFTWARE In article , dshayer@netcom.com (David Shayer) wrote: > TMON 3.0 is available from APDA (800-282-2732) for $250. > It suppoessedly has a few quirks on the PowerPC. Its been bought > by a new company, which is doing a PPC upgrade, so hopefully we'll > see a new version of TMON soon. What is the name of this 'new' company, and how would we get in contact with them? ====================================================================== Robert Schwalbe INET: roberts@insoftware.com IN SOFTWARE Voice: 619.743.7502 2403 Conway Drive Fax: 619.743.7503 Escondido, CA 92026 +++++++++++++++++++++++++++ >From dshayer@netcom.com (David Shayer) Date: Wed, 15 Jun 1994 05:03:14 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Robert Schwalbe (roberts@insoftware.com) wrote: : In article , dshayer@netcom.com (David : Shayer) wrote: : > TMON 3.0 is available from APDA (800-282-2732) for $250. : > It suppoessedly has a few quirks on the PowerPC. Its been bought : > by a new company, which is doing a PPC upgrade, so hopefully we'll : > see a new version of TMON soon. : What is the name of this 'new' company, and how would we get in : contact with them? The new "company" is really one guy, named Allan Foster. You can reach him at afcguru@aol.com. David --------------------------- >From cconstan@epdiv1.env.gov.bc.ca (Carl B. Constantine) Subject: Saving PICT files - Here's CODE!! Date: Thu, 16 Jun 1994 07:10:55 -0700 Organization: Ministry of Environment, Lands & Parks Here is some code that works for saving PICT files. This code was developed by a friend of mine, I'm not the author. Here you go. OK, I have working code for writing a PICT file from a mac Picture. The trick is to write the fields of the Picture in the proper order. Write 512 zeros, for conformity with old PICT files & MacDraw. Then write the picture size, the picture rect, and finally the picture opcodes. PicHandle macPicture; static Point SFPwhere = { 150, 150 }; static SFReply reply; void MakePICTFile () { OSErr iErr; int iFileRef; CQDProcs myProcs; int longZero, i; long longCount = 1; Rect pFrame; PicHandle newPICTHand; short globalRef; Rect temp; int tempSize; SFPutFile ( SFPwhere, "\pSave PICT Plot as:","\pSaved PICT Plot",NULL,&reply); if (reply.good) { PleaseWait (); /* change to watch cursor */ ExerciseOffScreen (); /* draw pict in off-screen bitmap */ iErr = Create ( reply.fName, reply.vRefNum, 'MKGW', 'PICT' ); /* create file */ if (iErr != 0) { puts("Error - could not create file\n"); return; } iErr = FSOpen ( reply.fName, reply.vRefNum, &globalRef ); /* open file */ for ( i = 1; i<= 512; i++) /* write 512 zeros for conformity to standard */ FSWrite (globalRef, &longCount, 0); longCount = 2; /* write picture size */ tempSize = (*macPicture)->picSize; FSWrite (globalRef, &longCount, &tempSize); longCount = 8; /* write picture rect */ temp = (*macPicture)->picFrame; FSWrite (globalRef, &longCount, &temp); /* write picture */ longCount = GetHandleSize ((Handle) macPicture); FSWrite (globalRef, &longCount, (Ptr) (*macPicture)+10); /* picture starts 10 bytes from beginning address */ FSClose (globalRef); } } Good luck! -- ========================================================================= Carl B. Constantine B.C. Environment, Lands & Parks End-User Support Analyst CCONSTAN@epdiv1.env.gov.bc.ca PGP Key available if you finger: CCONSTAN@EUSACBC.env.gov.bc.ca --------------------------- >From nhodulik@hypnos.norden1.com (Nick Hodulik) Subject: Scroll Bars in DLOG? Date: 6 Jun 1994 03:52:22 GMT Organization: Norden 1 Communications How does one make scroll bars work in a DLOG resource? I know it has something to do with the CNTL resource, but I can't figure it out. Please help me! Nick -- *-----------------------*------------------------------------*---------------* |nhodulik@norden1.com | "This train | *------* | |Norden1 Communications | is bound | \ GO / | |Nick Hodulik | for glory..." | TITANS! | |Toledo, OH | -Indigo Girls | \/ | \/ | *-----------------------*------------------------------------*---------------* +++++++++++++++++++++++++++ >From Alex Kac Date: Sat, 18 Jun 94 12:57:50 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Nick Hodulik writes: >How does one make scroll bars work in a DLOG resource? I know it has something >to do with the CNTL resource, but I can't figure it out. Please help me! > >Nick Ok...here is some ol PASCAL source for you (easier to read) FUNCTION NewDlogFilter (theDialog: DialogPtr; VAR theEvent: EventRecord; VAR itemhit: integer): boolean; first, you need to use a ModalDialogFilter (if you're using a modaldialog) BEGIN setport(theDialog); IF (theEvent.what = update) AND (WindowPtr(theevent.message) <> theDialog) & (WindowPeek(WindowPtr(theEvent.message))^.windowkind = dlog) THEN UpdtDialog(theDialog, (WindowPeek(WindowPtr(theEvent.message))^.updateRGN)) ELSE IF (theEvent.what = activate) AND (DialogPtr(theEvent.message) <> theDialog) THEN {Deactivate any window behind....} ELSE CASE theEvent.what OF ...do key stuff here.... M_Down: BEGIN hitPt := theEVENT.where; GlobalToLocal(hitPt); Ahit := FindControl(hitPt, theDialog, hitControl); IF NOT (hitControl = NIL) THEN BEGIN dhit := FindDitem(theDialog, hitpt) + 1; GetDitem(theDialog, dhit, itemtype, itemhandle, itemrect); {here I could have put a contrlAction in each of the 3 controls before I started the Dialog, but thought this was the best way} CASE Ahit OF inButton: BEGIN CASE itemtype OF 4..6: Ahit := TrackControl(hitControl, hitpt, NIL); 7: Ahit := TrackControl(hitCOntrol, hitpt, Pointer(-1)); {since this is a button, it can only be a PopUpMenu...} OTHERWISE ; END; CASE dhit OF ...buttons and other stuff here.... inUpButton: IF NOT (TrackControl(hitControl, hitpt, @UpButtonProc) = 0) THEN BEGIN NewDlogFilter := true; itemhit := dhit; END; inDownButton: IF NOT (TrackControl(hitControl, hitpt, @DownButtonProc) = 0) THEN BEGIN NewDlogFilter := true; itemhit := dhit; END; inThumb: IF NOT (TrackControl(hitControl, hitpt, NIL) = 0) THEN BEGIN ChangeBut(hitcontrol, theDialog); NewDlogFilter := true; itemhit := dhit; END; OTHERWISE ; END; END; END; {end of MDown} By! --------------------------- >From mburch@ksu.ksu.edu (Matt Burch) Subject: Why should't you move baseAddrs? Date: 15 Jun 1994 18:19:52 -0500 Organization: Kansas State University Forgive me for sounding obtuse, but what excactly is wrong with moving around baseAddrs? What's to prevent you from creating, say, a GWorld or other offscreen pixmap with the same dimensions and depth as the screen, and then setting the screen's baseAddr to the baseAddr of the buffer when you want to draw a frame, instead of blasting it into video memory? Am I missing something here? Probably. - Matt Burch +++++++++++++++++++++++++++ >From kbell@cs.utexas.edu (Kevin Bell) Date: Wed, 15 Jun 1994 23:30:38 -0600 Organization: The University of Texas at Austin, Austin, Texas In article <2to2ao$o4k@matt.ksu.ksu.edu>, mburch@ksu.ksu.edu (Matt Burch) wrote: > Forgive me for sounding obtuse, but what excactly is wrong with > moving around baseAddrs? What's to prevent you from creating, say, > a GWorld or other offscreen pixmap with the same dimensions and > depth as the screen, and then setting the screen's baseAddr to > the baseAddr of the buffer when you want to draw a frame, instead > of blasting it into video memory? Am I missing something here? > Probably. > > - Matt Burch The reason is that PixMaps are a QuickDraw software data structure, which has little relation to the underlying video hardware. So if you change the screen's baseAddr, QuickDraw commands will draw to the new port (if it doesn't crash, I've never tried this), but the video hardware will continue to fetch screen data from the old address. -- Kevin Bell kbell@cs.utexas.edu --------------------------- >From valentin+@pitt.edu (Shawn V. Hernan) Subject: cntl-opt-esc Date: 14 Jun 1994 00:19:12 GMT Organization: The University of Pittsburgh Greetings all, Once again, I turn to the wisdom of the net... Is there any way to programatically intercept the cnt-alt-esc keysequence? You know, the one that asks you if you really want to force such and such to quit. I thought this was an AppleEvent, but apparantly not.... Is this a FAQ? Do I have to resort to testing for that in my keyDown events? Any help is deeply appreciated, Thanks, Shawn Shawn Valentine Hernan |Is the War on Drugs worth it? The University of Pittsburgh |Why does the government want your guns? valentin+@pitt.edu |Does RICO ring a bell? 412-624-6425 |Did you vote in the last election? +++++++++++++++++++++++++++ >From Steve Maller Date: 14 Jun 1994 19:39:26 GMT Organization: General Magic In article <2tit20$59e@usenet.srv.cis.pitt.edu> Shawn V. Hernan, valentin+@pitt.edu writes: > Is there any way to programatically intercept the cnt-alt-esc >keysequence? You know, the one that asks you if you really want to >force such and such to quit. I thought this was an AppleEvent, but >apparantly not.... > >Is this a FAQ? Do I have to resort to testing for that in my keyDown >events? No dice. It's a pretty low level system patch (to PostEvent, I think) so you'd have to patch PostEvent yourself and filter it out. - --------------------------------------------------------------- Steve Maller Husband & Father General Magic, Inc. +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 14 Jun 1994 15:33:11 -0700 Organization: SRI International, Menlo Park, CA In article <2tl11e$lu0@gatekeep.genmagic.com> Steve Maller writes: >In article <2tit20$59e@usenet.srv.cis.pitt.edu> Shawn V. Hernan, >valentin+@pitt.edu writes: >> Is there any way to programatically intercept the cnt-alt-esc >>keysequence? You know, the one that asks you if you really want to >>force such and such to quit. I thought this was an AppleEvent, but >>apparantly not.... >> >>Is this a FAQ? Do I have to resort to testing for that in my keyDown >>events? Here you go from the up and coming UMPG volume II. (yes I'm actually working on it) Subject: No Option Escape code From: Manuel Veloso Distribution: world Someone a while back wanted code for killing off Force-Quit. Well, here's one I found on CIS (I think) a few weeks ago. It works(!). It's in MPW assembly, but 95% of it is the generic init install/patch. For anyone doing standalone systems (kiosks), well, you know... ; NoEscape.a include 'Traps.a' machine mc68000 case obj INITEntry proc export lea EndPatch,a0 lea StartPatch,a1 sub.l a1,a0 move.l a0,d0 move.l a0,d3 _NewPtr sys move.l a0,d4 beq.s NoPatch move.l a0,a1 lea StartPatch,a0 move.l d3,d0 _BlockMove move.w #$a9c9,d0 _GetTrapAddress newTool lea RealSysError,a1 move.l a0,(a1) move.w #$a9c9,d0 move.l d4,a0 _SetTrapAddress newTool NoPatch rts StartPatch cmpi.w #$4e22,d0 beq.s NoThanks move.l RealSysError,-(sp) NoThanks rts RealSysError ds.l 1 EndPatch equ * endp end -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From Greg_Marriott@genmagic.com (Greg Marriott) Date: Wed, 15 Jun 1994 06:21:07 -0800 Organization: General Magic, Inc. Steve Maller wrote: > valentin+@pitt.edu writes: > > Is there any way to programatically intercept the cnt-alt-esc > >keysequence?> > No dice. It's a pretty low level system patch (to PostEvent, I think) > so you'd have to patch PostEvent yourself and filter it out. Or you could patch SysError and intercept the dialog just before it comes up, pretending the user hit cancel. -- Greg Marriott Just Some Guy General Magic, Inc. Disclaimer: My opinions are not necessarily the same as General Magic's. (can a company even HAVE an opinion?) +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Wed, 15 Jun 1994 16:14:42 GMT Organization: Apple Computer, Inc. In article Greg Marriott, Greg_Marriott@genmagic.com writes: >Steve Maller wrote: >> valentin+@pitt.edu writes: >> > Is there any way to programatically intercept the cnt-alt-esc >> >keysequence?> >> No dice. It's a pretty low level system patch (to PostEvent, I think) >> so you'd have to patch PostEvent yourself and filter it out. > >Or you could patch SysError and intercept the dialog just before it comes >up, pretending the user hit cancel. SysError(20002) is how force-quit happens. As Greg said, just patch it to just RTS when the error code is 20002, otherwise call through. -Dave Falkenburg -Apple Computer, Inc. --------------------------- >From fadushin@top.cis.syr.edu (Fred Dushin) Subject: scroll bars in modal dialogs Date: Thu, 16 Jun 1994 15:44:22 GMT Organization: Syracuse University, CIS Dept. >From what I gather from Inside Mac (old volume I and Toolbox Essentials), I need to handle mouseDown events in scroll bars in modal dialogs with a filter proc. I.e., ModalDialog does not return the part code for the control, just the controlID. Is that so? If so, does someone have a sample filter procedure that handles scroll bars I can scavange from? Braaa. Fred Dushin Syracuse, NY +++++++++++++++++++++++++++ >From Here@There (Someone) Date: 17 Jun 1994 16:47:46 GMT Organization: Large Fuzzy Room In article <1994Jun16.154422.1710@newstand.syr.edu>, fadushin@top.cis.syr.edu (Fred Dushin) wrote: > Is that so? If so, does someone have a sample filter procedure > that handles scroll bars I can scavange from? Braaa. DialogBits 2.0.1 does this, it's on the DevCD and the ftp site. Here's the relevant code from the filter proc that tracks the scroll control............. // cut and paste into MPW to view right // inside your filter proc GetDItem(inputDialog, kScrollControlItem, &tempItem, &tempHandle, &tempRect); if (PtInRect(mousePoint, &tempRect)) { /* We're in the scroll bar. */ /* Now, what does that mean???? */ /* Well, the Dialog Manager will automatically call FindControl and TrackControl */ /* and set the control value (in the case of scroll thumbs) */ /* on controls added to your dialog, and in many cases that's all you're going */ /* to need. */ /* But, ModalDialog does NOT pass back a part code, so if the userPerson */ /* clicked on the thumb or arrows of the scroll bar, you won't know, you'll */ /* just know that the scroll bar was clicked in.*/ /* That's not enough, so we'll to an initial check to see where the control */ /* was hit */ thePart = FindControl(mousePoint, inputDialog, &returnedControl); /* if the hit was in an arrow or page area, we'll handle it ourselfs */ if (thePart != inThumb) { TrackControl(returnedControl, mousePoint, (ProcPtr)DoScrollArrows); returnVal = true; } /* if it was in the thumb, we'll just fall through and let the Dialog Manager */ /* handle it for us */ } /* This little routine adjusts the scroll bar during TrackControl */ pascal void DoScrollArrows(ControlHandle theControl, short thePart) { short currentVal = GetCtlValue(theControl); short offSet = 0; switch (thePart) { case inUpButton: offSet = -1; break; case inDownButton: offSet = 1; break; case inPageUp: offSet = -3; break; case inPageDown: offSet = 3; break; } /* set the control value to the new one, as long as it doesn't pass limits */ currentVal += offSet; if (currentVal < 1) currentVal = 1; if (currentVal > 10) currentVal = 10; SetCtlValue(theControl, currentVal); } /* end DoScrollArrows */ Somewhere, sometime SPA FON --------------------------- End of C.S.M.P. Digest **********************