home *** CD-ROM | disk | FTP | other *** search
/ ftp.mactech.com 2010 / ftp.mactech.com.tar / ftp.mactech.com / csmpdigest / csmp-digest-v3-078 < prev    next >
Text File  |  2010-09-21  |  64KB  |  1,672 lines

  1. Received-Date: Fri, 6 Jan 1995 14:55:16 +0100
  2. From: pottier@clipper.ens.fr (Francois Pottier)
  3. Subject: csmp-digest-v3-078
  4. To: csmp-digest@ens.fr
  5. Date: Fri, 6 Jan 1995 14:55:12 +0100 (MET)
  6. X-Mailer: ELM [version 2.4 PL23]
  7. Mime-Version: 1.0
  8. Content-Type: text/plain; charset=ISO-8859-1
  9. Content-Transfer-Encoding: 8bit
  10. Errors-To: listman@ens.fr
  11. Reply-To: pottier@clipper.ens.fr
  12. X-Sequence: 84
  13.  
  14. C.S.M.P. Digest             Fri, 06 Jan 95       Volume 3 : Issue 78
  15.  
  16. Today's Topics:
  17.  
  18.         64-bit math: "Int64Bit"? "comp"? "wide"? wtf??
  19.         Accessing &qd.arrow from a Power PC code resource?
  20.         How do I output a hairline line to the printer?
  21.         Introduction to object-oriented programming?
  22.         Memory management in C ?
  23.         Recordable applications
  24.         Transparent PICTs?
  25.  
  26.  
  27.  
  28. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  29. (pottier@clipper.ens.fr).
  30.  
  31. The digest is a collection of article threads from the internet newsgroup
  32. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  33. regularly and want an archive of the discussions.  If you don't know what a
  34. newsgroup is, you probably don't have access to it.  Ask your systems
  35. administrator(s) for details.  If you don't have access to news, you may
  36. still be able to post messages to the group by using a mail server like
  37. anon.penet.fi (mail help@anon.penet.fi for more information).
  38.  
  39. Each issue of the digest contains one or more sets of articles (called
  40. threads), with each set corresponding to a 'discussion' of a particular
  41. subject.  The articles are not edited; all articles included in this digest
  42. are in their original posted form (as received by our news server at
  43. nef.ens.fr).  Article threads are not added to the digest until the last
  44. article added to the thread is at least two weeks old (this is to ensure that
  45. the thread is dead before adding it to the digest).  Article threads that
  46. consist of only one message are generally not included in the digest.
  47.  
  48. The digest is officially distributed by two means, by email and ftp.
  49.  
  50. If you want to receive the digest by mail, send email to listserv@ens.fr
  51. with no subject and one of the following commands as body:
  52.     help                        Sends you a summary of commands
  53.     subscribe csmp-digest Your Name    Adds you to the mailing list
  54.     signoff csmp-digest            Removes you from the list
  55. Once you have subscribed, you will automatically receive each new
  56. issue as it is created.
  57.  
  58. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  59. Questions related to the ftp site should be directed to
  60. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  61. digest are available there.
  62.  
  63. Also, the digests are available to WAIS users.  To search back issues
  64. with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
  65. http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.
  66.  
  67.  
  68. -------------------------------------------------------
  69.  
  70. >From first.ascent@mindlink.bc.ca (Alex Curylo)
  71. Subject: 64-bit math: "Int64Bit"? "comp"? "wide"? wtf??
  72. Date: 22 Dec 1994 11:18:01 GMT
  73. Organization: First Ascent
  74.  
  75. So I need to port this 64-bit integer math library from handcrafted
  76. Windows assembly code (yuck! ptoo!), so I went looking for what kind of
  77. Toolbox support there is for 64-bit integers, and I'm all confused now.
  78.  
  79. 1) LongMul() multiplies two longs into a signed "Int64Bit". This
  80. appears to be the only place in the known universe that this type
  81. appears.
  82.  
  83. 2) SANE has the signed "comp" type. But it seems to be short on things
  84. to do with it, you seem to have to convert to extended to do much
  85. interesting. Unless I'm missing something.
  86.  
  87. 3) CodeWarrior's Types.h includes the perfect-appearing "wide" and
  88. "UnsignedWide" types. But I've never heard of these, and they don't
  89. appear in my Symantec or MPW Types.h, or anywhere else obvious.
  90. Hmmmmmm.
  91.  
  92. Can somebody tell me how all this fits together, and what the best way
  93. to do 64-bit integer math is?
  94.  
  95. +++++++++++++++++++++++++++
  96.  
  97. >From ensign@xmission.com (Ensign.CustSupport)
  98. Date: 22 Dec 1994 07:13:21 -0700
  99. Organization: XMission Public Access Internet (801-539-0900)
  100.  
  101.  
  102. Try looking at the PowerPC manual "IM PowerPC Numerics." It should offer 
  103. some help.
  104. I believe that "comp" was converted to "extended" on a 68K machine and 
  105. that the 68K machine was most efficient while using "extended." But that 
  106. is not the way it is on the PowerMac. Doubles are used extensively on the 
  107. PowerMac and "wide" will need a separate math library all its own. If 
  108. somebody knows of a "wide" library of functions, other than what is 
  109. already given, I would like to know about it.
  110.  
  111. Norman Parker
  112. ensign@xmission.com
  113.  
  114. Alex Curylo 
  115. (first.ascent@mindlink.bc.ca) wrote:
  116. : So I need to port this 64-bit integer math library from handcrafted
  117. : Windows assembly code (yuck! ptoo!), so I went looking for what kind of
  118. : Toolbox support there is for 64-bit integers, and I'm all confused now.
  119.  
  120. : 1) LongMul() multiplies two longs into a signed "Int64Bit". This
  121. : appears to be the only place in the known universe that this type
  122. : appears.
  123.  
  124. : 2) SANE has the signed "comp" type. But it seems to be short on things
  125. : to do with it, you seem to have to convert to extended to do much
  126. : interesting. Unless I'm missing something.
  127.  
  128. : 3) CodeWarrior's Types.h includes the perfect-appearing "wide" and
  129. : "UnsignedWide" types. But I've never heard of these, and they don't
  130. : appear in my Symantec or MPW Types.h, or anywhere else obvious.
  131. : Hmmmmmm.
  132.  
  133. : Can somebody tell me how all this fits together, and what the best way
  134. : to do 64-bit integer math is?
  135.  
  136. +++++++++++++++++++++++++++
  137.  
  138. >From ax52@cityscape.co.uk (Giuliano Gavazzi)
  139. Date: 22 Dec 1994 20:39:04 GMT
  140. Organization: CityScape Internet Sevices
  141.  
  142. In article <3dc1i1$fs0@xmission.xmission.com>, ensign@xmission.com
  143. (Ensign.CustSupport) wrote:
  144.  
  145. > Try looking at the PowerPC manual "IM PowerPC Numerics." It should offer 
  146. > some help.
  147. ...
  148. > Norman Parker
  149. > ensign@xmission.com
  150. > Alex Curylo 
  151. > (first.ascent@mindlink.bc.ca) wrote:
  152. ...
  153. > : Can somebody tell me how all this fits together, and what the best way
  154. > : to do 64-bit integer math is?
  155.  
  156. to my knowledge "IM PowerPC Numerics" tells only about floating
  157. point types. I am also interested in 64 bit integer math, and thus repeat:
  158. is there a way to di it without going to assembler or defining a new class.
  159.  
  160. Giuliano Gavazzi
  161.  
  162. +++++++++++++++++++++++++++
  163.  
  164. >From Jens Alfke <jens_alfke@powertalk.apple.com>
  165. Date: Thu, 22 Dec 1994 19:00:48 GMT
  166. Organization: Apple Computer
  167.  
  168. Alex Curylo, first.ascent@mindlink.bc.ca writes:
  169. > 3) CodeWarrior's Types.h includes the perfect-appearing "wide" and
  170. > "UnsignedWide" types. But I've never heard of these, and they don't
  171. > appear in my Symantec or MPW Types.h, or anywhere else obvious.
  172. > Hmmmmmm.
  173.  
  174. These are used by the wide math routines for PowerPC, defined in FixMath.h.
  175. Unfortunately these routines only exist on PowerMacs. However, I believe
  176. they're not too hard to implement on 68020 and higher...
  177.  
  178. --Jens Alfke                           jens_alfke@powertalk.apple.com
  179.                    "A man, a plan, a yam, a can of Spam ... Bananama!"
  180.  
  181. ---------------------------
  182.  
  183. >From dpbsmith@world.std.com (Daniel P. B. Smith)
  184. Subject: Accessing &qd.arrow from a Power PC code resource?
  185. Date: Thu, 8 Dec 1994 02:58:43 GMT
  186. Organization: The World Public Access UNIX, Brookline, MA
  187.  
  188. I'm tinkering with a Mac code resource, which is a kind of "plug-in"
  189. for an application.  It is a "fat" resource that contains both 68K and
  190. PPC code versions.  I'm trying to arrange for an hourglass cursor to
  191. appear during a time-consuming operation.  I have no problem with
  192. SetCursor(GetCursor(watchCursor)), but I can't quite figure out how
  193. to get it back to being an arrow.  In the 68K code you'd use
  194. SetCursor(&qd.arrow) (I'm typing this from memory, away from my reference
  195. material so if it's really SetCursor(qd.arrow) or SetCursor(qd->arrow)
  196. don't flame me), but it's not clear how you can get at the QuickDraw
  197. globals in a PPC code resource.  Inside Mac seems to suggest that you
  198. choose any little chunk of memory to be the QuickDraw global area and
  199. you MAKE it the QuickDraw global area when you call InitGraf.  All
  200. well and good, but it's the _main application_ that does that, not me!
  201. (And I don't have source, or even object code, for the main application).
  202.  
  203. >From a PowerPC code resource, how can I get to either a) an arrow cursor
  204. resource, or b) the QuickDraw global area?  Is there anything more
  205. sensible to do than build my own cursor resource that just happens to
  206. look the same as the genuine arrow cursor and put it in a resource file?
  207.  
  208. -- 
  209. Daniel P. B. Smith
  210. dpbsmith@world.std.com
  211.  
  212. +++++++++++++++++++++++++++
  213.  
  214. >From bobschaaf@aol.com (Bobschaaf)
  215. Date: 9 Dec 1994 20:55:19 -0500
  216. Organization: America Online, Inc. (1-800-827-6364)
  217.  
  218. In article <D0H1Lv.AB3@world.std.com>, dpbsmith@world.std.com (Daniel P.
  219. B. Smith) writes:
  220.  
  221. >I have no problem with
  222. >SetCursor(GetCursor(watchCursor)), but I can't quite figure out how
  223. >to get it back to being an arrow.
  224.  
  225. Just call InitCursor().
  226. The only problem would be that is resets ths cursor level to 0.
  227.  
  228. >From Phoenix,
  229. Bob Schaaf
  230.  
  231. +++++++++++++++++++++++++++
  232.  
  233. >From Chris Watson <cwatson@cam.org>
  234. Date: 12 Dec 1994 20:53:27 GMT
  235. Organization: -
  236.  
  237. In article <3cb1q7$a8f@newsbf01.news.aol.com> Bobschaaf,
  238. bobschaaf@aol.com writes:
  239. >In article <D0H1Lv.AB3@world.std.com>, dpbsmith@world.std.com (Daniel P.
  240. >B. Smith) writes:
  241. >
  242. >>I have no problem with
  243. >>SetCursor(GetCursor(watchCursor)), but I can't quite figure out how
  244. >>to get it back to being an arrow.
  245. >
  246. >Just call InitCursor().
  247. >The only problem would be that is resets ths cursor level to 0.
  248.  
  249.  
  250. Perhaps I do not understand fully what you are trying to do, but to set
  251. the cursor to the standard arrow, just use:
  252.  
  253. SetCursor (&qd.arrow);
  254.  
  255. This is how I do it in my program, and it works on 68k and ppc....
  256.  
  257. Sorry if I misunderstood; good luck.
  258.  
  259. +++++++++++++++++++++++++++
  260.  
  261. >From Jens Alfke <jens_alfke@powertalk.apple.com>
  262. Date: Thu, 22 Dec 1994 19:28:16 GMT
  263. Organization: Apple Computer
  264.  
  265. Chris Watson, cwatson@cam.org writes:
  266. > Perhaps I do not understand fully what you are trying to do, but to set
  267. > the cursor to the standard arrow, just use:
  268. > SetCursor (&qd.arrow);
  269. > This is how I do it in my program, and it works on 68k and ppc....
  270.  
  271. It works fine if your code originally called InitGraf, so the QD globals are
  272. living in your "qd" global variable. If you didn't, i.e. you are a code
  273. resource or shared lib, you can't do this.
  274. The way to do it is to use the fact that the longword at A5 is a pointer to
  275. the variable qd.thePort; by dereferencing A5 and subtracting the appropriate
  276. offset -- sizeof(QDGlobals) - sizeof(GrafPtr) -- you can recover a pointer to
  277. the globals. I have a snippet that does this but I can't find it right now...
  278. Yes, this works even on PPC. Even PowerMacs have A5 worlds, and calling
  279. LMGetCurrentA5 will get you the current A5 value.
  280.  
  281. --Jens Alfke                           jens_alfke@powertalk.apple.com
  282.                    "A man, a plan, a yam, a can of Spam ... Bananama!"
  283.  
  284. ---------------------------
  285.  
  286. >From clarrob@wwc.edu (Robert LaVerne Clark)
  287. Subject: How do I output a hairline line to the printer?
  288. Date: 19 Dec 1994 11:46:30 -0800
  289. Organization: Walla Walla College, College Place, WA
  290.  
  291. How can I draw a hairline-width line to the
  292. printer? I'm successfully drawing a one-pixel-
  293. wide line, but that's too big and fat for my
  294. purposes.
  295.  
  296. Any ideas?
  297.  
  298. --Bob Clark (clarrob@wwc.edu)
  299.  
  300.  
  301. +++++++++++++++++++++++++++
  302.  
  303. >From kenlong@netcom.com (Ken Long)
  304. Date: Mon, 19 Dec 1994 21:42:05 GMT
  305. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  306.  
  307. Robert LaVerne Clark (clarrob@wwc.edu) wrote:
  308. : How can I draw a hairline-width line to the
  309. : printer? I'm successfully drawing a one-pixel-
  310. : wide line, but that's too big and fat for my
  311. : purposes.
  312.  
  313. This was all covered (I believe) in an earlier c.s.m.p.  If you consult 
  314. the digests from volume 3 you'll probably find it.
  315.  
  316. I'd say, off hand, it depends on the printer.  Screen resolution is 
  317. usually 72 dpi.  A StyleWriter is 360 dpi, which is 1/5th sreen res.  
  318. Therefore, if the printer draws a pixel, the printed pixel is 25x25 jet 
  319. squirts.  The StyeWriter (I or II) has an adjustment for scale 
  320. percentage.  If I draw a 72 dpi line-art in Color It! and scale it up 
  321. 500%, then it will "smooth scale" it - which means it takes one pixel and 
  322. widens and fades (blurs) it out from the center of the pixel.  So the 
  323. center new pixel is black and it grayscales out 5 pixels in both 
  324. directions to the background color.
  325.  
  326. so, from white, 5 darker pixels to blak, then 5 lighter pixel back to 
  327. white, in both directions (h, v).
  328.  
  329. Then, I'll remove all but the black pixels and print it at 360 dpi.  The 
  330. result is a 72 dpi printout using 360 dpi pixels.  In other words, I 
  331. scale it up 5 times, remove all but the black pixels and print and all 
  332. the "pixel" sixes are 1/5th their original size on the page, or one jet 
  333. suirt wide.
  334.  
  335. But it seems you want to do this with only a portion of the printout.  True?
  336.  
  337. -Ken-
  338.  
  339. +++++++++++++++++++++++++++
  340.  
  341. >From scouten@metrowerks.com (Eric Scouten)
  342. Date: Mon, 19 Dec 1994 19:28:23 -0600
  343. Organization: metrowerks, inc.
  344.  
  345. Robert LaVerne Clark (clarrob@wwc.edu) wrote:
  346. : How can I draw a hairline-width line to the
  347. : printer? I'm successfully drawing a one-pixel-
  348. : wide line, but that's too big and fat for my
  349. : purposes.
  350.  
  351. To which kenlong@netcom.com (Ken Long) responded:
  352.  
  353.  [most of instructions deleted]
  354. > percentage.  If I draw a 72 dpi line-art in Color It! and scale it up 
  355. > 500%, then it will "smooth scale" it - which means it takes one pixel and 
  356. > widens and fades (blurs) it out from the center of the pixel.
  357.  
  358. I'm not sure, but I think you have misinterpreted the question. I'm
  359. assuming (since this is in c.s.m.programmer.help) that Robert is wishing
  360. to draw hairlines directly from his program, rather than from some
  361. graphics program. Given that interpretation, here's my answer:
  362.  
  363.  
  364. What you really need to know is the SetLineWidth PICT comment. It's a
  365. rather strange and awkward beast, but it's your only choice unless you
  366. want to write straight PostScript. The best description of it can be found
  367. in Tech Note PR12. If you have WWW access, you can find it at:
  368.  
  369.   http://www.info.apple.com/dev/technotes/Printing/pr_12.html
  370.  
  371. Basically it works something like this:
  372.  
  373.     Handle itsWidthPoint = NewHandle(sizeof (Point));
  374.     SetPt((Point *) *itsWidthPoint, 4, 1);
  375.     PicComment(SetLineWidth, sizeof(Point), itsWidthPoint);
  376.  
  377. >From this point on, until the next SetLineWidth comment, line widths are
  378. multiplied by 1/4 (or whatever values you plug into the SetPt command).
  379. This works equally well for QuickDraw printers (ImageWriter, StyleWriter,
  380. etc.) as PostScript (most LaserWriters).
  381.  
  382. Read the Tech Note *carefully* before using it; there are some rather
  383. strange caveats.
  384.  
  385. -es
  386.  
  387. __________________________________________________________________________
  388. Eric Scouten                                       Constructor Constructor
  389. scouten@metrowerks.com                                     Metrowerks, Inc.
  390.          **** ON VACATION Dec 21 - Jan 8: LIMITED NET ACCESS ****
  391.  
  392. I saw John Norstad with Elvis! And they were varnishing waffles!
  393.    -Peter Cohen <flargh@tiac.net>
  394.  
  395. +++++++++++++++++++++++++++
  396.  
  397. >From lawa@bbsrc.ac.uk (Andy Law (Big Nose))
  398. Date: 22 Dec 1994 11:14:40 GMT
  399. Organization: Roslin Institute
  400.  
  401.  
  402.   > Robert LaVerne Clark (clarrob@wwc.edu) wrote:
  403.   > : How can I draw a hairline-width line to the
  404.   > : printer? I'm successfully drawing a one-pixel-
  405.   > : wide line, but that's too big and fat for my
  406.   > : purposes.
  407.   > 
  408.  
  409. I think (but I've never done it so don't quote me) that you need to
  410. incorporate PictureComments into your drawing set up. There is one comment
  411. that scales the size of the line to be drawn. I seem to remember some
  412. discussion about problems with scaling in that different printers dealt
  413. with the situation differently, but there was some generalised solution to
  414. it all.
  415.  
  416. Try a WAIS search of the csmp archives to see if you can pull it out.
  417. -- 
  418. Andy Law
  419.  
  420. ( Lawa @ bbsrc.ac.uk                     Big Nose in Edinburgh )
  421.  
  422. ---------------------------
  423.  
  424. >From dimento@cs.tu-berlin.de (Christian Moskal)
  425. Subject: Introduction to object-oriented programming?
  426. Date: 17 Dec 1994 07:03:05 GMT
  427. Organization: Technical University of Berlin, Germany
  428.  
  429. Hello --
  430.  
  431. I am looking for a good introduction to basic principles of object oriented
  432. programming languages such as C++ for a friend of mine.
  433.  
  434. Any pointers will be greatly appreciated.
  435.  
  436.  
  437. Best
  438. -- Chris
  439.  
  440. -- 
  441. I'd rather learn from one bird how to sing
  442. than teach ten thousand stars how not to dance
  443.  
  444. +++++++++++++++++++++++++++
  445.  
  446. >From jim@MCS.COM (Reverend Jim Mines)
  447. Date: 17 Dec 1994 08:17:31 -0600
  448. Organization: The Church Of Digital Splendor
  449.  
  450. Christian Moskal (dimento@cs.tu-berlin.de) wrote:
  451. : Hello --
  452.  
  453. : I am looking for a good introduction to basic principles of object oriented
  454. : programming languages such as C++ for a friend of mine.
  455.  
  456. : Any pointers will be greatly appreciated.
  457.  
  458.  
  459. : Best
  460. : -- Chris
  461.  
  462. : -- 
  463. : I'd rather learn from one bird how to sing
  464. : than teach ten thousand stars how not to dance
  465.  
  466. --
  467.     I'm learning c++/oop with "Simple C++" by Jeffrey M. Cogswell 
  468. (ISBN #1-878739-44-1).
  469.     It's easy to read, but doesn't seem to insult me like the 
  470. 'dummies' books do.  It explains OOP very well, and I've never programmed 
  471. a thing in my life!!!
  472.  
  473.          Reverend Jim Mines (jim@mcs.com)
  474.     __///////\   The Church of Digital Splendor   /\\\\\\\__
  475.       \\\\\\\/  http://www.mcs.com/~jim/cds.html  \///////
  476.           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  477.  
  478. +++++++++++++++++++++++++++
  479.  
  480. >From stanleyr@acf4.nyu.edu (Rick Stanley)
  481. Date: 17 Dec 1994 16:16:16 GMT
  482. Organization: New York University
  483.  
  484. dimento@cs.tu-berlin.de (Christian Moskal) writes:
  485.  
  486. >Hello --
  487.  
  488. >I am looking for a good introduction to basic principles of object oriented
  489. >programming languages such as C++ for a friend of mine.
  490.  
  491. >Any pointers will be greatly appreciated.
  492.  
  493. Purchase a copy of the following book:
  494.  
  495. "Object-Oriented Analysis And Design, With Applications" 2nd edition
  496. Grady Booch, Author
  497. The Benjamin/Cummings Publishing Co., Inc.
  498. ISBN # 0-8053-5340-2
  499.  
  500. --
  501. Rick Stanley                         |              RSI
  502. stanleyr@acf4.nyu.edu                |         (212) 740-6600
  503. Information Technologies Institute   |        C++ & C Language
  504. New York University   NYC, NY  USA   | Programming, Training, Consulting
  505.  
  506. +++++++++++++++++++++++++++
  507.  
  508. >From pjl@graceland.att.com (Paul J. Lucas)
  509. Date: Sat, 17 Dec 1994 12:32:33 GMT
  510. Organization: AT&T
  511.  
  512. In <dimento-1712940815550001@130.149.1.104> dimento@cs.tu-berlin.de (Christian Moskal) writes:
  513.  
  514. >I am looking for a good introduction to basic principles of object oriented
  515. >programming languages such as C++ for a friend of mine.
  516.  
  517. >Any pointers will be greatly appreciated.
  518.  
  519.     There's the famous "What is" paper by Bjarne:
  520.  
  521.         Stroustrup, Bjarne.  "What is Object-Oriented
  522.             Programming?"  IEEE Software, vol. 5, May 1988,
  523.             pp. 10-20.
  524.  
  525.     The beginning of The C++ Programming Language also has a nice
  526.     explanation as well as a comparison with other methodologies.
  527.  
  528.     For a more general intorduction, there's also a book by Timothy
  529.     Budd -- blue book with a platypus on the cover...can't remember
  530.     the name.  Hopefully, somebody out there in net-land will know.
  531. --
  532.     - Paul J. Lucas
  533.       AT&T Bell Laboratories
  534.       Naperville, IL
  535.  
  536. +++++++++++++++++++++++++++
  537.  
  538. >From howardb@enlil.premenos.com (Howard Berkey)
  539. Date: 18 Dec 1994 02:09:14 GMT
  540. Organization: Premenos Corp.
  541.  
  542. In article <dimento-1712940815550001@130.149.1.104>,
  543. Christian Moskal <dimento@cs.tu-berlin.de> wrote:
  544. >Hello --
  545. >
  546. >I am looking for a good introduction to basic principles of object oriented
  547. >programming languages such as C++ for a friend of mine.
  548. >
  549. >Any pointers will be greatly appreciated.
  550. >
  551. >
  552.  
  553. A book I like is "Object oriented programming - An evolutionary
  554. approach" by Cox and Novbilsky.  It centers around objective C (the
  555. authors are/were principals of Stepstone) but it is applicable to any
  556. OO language.  It is not a book for beginning programmers, however.  It
  557. is pretty in-depth.
  558.  
  559. Also, Grady Booch has a book that everyone seems to like (the title
  560. escapes me, I don't own it).
  561.  
  562. Good luck,
  563.  
  564. -- 
  565. Howard Berkey                                     howardb@premenos.com
  566.                    Windows '95 == Macintosh '84        
  567.  
  568. +++++++++++++++++++++++++++
  569.  
  570. >From garyg@oak.circa.ufl.edu (gary greenberg)
  571. Date: 18 Dec 1994 03:21:19 GMT
  572. Organization: Center for Instructional and Research Computing Activities
  573.  
  574. In article <3d05ka$gqu@tortosa.templar.net>, howardb@enlil.premenos.com (Howard Berkey) writes:
  575. >In article <dimento-1712940815550001@130.149.1.104>,
  576. >Christian Moskal <dimento@cs.tu-berlin.de> wrote:
  577. >>Hello --
  578. >>
  579. >>I am looking for a good introduction to basic principles of object oriented
  580. >>programming languages such as C++ for a friend of mine.
  581. >>
  582. >>Any pointers will be greatly appreciated.
  583. >>
  584. >>
  585. >
  586. >A book I like is "Object oriented programming - An evolutionary
  587. >approach" by Cox and Novbilsky.  It centers around objective C (the
  588. >authors are/were principals of Stepstone) but it is applicable to any
  589. >OO language.  It is not a book for beginning programmers, however.  It
  590. >is pretty in-depth.
  591.  
  592. A basic yet excellent introduction to OO (using Smalltalk to illustrate the
  593. principles as explained) is:
  594. Concpts of Object-Oriented Programming by David N. Smith, McGraw-Hill, Inc.
  595. 1991. ISBN - 0-07-059177-6. I read this when I was thinking about learning
  596. to program, before I had ever even attempted to write a line of code. It helped
  597. convince me that this would be fun. Although I'm still a neophyte, and couldn't
  598. _yet_ find the errors in most posted code, I can say you'll enjoy this book &&
  599. get lot's out of it.
  600. btw, the programmer who recommended it to me has been a smalltalker for about
  601. 12 years and he used it for a class he taught to newbies.
  602.  
  603. Moreover, to all the wizards out there who donate their time to help us
  604. learn && enable us to "stand on the shoulders of those who came before"
  605.         Happy Holidays To ALL!!
  606. Cheers,
  607. gary
  608.  
  609. +++++++++++++++++++++++++++
  610.  
  611. >From AST@postman.hsn.no (Alf P. Steinbach)
  612. Date: Sun, 18 Dec 1994 05:58:58 GMT
  613. Organization: Nordland College
  614.  
  615. In article <3cv2sg$7o3@cmcl2.NYU.EDU> stanleyr@acf4.nyu.edu (Rick Stanley) writes:
  616. >Xref: news.uit.no comp.lang.c++:92640 comp.lang.misc:15178 comp.sys.mac.programmer:106665 comp.sys.mac.programmer.help:1188 comp.sys.newton.misc:20817 rec.arts.books:107462 rec.arts.books.marketplace:5041
  617. >Path: news.uit.no!trane.uninett.no!sunic!pipex!howland.reston.ans.net!math.ohio-state.edu!uwm.edu!rutgers!mcrcr6!cmcl2!acf4!stanleyr
  618. >Newsgroups: comp.lang.c++,comp.lang.misc,comp.sys.mac.programmer,comp.sys.mac.programmer.help,comp.sys.newton.misc,rec.arts.books,rec.arts.books.marketplace
  619. >Subject: Re: Introduction to object-oriented programming?
  620. >Message-ID: <3cv2sg$7o3@cmcl2.NYU.EDU>
  621. >From: stanleyr@acf4.nyu.edu (Rick Stanley)
  622. >Date: 17 Dec 1994 16:16:16 GMT
  623. >References: <dimento-1712940815550001@130.149.1.104>
  624. >Organization: New York University
  625. >NNTP-Posting-Host: acf4.nyu.edu
  626. >X-Newsreader: NN version 6.5.0 #5 (NOV)
  627. >Lines: 21
  628. >dimento@cs.tu-berlin.de (Christian Moskal) writes:
  629. >
  630. >>Hello --
  631. >
  632. >>I am looking for a good introduction to basic principles of object oriented
  633. >>programming languages such as C++ for a friend of mine.
  634. >
  635. >>Any pointers will be greatly appreciated.
  636. >
  637. >Purchase a copy of the following book:
  638. >
  639. >"Object-Oriented Analysis And Design, With Applications" 2nd edition
  640. >Grady Booch, Author
  641. >The Benjamin/Cummings Publishing Co., Inc.
  642. >ISBN # 0-8053-5340-2
  643. >
  644. >--
  645. >Rick Stanley                         |              RSI
  646. >stanleyr@acf4.nyu.edu                |         (212) 740-6600
  647. >Information Technologies Institute   |        C++ & C Language
  648. >New York University   NYC, NY  USA   | Programming, Training, Consulting
  649.  
  650. Also consider the original "Smalltalk-80:  the language and its 
  651. implementation" (Golberg & Robson, Addison Wesley) as supplementary
  652. literature  -  this book was my introduction to OOP, and it's great: much 
  653. info, discussion of the Smalltalk app framework, and historical interest.
  654.  
  655. For a main text, consider the Eiffel book:  it's very clear, very lucid,
  656. and covers high-level ideas and design issues as well as practical 
  657. techniques and the language support.  But what was the name of the book?
  658.  
  659. +++++++++++++++++++++++++++
  660.  
  661. >From bb@lightside.com (Bob Bradley)
  662. Date: Sat, 17 Dec 1994 22:51:45 -0800
  663. Organization: SS Software Inc.
  664.  
  665. The best book I've seen on Mac Object Programming is Element of C++
  666. Macintosh Programming by Dan Weston. It's a easy book to read that goes
  667. thru what you need to know to to use C++ on the Mac. It goes thru creating
  668. an Application and various Window classes to make a Mac application and
  669. more.
  670.  
  671. +++++++++++++++++++++++++++
  672.  
  673. >From brianm@csa.bu.edu (Brian Mancuso)
  674. Date: 18 Dec 1994 22:25:49 GMT
  675. Organization: Computer Science Department, Boston University, Boston, MA, USA
  676.  
  677. stanleyr@acf4.nyu.edu (Rick Stanley) writes:
  678. | dimento@cs.tu-berlin.de (Christian Moskal) writes:
  679. | Purchase a copy of the following book:
  680. | "Object-Oriented Analysis And Design, With Applications" 2nd edition
  681. | Grady Booch, Author
  682. | The Benjamin/Cummings Publishing Co., Inc.
  683. | ISBN # 0-8053-5340-2
  684.  
  685. I second this motion; this book tends to be the definitive
  686. introductory text to object-oriented programming methodologies. One of
  687. the key strengths of this book is the fact that it takes into
  688. consideration a significant number of the object-oriented styles that
  689. historically have been significant.
  690.  
  691. Brian Mancuso
  692.  
  693. | "Computation is the art of carefully throwing away information." |
  694.                     | Boston University Computer Science Dept. |
  695.                     | Tel: 617.352.8685 Net: brianm@cs.bu.edu  |
  696.                     | Pgp Public Key Avail. Member of the LPF. |
  697.  
  698. +++++++++++++++++++++++++++
  699.  
  700. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  701. Date: Mon, 19 Dec 1994 11:47:40 +0800
  702. Organization: Department of Computer Science, University of Western Australia
  703.  
  704. In article <AST.200.787730338@postman.hsn.no>, AST@postman.hsn.no (Alf P.
  705. Steinbach) wrote:
  706.  
  707. >For a main text, consider the Eiffel book:  it's very clear, very lucid,
  708. >and covers high-level ideas and design issues as well as practical 
  709. >techniques and the language support.  But what was the name of the book?
  710.  
  711. Well there's two...
  712.  
  713. "Object Oriented Software Construction"
  714.  
  715. ...and...
  716.  
  717. "Eiffel: The Language"
  718.  
  719. ... both by Betrand Meyer.  Both are very good IMHO.
  720. --
  721. Quinn "The Eskimo!"                   "Ah ha, the carnage begins!"
  722.  
  723. +++++++++++++++++++++++++++
  724.  
  725. >From zhou0024@eel.micro.umn.edu (CHENGCHEN   ZHOU)
  726. Date: Mon, 19 Dec 1994 22:17:09 GMT
  727. Organization: University of Minnesota, Minneapolis: Under Grad Workstation Lab.
  728.  
  729. In <3curtr$17u@Mars.mcs.com> jim@MCS.COM (Reverend Jim Mines) writes:
  730.  
  731. >Christian Moskal (dimento@cs.tu-berlin.de) wrote:
  732. >: Hello --
  733.  
  734. >: I am looking for a good introduction to basic principles of object oriented
  735. >: programming languages such as C++ for a friend of mine.
  736.  
  737. >: Any pointers will be greatly appreciated.
  738.  
  739.   I just bought the book titled "Design Patterns" by Gamma et.el,
  740.   it categorized certain OOD ideas and explained them using concerete examples.
  741.   I dislike the so called "OO methodology"s, but like this book.
  742.   "OOP should be a pratical discipline".
  743.  
  744.  
  745.   D. Yue 
  746.  
  747. +++++++++++++++++++++++++++
  748.  
  749. >From bw16@cornell.edu (Bretton Wade)
  750. Date: Mon, 19 Dec 1994 20:56:11 -0500
  751. Organization: Cornell Program of Computer Graphics
  752.  
  753. try this one out too:
  754.  
  755.    http://info.desy.de/gna/html/cc/index.html
  756.  
  757.  
  758. In article <dimento-1712940815550001@130.149.1.104>,
  759. dimento@cs.tu-berlin.de (Christian Moskal) wrote:
  760.  
  761. > Hello --
  762. > I am looking for a good introduction to basic principles of object oriented
  763. > programming languages such as C++ for a friend of mine.
  764. > Any pointers will be greatly appreciated.
  765.  
  766. _____________________________________________________________________
  767.  
  768.    Bretton Wade (bw16@cornell.edu)
  769.    http://www.graphics.cornell.edu/~bwade/
  770. _____________________________________________________________________
  771.  
  772. +++++++++++++++++++++++++++
  773.  
  774. >From Brian_Mancuso,brianm-csa.bu.edu,Internet@adbbs.antioch.edu (Brian Mancuso,brianm@csa.bu.edu,Internet)
  775. Date: 18 Dec 1994 22:25:49 GMT
  776. Organization: Apple Dayton User's Group's BBS
  777.  
  778. stanleyr@acf4.nyu.edu (Rick Stanley) writes:
  779. | dimento@cs.tu-berlin.de (Christian Moskal) writes:
  780. | Purchase a copy of the following book:
  781. | "Object-Oriented Analysis And Design, With Applications" 2nd edition
  782. | Grady Booch, Author
  783. | The Benjamin/Cummings Publishing Co., Inc.
  784. | ISBN # 0-8053-5340-2
  785.  
  786. I second this motion; this book tends to be the definitive
  787. introductory text to object-oriented programming methodologies. One of
  788. the key strengths of this book is the fact that it takes into
  789. consideration a significant number of the object-oriented styles that
  790. historically have been significant.
  791.  
  792. Brian Mancuso
  793.  
  794. | "Computation is the art of carefully throwing away information." |
  795.                     | Boston University Computer Science Dept. |
  796.                     | Tel: 617.352.8685 Net: brianm@cs.bu.edu  |
  797.                     | Pgp Public Key Avail. Member of the LPF. |
  798.  
  799. +++++++++++++++++++++++++++
  800.  
  801. >From "Alexander R¯dsten" <siv910111@vm.bi.no>
  802. Date: 21 Dec 1994 10:18:01 GMT
  803. Organization: UniNett
  804.  
  805. dimento@cs.tu-berlin.de (Christian Moskal) wrote:
  806. >
  807. > Hello --
  808. > I am looking for a good introduction to basic principles of object oriented
  809. > programming languages such as C++ for a friend of mine.
  810. > Any pointers will be greatly appreciated.
  811. > Best
  812. > -- Chris
  813. > -- 
  814. > I'd rather learn from one bird how to sing
  815. > than teach ten thousand stars how not to dance
  816.  
  817.  
  818. Suggestion: "OOP" P. Coad & J.Nicola,
  819.  Yourdon Press Computing Series, 1993
  820.  
  821. ---------------------------
  822.  
  823. >From fh3ar@aixterm1.urz.uni-heidelberg.de (Marc Steinbach)
  824. Subject: Memory management in C ?
  825. Date: 19 Dec 1994 10:35:25 -0600
  826. Organization: UTexas Mail-to-News Gateway
  827.  
  828. Hello,
  829. we're looking for an automatic memory management which is handled
  830. by a garbage collection and written in C for use in C-code.
  831. Especially for use with Apple Macs, Windows-based machines and
  832. Sun Sparc running under Solaris.
  833. Thanks for advice.
  834. marc
  835.  
  836. PS: Happy Christmas 
  837.  
  838.  
  839. +++++++++++++++++++++++++++
  840.  
  841. >From gdr11@cl.cam.ac.uk (Gareth Rees)
  842. Date: 20 Dec 1994 05:03:57 GMT
  843. Organization: U of Cambridge Computer Lab, UK
  844.  
  845. Marc Steinbach (fh3ar@aixterm1.urz.uni-heidelberg.de) writes:
  846. > We're looking for an automatic memory management which is handled by
  847. > garbage collection and written in C for use in C-code.
  848.  
  849. Such a beast can't be implemented as a portable C library for use by C
  850. code, because garbage collection is implementation specific.  Consider:
  851.  
  852. (1) How is the garbage collector to distinguish between pointers and
  853. other data, when it is marking/collecting the heap?  Compilers for
  854. languages with garbage collection must tag pointers in some way so as to
  855. make them distinctive.  A garbage collector for a C program must
  856. therefore have detailed knowledge of the structures in the heap so that
  857. it can trace them.
  858.  
  859. (2) How is the garbage collector going to identify pointers into the
  860. heap?  It has to examine the stack, all global variables, and any
  861. variables in registers.  Again, this depends upon detailed knowledge
  862. about the implementation of the compiler.
  863.  
  864. +++++++++++++++++++++++++++
  865.  
  866. >From Lars.Farm@nts.mh.se (Lars Farm)
  867. Date: Tue, 20 Dec 1994 16:20:00 +0100
  868. Organization: Mid Sweden University
  869.  
  870. In article <3d5ojt$omi@lyra.csx.cam.ac.uk>, gdr11@cl.cam.ac.uk (Gareth
  871. Rees) wrote:
  872.  
  873. > Marc Steinbach (fh3ar@aixterm1.urz.uni-heidelberg.de) writes:
  874. > > We're looking for an automatic memory management which is handled by
  875. > > garbage collection and written in C for use in C-code.
  876. >
  877. > Such a beast can't be implemented as a portable C library for use by C
  878. > code, because garbage collection is implementation specific.  Consider:
  879.  
  880. No? Check out Hans Bˆhms free GC at ftp.parc.xerox.com in /pub/gc.
  881.  
  882. I can't remember the list of supported machines, but it was long. On the
  883. Mac SC++ is supported. I made it work with MW++ (68K/4-byte int easy) It
  884. should be equaly simple to make it work for PPC. It requires a tiny little
  885. configuration specific support routine in PPC asm and I haven't tried that
  886. yet. One could probably start from the (supported) RS6000.
  887.  
  888. Lars
  889.  
  890. > (1) How is the garbage collector to distinguish between pointers and
  891. > other data, when it is marking/collecting the heap?  Compilers for
  892. > languages with garbage collection must tag pointers in some way so as to
  893. > make them distinctive.  A garbage collector for a C program must
  894. > therefore have detailed knowledge of the structures in the heap so that
  895. > it can trace them.
  896. > (2) How is the garbage collector going to identify pointers into the
  897. > heap?  It has to examine the stack, all global variables, and any
  898. > variables in registers.  Again, this depends upon detailed knowledge
  899. > about the implementation of the compiler.
  900.  
  901. -- 
  902. Lars.Farm@nts.mh.se
  903.  
  904. +++++++++++++++++++++++++++
  905.  
  906. >From boehm@parc.xerox.com (Hans Boehm)
  907. Date: 21 Dec 1994 02:26:02 GMT
  908. Organization: Xerox Palo Alto Research Center
  909.  
  910. gdr11@cl.cam.ac.uk (Gareth Rees) writes:
  911.  
  912. >Marc Steinbach (fh3ar@aixterm1.urz.uni-heidelberg.de) writes:
  913. >> We're looking for an automatic memory management which is handled by
  914. >> garbage collection and written in C for use in C-code.
  915.  
  916. >Such a beast can't be implemented as a portable C library for use by C
  917. >code, because garbage collection is implementation specific.  Consider:
  918.  
  919. Depends on what you mean by "portable".  The collector in
  920. parcftp.xerox.com:pub/gc/gc.tar.Z has been ported to all common
  921. workstation UN*X-like systems, win32, MacOS, OS/2 and AmigaDOS.
  922. Admittedly it contains some conditionally compiled code.
  923.  
  924. >(1) How is the garbage collector to distinguish between pointers and
  925. >other data, when it is marking/collecting the heap?  Compilers for
  926. >languages with garbage collection must tag pointers in some way so as to
  927. >make them distinctive.  A garbage collector for a C program must
  928. >therefore have detailed knowledge of the structures in the heap so that
  929. >it can trace them.
  930.  
  931. Or it can be conservative and trace through everything that looks like
  932. a pointer.  Doing so actually loses surprisingly little provided, as
  933. always, that you get the details right.  You need to restrict source
  934. programs slightly.  But the large majority of exisiting C programs
  935. already satisfy those restrictions.  (Strict ANSI conformance, plus
  936. some restrictions on pointer IO and memcpy and friends are sufficient.)
  937.  
  938. >(2) How is the garbage collector going to identify pointers into the
  939. >heap?  It has to examine the stack, all global variables, and any
  940. >variables in registers.  Again, this depends upon detailed knowledge
  941. >about the implementation of the compiler.
  942.  
  943. Again, a conservative scan for anything that looks like a pointer will do.
  944. You still have to find the stack, registers, etc., which introduces
  945. a minor OS/hardware dependency.  The only compiler dependency is that
  946. we expect the compiler not to disguise the last reference to an object.
  947. Most (all?) compilers preserve that property for unoptimized code.  (They almost
  948. have to, if you think about the requirements imposed by a debugger.)
  949. Some compilers (e.g. gcc) allow that property to be ensured by a
  950. source-to-source preprocessor at small cost, even in the presence of
  951. optimization.  We have never seen a real case of a compiler not
  952. maintaining this property, even on unprocessed, optimized code.  However,
  953. we can contrive cases that fail with optimization.
  954.  
  955. Probably the majority of compilers that use C as an intermediate language
  956. rely on some form of conservative collection for the target code (e.g.
  957. GCL (a.k.a. AKCL), Scheme-to-C, Bigloo, SRC Modula-3, Sather 1.0,
  958. Cedar).
  959.  
  960. Hans-J. Boehm
  961. (boehm@parc.xerox.com)
  962. Standard disclaimer ...
  963.  
  964. +++++++++++++++++++++++++++
  965.  
  966. >From devon@apple.com (Devon Hubbard)
  967. Date: Wed, 21 Dec 1994 11:11:13 -0800
  968. Organization: Apple Computer, Inc.
  969.  
  970. In article <9412191635.AA23470@ix.urz.uni-heidelberg.de>,
  971. fh3ar@aixterm1.urz.uni-heidelberg.de (Marc Steinbach) wrote:
  972.  
  973. > we're looking for an automatic memory management which is handled
  974. > by a garbage collection and written in C for use in C-code.
  975. > Especially for use with Apple Macs, Windows-based machines and
  976. > Sun Sparc running under Solaris.
  977.  
  978. Although I've never personally used it, I've heard good stuff about a
  979. cross platform memory management package called SmartHeap(tm) from
  980. MicroQuill. You can use it on Windows, UNIX (Sun, HP, etc.), OS/2, NT,
  981. Extended DOS and Macs. You can write 'devtools@microquill.win.net' for
  982. specific information.
  983.  
  984. dEVoN
  985.  
  986. - ------------------------------------------------------------------------
  987. Devon Hubbard                                                Silicon Pilot
  988. devon@apple.com                                        Apple Computer, Inc
  989.  
  990. +++++++++++++++++++++++++++
  991.  
  992. >From h+@metrowerks.com (Jon W{tte)
  993. Date: Wed, 21 Dec 1994 20:27:43 +0100
  994. Organization: The Conspiracy
  995.  
  996. In article <3d5ojt$omi@lyra.csx.cam.ac.uk>,
  997. gdr11@cl.cam.ac.uk (Gareth Rees) wrote:
  998.  
  999. >> We're looking for an automatic memory management which is handled by
  1000. >> garbage collection and written in C for use in C-code.
  1001.  
  1002. >Such a beast can't be implemented as a portable C library for use by C
  1003. >code, because garbage collection is implementation specific.  Consider:
  1004.  
  1005. There's a C and C++ library from Xerox which supposedly does 
  1006. this (I don't doubt it; I read the abstract and it wasn't too 
  1007. hairy)
  1008.  
  1009. >(1) How is the garbage collector to distinguish between pointers and
  1010. >other data, when it is marking/collecting the heap?  Compilers for
  1011.  
  1012. Surprise! It doesn't have to! Anything that looks like it could 
  1013. point into an allocated memory block can be said to reference 
  1014. that block, and the block is marked as referenced. All blocks 
  1015. not marked after a sweep are purged. So what if a few blocks 
  1016. aren't dstroyed immediately (or at all)
  1017.  
  1018. Oh, and the chances of actual data looking like pointers into 
  1019. an allocated block and not being such pointers is actually 
  1020. pretty slim!
  1021.  
  1022. >make them distinctive.  A garbage collector for a C program must
  1023. >therefore have detailed knowledge of the structures in the heap so that
  1024. >it can trace them.
  1025.  
  1026. Yes, it has to have detailed knowledge of the heap. Such 
  1027. knowledge IS available for the Mac memory manager heap, but the 
  1028. simplest thing to do is to replace malloc() and/or ::operator 
  1029. new() with your own allocator. That's not rocket science.
  1030.  
  1031. >(2) How is the garbage collector going to identify pointers into the
  1032. >heap?  It has to examine the stack, all global variables, and any
  1033. >variables in registers.  Again, this depends upon detailed knowledge
  1034. >about the implementation of the compiler.
  1035.  
  1036. Uh, no. As you say, it has to examine all registers, all global 
  1037. variables, and all local variables on the stack. It's well 
  1038. known where to find these for each system, and "portable" 
  1039. doesn't mean you have to compile ALL of the same code for all 
  1040. systems, just that you can move the code with relatively little 
  1041. effort (like, telling a header file where the stack is and 
  1042. where global data is)
  1043.  
  1044. Just walk the stack and global data (and all blocks 
  1045. subsequently marked as referenced...) on 2-byte boundaries 
  1046. (this is a 68K with short-sized ints and/or Booleans...) Then 
  1047. call setjmp() to get all registers into a buffer. If setjmp() 
  1048. doesn't work, write a smidgeon of assembly, and you're done.
  1049.  
  1050. This seems to be exactly what the Xerox gc library does, by the 
  1051. way!
  1052.  
  1053. Cheers,
  1054.  
  1055.                             / h+
  1056.  
  1057.  
  1058. --
  1059.   Jon W‰tte (h+@metrowerks.com), Hagagatan 1, 113 48 Stockholm, Sweden
  1060.   "It was, in fact, cool as all get-out.  Fortunately it was a little
  1061.    too late (historically speaking) to be groovy."
  1062.                      -- Dennis Pelton
  1063.  
  1064.  
  1065. +++++++++++++++++++++++++++
  1066.  
  1067. >From gurgle@dnai.com (Pete Gontier)
  1068. Date: Thu, 22 Dec 1994 14:22:54 -0700
  1069. Organization: cellular
  1070.  
  1071. In article <3d83nq$qvl@news.parc.xerox.com>,
  1072. boehm@parc.xerox.com (Hans Boehm) wrote:
  1073.  
  1074. > You still have to find the stack...
  1075.  
  1076. On Macintosh, an application may have several stacks, one for each
  1077. lightweight thread. Is there multiple stack support in this library?
  1078.  
  1079. ________________________________________________________________________________
  1080.  Pete Gontier -- MacZealotry, Ink. -- gurgle@dnai.com
  1081.  Where do I want to go today? Anywhere but Chicago.
  1082.  
  1083. ---------------------------
  1084.  
  1085. >From julian@cs.auckland.ac.nz (Julian Harris)
  1086. Subject: Recordable applications
  1087. Date: Mon, 19 Dec 1994 14:23:04 +1300
  1088. Organization: Computer Science Department, UA
  1089.  
  1090. Well, along with the famous net saying 'The best way to get information on
  1091. UseNet isn't to ask a question, but to post the wrong information', I'll
  1092. start off by saying
  1093.  
  1094. I've been researching the Apple event manager and was wondering how to
  1095. find out whether an application is recording apple events (to optimise my
  1096. ui routines, I wanted to only send/receive apple events to myself when
  1097. recording) and I found in IM-Interapplication Communication, 9-36:
  1098.  
  1099.     "To determine whether another process is recording apple events, check
  1100.      bit 7 of the _AEProcessState_ ($B1F) low memory global and adjust your
  1101.      apple event sending routine appropriately"
  1102.  
  1103. ...but this is all lies and I just made it up.
  1104.  
  1105. ON p9-36 in IAC, it talks about the 'Start Recording' event which is sent
  1106. to all running processes when an application (e.g. Script Editor)
  1107. indicates it wants to start recording. 
  1108.  
  1109. I want to write an application that is fully recordable and scriptable,
  1110. but I reel at the thought of having to send and receive apple events for
  1111. everything I do just so that a recording will get the stuff. And in all
  1112. reality, even in a few years, you won't be recording more than about 10%
  1113. of the time.
  1114.  
  1115. Wouldn't it be better to only generate the events when someone is
  1116. listening? I.e. in response to 'Start Recording', set a global flag, and
  1117. clear it when you get a 'Stop Recording' message. Then in your ui dispatch
  1118. routines, you can check the flag and generate the apple event if something
  1119. is recording.
  1120.  
  1121. Comments?
  1122. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
  1123. Microsoft is not the answer.                    >  Julian Harris, Programmer   >
  1124. Microsoft is the question.                     >  Comp. Sci. Dept.     x8915  >
  1125.                                               >  The University of Auckland  >
  1126. NO is the answer.                            >  julian@cs.auckland.ac.nz    >
  1127.  
  1128. +++++++++++++++++++++++++++
  1129.  
  1130. >From stk@DoBag.IN-Berlin.DE (Stefan Kurth)
  1131. Date: Mon, 19 Dec 1994 03:34:19 +0100
  1132. Organization: none
  1133.  
  1134. In article <julian-1912941423040001@julian.cs.aukuni.ac.nz>,
  1135. julian@cs.auckland.ac.nz (Julian Harris) wrote:
  1136.  
  1137. > I want to write an application that is fully recordable and scriptable,
  1138. > but I reel at the thought of having to send and receive apple events for
  1139. > everything I do just so that a recording will get the stuff.
  1140. >
  1141. > Wouldn't it be better to only generate the events when someone is
  1142. > listening?
  1143.  
  1144. If you send AppleEvents to yourself, they don't go through the event
  1145. loop, but are directly dispatched to the respective AE handlers.  This
  1146. seems quite efficient, and is unlikely to slow down the application.  I
  1147. don't think what you suggest is worth the trouble.
  1148.  
  1149. ________________________________________________________________________
  1150. Stefan Kurth             Berlin, Germany          stk@dobag.in-berlin.de
  1151.  
  1152. +++++++++++++++++++++++++++
  1153.  
  1154. >From plsuh@econ.sas.upenn.edu (Paul L. Suh)
  1155. Date: Sun, 18 Dec 1994 22:52:28 -0500
  1156. Organization: UPenn Grad Econ
  1157.  
  1158. In article <julian-1912941423040001@julian.cs.aukuni.ac.nz>,
  1159. julian@cs.auckland.ac.nz (Julian Harris) wrote:
  1160.  
  1161. > I want to write an application that is fully recordable and scriptable,
  1162. > but I reel at the thought of having to send and receive apple events for
  1163. > everything I do just so that a recording will get the stuff. And in all
  1164. > reality, even in a few years, you won't be recording more than about 10%
  1165. > of the time.
  1166. > Wouldn't it be better to only generate the events when someone is
  1167. > listening? I.e. in response to 'Start Recording', set a global flag, and
  1168. > clear it when you get a 'Stop Recording' message. Then in your ui dispatch
  1169. > routines, you can check the flag and generate the apple event if something
  1170. > is recording.
  1171.  
  1172. As I understand the guidelines, a true object model scriptable app should
  1173. not care where the AE came from, outside or inside the app.  If you
  1174. receive a MenuKey-type command to set the text style to italic, for
  1175. instance, you should send yourself an AppleEvent telling you to set the
  1176. selection to italic.  The overhead involved in this is minimal, and you
  1177. reduce the chances of bugs creeping in because you handle an AE command
  1178. slightly differently from an internal one.  As a bonus, recordability is
  1179. almost automatic.  
  1180.  
  1181.  
  1182. --Paul
  1183.  
  1184. -- 
  1185. P |\   / S   University of Pennsylvania
  1186.   | \ /      Graduate Economics
  1187.   |  X
  1188.   | / \      Paul L. Suh
  1189.   |/   \ D   plsuh@econ.sas.upenn.edu
  1190.   +------ Q
  1191.  
  1192. +++++++++++++++++++++++++++
  1193.  
  1194. >From julian@cs.auckland.ac.nz (Julian Harris)
  1195. Date: Tue, 20 Dec 1994 10:44:05 +1300
  1196. Organization: Computer Science Department, UA
  1197.  
  1198. In article <3d2rf7$35r@unlisys.IN-Berlin.DE>, stk@DoBag.IN-Berlin.DE
  1199. (Stefan Kurth) wrote:
  1200.  
  1201. > In article <julian-1912941423040001@julian.cs.aukuni.ac.nz>,
  1202. > julian@cs.auckland.ac.nz (Julian Harris) wrote:
  1203. > > I want to write an application that is fully recordable and scriptable,
  1204. > > but I reel at the thought of having to send and receive apple events for
  1205. > > everything I do just so that a recording will get the stuff.
  1206. > >
  1207. > > Wouldn't it be better to only generate the events when someone is
  1208. > > listening?
  1209. > If you send AppleEvents to yourself, they don't go through the event
  1210. > loop, but are directly dispatched to the respective AE handlers.
  1211.  
  1212. Yes, but you still have to encapsulate the object descriptors and parse
  1213. them again on receipt. 
  1214.  
  1215. >This
  1216. > seems quite efficient, and is unlikely to slow down the application.  I
  1217. > don't think what you suggest is worth the trouble.
  1218.  
  1219. Have you written a recorable app yourself?
  1220. Constructing object specifiers seems to be a time consuming, nontrivial
  1221. task. Any of the demos that are provided with AppleScript CD contain
  1222. _hundreds_ of k of source. You maybe right, and I hope so, but I'm not
  1223. convinced.
  1224. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
  1225. Microsoft is not the answer.                    >  Julian Harris, Programmer   >
  1226. Microsoft is the question.                     >  Comp. Sci. Dept.     x8915  >
  1227.                                               >  The University of Auckland  >
  1228. NO is the answer.                            >  julian@cs.auckland.ac.nz    >
  1229.  
  1230. +++++++++++++++++++++++++++
  1231.  
  1232. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  1233. Date: 22 Dec 94 21:07:05 +1300
  1234. Organization: University of Waikato, Hamilton, New Zealand
  1235.  
  1236. In article <plsuh-1812942252290001@ts3-40.upenn.edu>, plsuh@econ.sas.upenn.edu (Paul L. Suh) writes:
  1237. > In article <julian-1912941423040001@julian.cs.aukuni.ac.nz>,
  1238. > julian@cs.auckland.ac.nz (Julian Harris) wrote:
  1239. >
  1240. >> I want to write an application that is fully recordable and scriptable,
  1241. >> but I reel at the thought of having to send and receive apple events for
  1242. >> everything I do just so that a recording will get the stuff. And in all
  1243. >> reality, even in a few years, you won't be recording more than about 10%
  1244. >> of the time.
  1245. >>
  1246. >> Wouldn't it be better to only generate the events when someone is
  1247. >> listening? I.e. in response to 'Start Recording', set a global flag, and
  1248. >> clear it when you get a 'Stop Recording' message. Then in your ui dispatch
  1249. >> routines, you can check the flag and generate the apple event if something
  1250. >> is recording.
  1251. >
  1252. > As I understand the guidelines, a true object model scriptable app should
  1253. > not care where the AE came from, outside or inside the app.  If you
  1254. > receive a MenuKey-type command to set the text style to italic, for
  1255. > instance, you should send yourself an AppleEvent telling you to set the
  1256. > selection to italic.  The overhead involved in this is minimal, and you
  1257. > reduce the chances of bugs creeping in because you handle an AE command
  1258. > slightly differently from an internal one.  As a bonus, recordability is
  1259. > almost automatic.
  1260.  
  1261. I want to add my agreement to Paul's posting. Having spent about six weeks'
  1262. worth of evenings and weekends working on a viewer for QuickDraw GX Portable
  1263. Digital Documents that also happens to be scriptable and recordable and
  1264. supports the AppleEvent Object Model, I don't think it's really worth it to
  1265. try to do things two different ways, depending on whether somebody is
  1266. recording your actions or not. It just adds extra complications to your code.
  1267.  
  1268. There are a few situations where you might not want to incur the overhead
  1269. of sending too many events, such as:
  1270.  
  1271. * Typing text. It makes sense to save up a string of text that the user has
  1272. typed, and send them as one event when the user does something else. I believe
  1273. the Scriptable Text Editor might do something like this.
  1274. * Performing some continuous action, such as scrolling a view in a window.
  1275. It makes sense to send a single event to set the view origin to the final
  1276. value when the user releases the mouse button.
  1277.  
  1278. Note that in both these cases, the event you send tells you to do something
  1279. that you've already done. The way I deal with this is by having a bit of smarts
  1280. in the event handling code, so that it doesn't do anything in response to an
  1281. event which is effectively a no-op. I feel this is preferable to setting the
  1282. kAEDontExecute bit in the SendMode flags, as that depends on having AppleEvent
  1283. Manager 1.0.1 or later, which might not be present.
  1284.  
  1285. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  1286. Computer Services Dept                     fax: +64-7-838-4066
  1287. University of Waikato            electric mail: ldo@waikato.ac.nz
  1288. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  1289.  
  1290. +++++++++++++++++++++++++++
  1291.  
  1292. >From jwbaxter@olympus.net (John W. Baxter)
  1293. Date: Thu, 22 Dec 1994 08:55:32 -0800
  1294. Organization: Internet for the Olympic Peninsula
  1295.  
  1296. In article <1994Dec22.210705.36213@waikato.ac.nz>, ldo@waikato.ac.nz
  1297. (Lawrence D'Oliveiro, Waikato University) wrote:
  1298.  
  1299. > There are a few situations where you might not want to incur the overhead
  1300. > of sending too many events, such as:
  1301. > * Typing text. It makes sense to save up a string of text that the user has
  1302. > typed, and send them as one event when the user does something else. I believe
  1303. > the Scriptable Text Editor might do something like this.
  1304.  
  1305. A likely starting point for finding those situations is "does Undo undo a
  1306. bunch of stuff?"  If so, it's likely that one recorded event represents
  1307. several actions.
  1308.  
  1309. > Note that in both these cases, the event you send tells you to do something
  1310. > that you've already done. The way I deal with this is by having a bit of
  1311. smarts
  1312. > in the event handling code, so that it doesn't do anything in response to an
  1313. > event which is effectively a no-op. I feel this is preferable to setting the
  1314. > kAEDontExecute bit in the SendMode flags, as that depends on having AppleEvent
  1315. > Manager 1.0.1 or later, which might not be present.
  1316.  
  1317. Good point about AE Manager 1.0.  However, it's probably better to mark
  1318. the event execute only (to avoid the overhead of starting the event
  1319. handler only to notice that it shouldn't run, on non-archiac systems) AND
  1320. to detect that the event shouldn't be handled.  Ideally, one would be able
  1321. to dig the send mode out of the event and check the don't execute bit, but
  1322. a quick look didn't show me a supported way to do that.
  1323.  
  1324. It might be interesting to experiment with an attribute defined by the
  1325. app, to hold the information.
  1326.  
  1327.    --John
  1328.  
  1329. -- 
  1330. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  1331.    jwbaxter@pt.olympus.net
  1332.  
  1333. ---------------------------
  1334.  
  1335. >From raub@alder.circa.ufl.edu (Mauricio C Tavares)
  1336. Subject: Transparent PICTs?
  1337. Date: 28 Nov 1994 20:59:44 -0600
  1338. Organization: UTexas Mail-to-News Gateway
  1339.  
  1340.     I know this may be a pretty silly question, but what do I need to 
  1341. do to write a PICT resource on the top of the other so that the white 
  1342. space surrounding the drawing itself bahaves as if it was transparent?
  1343.  
  1344. +++++++++++++++++++++++++++
  1345.  
  1346. >From chaoyang@usc.edu (Chao-Kuang Yang (Mark Yang))
  1347. Date: Fri, 18 Nov 1994 22:27:56 -0800
  1348. Organization: Z-Perception Graphics
  1349.  
  1350. In article <199411290300.WAA02464@grove.ufl.edu>, raub@alder.circa.ufl.edu
  1351. (Mauricio C Tavares) wrote:
  1352.  
  1353. >         I know this may be a pretty silly question, but what do I need to 
  1354. > do to write a PICT resource on the top of the other so that the white 
  1355. > space surrounding the drawing itself bahaves as if it was transparent?
  1356.  
  1357. Hi!
  1358.    What you can do is to scan through the picture, which overlays another,
  1359. itself and set the clip region on the other overlayed picture.  You can
  1360. refer to Inside Macintosh: Imaging to the operation about the clip region.
  1361.  
  1362. Mark Yang
  1363.  
  1364. +++++++++++++++++++++++++++
  1365.  
  1366. >From "Jonathan R. Seagrave" <jrs@doek.uoregon.edu>
  1367. Date: Mon, 28 Nov 1994 22:18:10 -0800 (PST)
  1368. Organization: University of Oregon
  1369.  
  1370. On 28 Nov 1994, Mauricio C Tavares wrote:
  1371. >     I know this may be a pretty silly question, but what do I need to 
  1372. > do to write a PICT resource on the top of the other so that the white 
  1373. > space surrounding the drawing itself bahaves as if it was transparent?
  1374.  
  1375. hmmm... I'd like to know the answer to this one too. ??
  1376.  
  1377. jrs
  1378.  
  1379. +++++++++++++++++++++++++++
  1380.  
  1381. >From songer@lexmark.com
  1382. Date: Tue, 29 Nov 1994 16:33:38 GMT
  1383. Organization: Lexmark International, Lexington, KY
  1384.  
  1385. In article <Pine.NXT.3.90.941128221533.8160C-100000@doek.uoregon.edu> "Jonathan R. Seagrave" <jrs@doek.uoregon.edu> writes:
  1386.  
  1387.    On 28 Nov 1994, Mauricio C Tavares wrote:
  1388.    >     I know this may be a pretty silly question, but what do I need to 
  1389.    > do to write a PICT resource on the top of the other so that the white 
  1390.    > space surrounding the drawing itself bahaves as if it was transparent?
  1391.  
  1392.    hmmm... I'd like to know the answer to this one too. ??
  1393.  
  1394.  
  1395. Hi!
  1396.  
  1397.      Here's how I do it. Be aware that in this solution I am willing
  1398. to sacrifice memory and setup time for fast compositing. 
  1399.  
  1400.      Draw both picts into GWorlds with the Draw Picture call (make
  1401. sure your GWorld's are erased. The GWorld holding the overlaying pict
  1402. should be an Offscreen GWorld.) Then use CopyBits() with the
  1403. transparent operator to copy the PixMap containing the overlay picture
  1404. into the base picture's PixMap. You now have a GWorld which has the
  1405. base picture and the overlay in it. (Destroy the overlay Offscreen
  1406. GWorld if you no longer need it.)
  1407.  
  1408.      If you are only doing this once, then you should probably
  1409. consider making this resultant pixmap the pixmap for the window in
  1410. which you are drawing -- ie draw the base pict into the window, draw
  1411. the overlay pict into an offscreen GWorld and then CopyBits() the
  1412. overlay into the window. If, however, you are going to composite this
  1413. combined image alot, you might consider retaining the combined image
  1414. in an offscreen GWorld so that you can do this quickly. The
  1415. transparent CopyBits() is comparitively slow.
  1416.  
  1417.      I am by no means a mac programming whiz, (I just started about
  1418. four months ago and only do it in my spare time.) so there may be a
  1419. better solution but this one does work.
  1420.  
  1421. Anyway,
  1422. -Chris
  1423. songer@lexmark.com
  1424.  
  1425. +++++++++++++++++++++++++++
  1426.  
  1427. >From cons116@titan.ucs.umass.edu (Mike White)
  1428. Date: 30 Nov 1994 19:00:35 GMT
  1429. Organization: University of Massachusetts, Amherst
  1430.  
  1431. Mauricio C Tavares (raub@alder.circa.ufl.edu) wrote:
  1432. :     I know this may be a pretty silly question, but what do I need to 
  1433. : do to write a PICT resource on the top of the other so that the white 
  1434. : space surrounding the drawing itself bahaves as if it was transparent?
  1435.  
  1436. Another solution is to use photoshop to create a mask of the image by
  1437. selecting the unwanted regions (magic wand would work well here), selecting
  1438. the inverse of this, and then feathering, if you want a a smoothly
  1439. transitioned overlay.
  1440.  
  1441. I believe you should then be able to bring up the images in an ofscreen
  1442. world and do copybits using some sort of "and" operation (note intentional
  1443. vagueness: I haven't actually done this before, but the theory should hold
  1444. true).  The downside of this is that you must use an image editing program
  1445. rather than directly programming to analyze the image.  It should work
  1446. though.
  1447.  
  1448. Most implementations of sprites that I know of work in basically this manner.
  1449.  
  1450. mike white
  1451.  
  1452.  
  1453. +++++++++++++++++++++++++++
  1454.  
  1455. >From Jeremy Doig <jeremy@power.globalnews.com>
  1456. Date: 1 Dec 1994 20:11:04 GMT
  1457. Organization: Internet Publishing
  1458.  
  1459. In article <199411290300.WAA02464@grove.ufl.edu> Mauricio C Tavares,
  1460. raub@alder.circa.ufl.edu writes:
  1461. >    I know this may be a pretty silly question, but what do I need to
  1462. >do to write a PICT resource on the top of the other so that the white
  1463. >space surrounding the drawing itself bahaves as if it was transparent?
  1464.  
  1465. Just on the off chance - if you're thinking of writing a Transparent GIF
  1466. maker, it's been done by Aaron Giles (and it's great).
  1467. If not, sorry I spoke...
  1468.  
  1469.  
  1470. Jeremy
  1471.  
  1472. +++++++++++++++++++++++++++
  1473.  
  1474. >From Charles Thomas <Charlest@macc.wisc.edu>
  1475. Date: 3 Dec 1994 21:25:31 GMT
  1476. Organization: IMR, University of Wisconsin-Madison
  1477.  
  1478. In article <SONGER.94Nov29113338@ovation.lexmark.com> ,
  1479. songer@lexmark.com writes:
  1480. >
  1481. >     Here's how I do it. Be aware that in this solution I am willing
  1482. >to sacrifice memory and setup time for fast compositing. 
  1483. >
  1484. >     Draw both picts into GWorlds with the Draw Picture call (make
  1485. >sure your GWorld's are erased. The GWorld holding the overlaying pict
  1486. >should be an Offscreen GWorld.) Then use CopyBits() with the
  1487. >transparent operator to copy the PixMap containing the overlay picture
  1488. >into the base picture's PixMap. You now have a GWorld which has the
  1489. >base picture and the overlay in it. (Destroy the overlay Offscreen
  1490. >GWorld if you no longer need it.)
  1491. >
  1492. >     If you are only doing this once, then you should probably
  1493. >consider making this resultant pixmap the pixmap for the window in
  1494. >which you are drawing -- ie draw the base pict into the window, draw
  1495. >the overlay pict into an offscreen GWorld and then CopyBits() the
  1496. >overlay into the window. If, however, you are going to composite this
  1497. >combined image alot, you might consider retaining the combined image
  1498. >in an offscreen GWorld so that you can do this quickly. The
  1499. >transparent CopyBits() is comparitively slow.
  1500. >
  1501.  
  1502. Would the CopyBits operation with the transparent operator work to make a
  1503. transparent PICT overlay from a frame of a QuickTime movie?
  1504.  
  1505. More specifically, I'm trying to make a program to put an overlay onto a
  1506. quicktime movie as it's playing (e.g. an arrow following some feature in
  1507. the quicktime movie).
  1508.  
  1509. I can make an overlay that moves around in response to the mouse (and can
  1510. be turned on or off) by creating a new track and setting the Clip Region
  1511. for that track to be arrow-shaped, but this doesn't allow the user to
  1512. play back or save the movements of the arrow in the overlay.  
  1513.  
  1514. So, what I'd like to do is creat a PICT of the arrow at the mouse
  1515. position, have everything but the arrow be transparent (so the QuickTime
  1516. movie underneath can be seen), then save the PICT to the overlay track. 
  1517. In this way it could be played back and turned on/off.
  1518.  
  1519. So... would your method allow you to use the Transparent Operator to do
  1520. operations on a PICT from a QuickTime frame?
  1521.  
  1522. +++++++++++++++++++++++++++
  1523.  
  1524. >From hanrek@cts.com (Mark Hanrek)
  1525. Date: Sat, 3 Dec 1994 20:13:30 GMT
  1526. Organization: The Information Worskhop
  1527.  
  1528. In article <199411290300.WAA02464@grove.ufl.edu>, raub@alder.circa.ufl.edu
  1529. (Mauricio C Tavares) wrote:
  1530.  
  1531. >         I know this may be a pretty silly question, but what do I need to 
  1532. > do to write a PICT resource on the top of the other so that the white 
  1533. > space surrounding the drawing itself bahaves as if it was transparent?
  1534.  
  1535.  
  1536. This effect is accomplished by using "transparent" in the CopyBits "mode"
  1537. parameter. Normally the mode parameter is "srcCopy", which says to copy
  1538. all of the pixels regardless.
  1539.  
  1540. Too simple.
  1541.  
  1542. But, you are presumably using DrawPicture to draw your PICTs.  Here's the
  1543. deal...
  1544.  
  1545. Keep in mind that a PICT is a complex conglomeration of a lot of things
  1546. (e.g. color tables, bitmaps, drawing operations, clip regions, etc).  
  1547.  
  1548. Presumably the PICT in question was created by someone else.  There is
  1549. probably a "copybits" operation within that PICT, but you cannot get in
  1550. there and change the copybits mode to "transparent".
  1551.  
  1552. So, what you must do is first draw the PICT to a GWorld the same depth as
  1553. the destination window, and then CopyBits the GWorld to the destination
  1554. window so that you have the opportunity to specify the "transparent"
  1555. transfermode.
  1556.  
  1557. - ---
  1558.  
  1559. Depending on your situation, it is possible for you to "recreate" that
  1560. PICT so that it does what you wanted in the first place.  You would do
  1561. this by drawing the PICT to the GWorld as before, then call OpenPicture,
  1562. CopyBits the image to itself using the transparent mode, and then
  1563. ClosePicture.  
  1564.  
  1565. But there could be sticky issues, such as the original bit depth of the
  1566. picture.  Or the graphic may be constructed with lots of individual
  1567. graphic objects (MacDraw-style), and all of that would be lost by
  1568. recreating the picture.  I am really mentioning this just for completeness
  1569. and perspective.
  1570.  
  1571. Mark Hanrek
  1572. The Information Workshop
  1573.  
  1574. +++++++++++++++++++++++++++
  1575.  
  1576. >From songer@lexmark.com
  1577. Date: Wed, 14 Dec 1994 18:08:24 GMT
  1578. Organization: Lexmark International, Lexington, KY
  1579.  
  1580. In article <3bqnob$4h7@news.doit.wisc.edu> Charles Thomas <Charlest@macc.wisc.edu> writes:
  1581.    [...]
  1582.    So... would your method allow you to use the Transparent Operator to do
  1583.    operations on a PICT from a QuickTime frame?
  1584.    [...]
  1585.  
  1586. Hi!
  1587.  
  1588.      Unfortunately, I don't know.
  1589.  
  1590. -Chris
  1591.  
  1592. +++++++++++++++++++++++++++
  1593.  
  1594. >From ikb_macd@ece.concordia.ca (Keith MacDonald)
  1595. Date: 16 Dec 1994 04:30:00 GMT
  1596. Organization: ECE - Concordia University
  1597.  
  1598. : >         I know this may be a pretty silly question, but what do I need to 
  1599. : > do to write a PICT resource on the top of the other so that the white 
  1600. : > space surrounding the drawing itself bahaves as if it was transparent?
  1601.  
  1602.  
  1603. : This effect is accomplished by using "transparent" in the CopyBits "mode"
  1604. : parameter. Normally the mode parameter is "srcCopy", which says to copy
  1605. : all of the pixels regardless.
  1606.  
  1607. Just a quick note - "transparent" copies all bits which are not *the same as
  1608. the background color* (which may not be white in all cases).  I know the 
  1609. original post was for a white background but I soon found out it won't work
  1610. with non-white backgrounds with a pict w/ white background...back to copyMask().
  1611.  
  1612. Cheers,
  1613. Keith
  1614. ___________________________________________________________________________
  1615.  Keith MacDonald                                       Computer Engineering
  1616.  ikb_macd@ECE.concordia.ca                             Concordia University
  1617.  http://www.ece.concordia.ca/~ikb_macd/addr.html       Montreal, QC, Canada
  1618.  
  1619. +++++++++++++++++++++++++++
  1620.  
  1621. >From greg@cosc.canterbury.ac.nz (Greg Ewing)
  1622. Date: 21 Dec 1994 00:36:12 GMT
  1623. Organization: University of Canterbury, Christchurch, New Zealand
  1624.  
  1625.  
  1626.  
  1627. +++++++++++++++++++++++++++
  1628.  
  1629. >From greg@cosc.canterbury.ac.nz (Greg Ewing)
  1630. Date: 21 Dec 1994 00:38:04 GMT
  1631. Organization: University of Canterbury, Christchurch, New Zealand
  1632.  
  1633.  
  1634. In article <3cr548$lo6@newsflash.concordia.ca>, ikb_macd@ece.concordia.ca (Keith MacDonald) writes:
  1635. |> it won't work with non-white backgrounds with a pict w/ white background...
  1636. |> back to copyMask().
  1637.  
  1638. Why not just set the background colour to white for the
  1639. duration of the CopyBits?
  1640.  
  1641. Greg Ewing, Computer Science Dept, +--------------------------------------+
  1642. University of Canterbury,       | A citizen of NewZealandCorp, a      |
  1643. Christchurch, New Zealand       | wholly-owned subsidiary of Japan Inc.|
  1644. greg@cosc.canterbury.ac.nz       +--------------------------------------+
  1645.  
  1646. ---------------------------
  1647.  
  1648. End of C.S.M.P. Digest
  1649. **********************
  1650.  
  1651.  
  1652.