From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-058 Date: Thu, 15 Sep 1994 13:51:12 +0200 (MET DST) C.S.M.P. Digest Thu, 15 Sep 94 Volume 3 : Issue 58 Today's Topics: AppleEvents for command line args (argc, argv)? Exception Handling NIM on develop, as of 19 Need to Stop flashing Desktop when changing palletes PPostEvent mouse events Sample MacTcp Programs Selecting Window via menus SetDialogDefaultItem real? Stack sniffer - how can I turn it off? 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 rhn@waltz.engr.sgi.com (Ron Nicholson) Subject: AppleEvents for command line args (argc, argv)? Date: Wed, 24 Aug 1994 18:05:15 GMT Organization: Silicon Graphics, Inc., Mountain View, CA Are there AppleEvents suitable for passing a unix style command line to a ported Unix C application? I handle the 4 required AppleEvents in a wrapper, but that's not enough to pass all the args needed to a ported app. Thanks, Ronald H. Nicholson, Jr. rhn@engr.sgi.com, rhn@netcom.com, N6YWU #include // I speak only for myself, etc. +++++++++++++++++++++++++++ >From rhn@netcom.com (Ron Nicholson) Date: Thu, 1 Sep 1994 05:51:04 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article I wrote: >Are there AppleEvents suitable for passing a unix style command line >to a ported Unix C application? I handle the 4 required AppleEvents >in a wrapper, but that's not enough to pass all the args needed to >a ported app. Thanks for all the replies. Several people recommended using the DoScript ('dosc') command, part of the misc suite. I tried using the DoScript command and it works just fine. Inside my initialization code for the required handlers I added: err = AEInstallEventHandler('misc', kAEDoScript, NewAEEventHandlerProc(myHandleDoScript), 0, false); // 'misc' == kAEMiscSuite ; couldn't find it in my headers files. Inside the myHandleDoScript AE handler routine I used: err = AEGetParamPtr(aevt, keyDirectObject, typeChar, &typeCode, myParamTextBuffer, 256L, &actualSize); This puts a string of text into myParamTextBuffer that can be parsed into parameters or commands (in the main loop, NOT in the handler). Do I need to do anything else to make this bulletproof? I needed an aete resource containing DoScript and the required AppleEvents. I found one inside the ToolServer 1.1 application. I just copied it since I don't have an aete editor. I'm going to try this for porting standalone unix filters like grep. >>> Tell application "grep" to DoScript "grep -i foo somefile.txt" Something like "grep bar < infile > outfile" should work for unix style file names in a default directory. I suppose something like this could be packaged up with a dropshell to make it a scriptshell. - - Ronald H. Nicholson, Jr. rhn@netcom.com, rhn@engr.sgi.com, N6YWU #include // I speak only for myself, etc. --------------------------- >From stara@holmes.ece.orst.edu (Aaron Starr) Subject: Exception Handling Date: 29 Aug 1994 18:58:11 GMT Organization: College of Engineering, Oregon State University Until we have a compiler that supports exception handling, I need to use some sort of approximation in my code. Anyone have any preferences? I know that Symantec has an exception library for TCL, as well as a Bedrock exception library, and I know that Metrowerks has something similar for PowerPlant. Does anyone know which of these is most similar to likely implementations in the compiler? Thanks for info, Aaron Starr stara@ece.orst.edu +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 30 Aug 1994 02:59:30 -0400 Organization: America Online, Inc. (1-800-827-6364) Aaron Starr (stara@holmes.ece.orst.edu ) writes: >Until we have a compiler that supports exception handling, I need to use >some sort of approximation in my code. Anyone have any preferences? > >I know that Symantec has an exception library for TCL, as well as a >Bedrock exception library, and I know that Metrowerks has something >similar for PowerPlant. Does anyone know which of these is most similar >to likely implementations in the compiler? I'm the engineer who did most of the work on BEL. If your criteria is compatibility to the C++ standard, then I think BEL is your best choice. Of course, I'm biased, but let me try to give you enough facts so that you can make an objective decision. The original TCL exception handling implementation made no attempt to throw/catch objects, and no attempt to delete stack-based objects as the stack is unwound. The PowerPlant mechanism does not throw objects, though it does delete stack-based objects. However, it calls constructors for partially constructed objects, and doesn't prevent memory leaks when exceptions are thrown from constructors of objects that are being allocated from the heap. BEL does throw/catch objects; in fact, BEL only throws objects. It doesn't allow throwing of arbitrary types like integers and strings. Of course, you can package integers and strings inside exception classes of your own design. BEL properly deletes stack based objects as the stack is unwound. Destructors are called only for fully constructed objects. However, BEL doesn't do this automatically; you must insert a macro call at the end of every constructor and the start of every destructor for the classes that need automatic cleanup. You must also derive such classes from a special class. If you use multiple inheritance there are some restrictions; the major one being that you can't inherit from the special "CAutoDestruct" class more than once, and virtual base classes are not supported. If you use mixin style inheritance, then your mixin classes should not be derived from CAutoDestruct. BEL also handles the case where an object is allocated from the heap using operator new and an exception is thrown from the constructor. In this case, the raw memory allocated (with ::operator new()) must be deleted by the exception handling mechanism. The BEL macros that implement the programming interface are designed to be compatible with the C++ exception handling syntax. When compilers provide exception handling, BEL's macros can be redefined to the C++ syntax. You can then recompile your code without making any changes to take advantage of the compilers support. Of course, you can then globally replace the macros with the real syntax, but there may be good reasons to continue using the macros for a while. For example, an implementation of BEL for Windows exists, so if you write cross platform code using BEL you will want to wait to use the true C++ syntax until all of your compilers support exceptions (and do so relatively bug-free). Finally, even though Bedrock is no more, the OpenDoc Parts Framework (OPF) is being developed with BEL. I am now a contractor at Apple working on OPF, and I am enhancing BEL as part of the contract. What is the downside to BEL? The main issue is performance and code size. There are lots of things a compiler can do that can't be done using portable C++ code; that is why Stroustrup wanted exceptions in the language, and not just a part of the standard library. You'll have to settle with some overhead until the compilers implement exceptions. There are of course other compromises. Jim Lloyd afcjlloyd@aol.com -or- Jim_Lloyd@powertalk.apple.com +++++++++++++++++++++++++++ >From jahess@metrowerks.com (Jonathan Hess) Date: 30 Aug 1994 18:53:50 GMT Organization: ViviStar Consulting In article <33tb43$1r2@engr.orst.edu> stara@holmes.ece.orst.edu (Aaron Starr) writes: > I know that Symantec has an exception library for TCL, as well as a > Bedrock exception library, and I know that Metrowerks has something > similar for PowerPlant. Does anyone know which of these is most similar > to likely implementations in the compiler? TCL 2 uses the Bedrock exception library "BEL." Once you get past the macros, BEL probably is closer to C++ exceptions for throwing actual objects and the like. But, if you like simplicity, UExceptions from PowerPlant is REAL clean. In both cases you'll probably be able to global GREP search and replaces for C++ exceptions. As for my personal preference... well I'm biased. :) , Jonathan Hess Metrowerks, Inc. jahess@metrowerks.com +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 31 Aug 1994 03:16:03 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <33vv7u$7i4@tracker.ramp.com>, jahess@metrowerks.com (Jonathan Hess) writes: >In article <33tb43$1r2@engr.orst.edu> >stara@holmes.ece.orst.edu (Aaron Starr) writes: > >> I know that Symantec has an exception library for TCL, as well as a >> Bedrock exception library, and I know that Metrowerks has something >> similar for PowerPlant. Does anyone know which of these is most similar >> to likely implementations in the compiler? > >TCL 2 uses the Bedrock exception library "BEL." Once you get past the >macros, BEL probably is closer to C++ exceptions for throwing actual >objects and the like. > >But, if you like simplicity, UExceptions from PowerPlant is REAL clean. > >In both cases you'll probably be able to global GREP search and >replaces for C++ exceptions. > >As for my personal preference... well I'm biased. :) The number one design criteria for BEL was to be "sufficiently" close to the C++ standard. To achieve this we wanted application developers to be able to write exception handling code in almost exactly the same style they would use with C++ exceptions, with only minimal restrictions, and that code written using BEL could be recompiled without changes and work correctly when compilers support C++ exceptions. Alas, this criteria often precluded simplicity. As it happens, I spend a little of my spare time working on an idea I have for an educational game. The exception library I wrote for it is even simpler than PowerPlant's UExceptions. You see, I too believe that for some applications, simplicity is more important than adherence to some external standard. Jim Lloyd afcjlloyd@aol.com -or- Jim_Lloyd@powertalk.apple.com +++++++++++++++++++++++++++ >From sparent@mv.us.adobe.com (Sean Parent) Date: Wed, 31 Aug 1994 20:49:22 GMT Organization: Adobe Systems Incorporated How does BEL handle the case of an auto-destruct member within another auto-destruct derived class? That is, how do you handle: class CFoo : CAutoDestruct { ... } class CBar : CAutoDestruct { CFoo fooMember; } void Test { CBar bar; CFoo foo; Failure(); // or throw } You need to thread foo and bar onto your exception stack but not fooMember (since it's destructor will get called when bar is destructed). Sean In article <341anj$sv3@search01.news.aol.com>, afcjlloyd@aol.com (AFC JLloyd) wrote: > In article <33vv7u$7i4@tracker.ramp.com>, jahess@metrowerks.com (Jonathan > Hess) writes: > > >In article <33tb43$1r2@engr.orst.edu> > >stara@holmes.ece.orst.edu (Aaron Starr) writes: > > > >> I know that Symantec has an exception library for TCL, as well as a > >> Bedrock exception library, and I know that Metrowerks has something > >> similar for PowerPlant. Does anyone know which of these is most > similar > >> to likely implementations in the compiler? > > > >TCL 2 uses the Bedrock exception library "BEL." Once you get past the > >macros, BEL probably is closer to C++ exceptions for throwing actual > >objects and the like. > > > >But, if you like simplicity, UExceptions from PowerPlant is REAL clean. > > > >In both cases you'll probably be able to global GREP search and > >replaces for C++ exceptions. > > > >As for my personal preference... well I'm biased. :) > > The number one design criteria for BEL was to be "sufficiently" close to > the C++ standard. To achieve this we wanted application developers to be > able to write exception handling code in almost exactly the same style > they would use with C++ exceptions, with only minimal restrictions, and > that code written using BEL could be recompiled without changes and work > correctly when compilers support C++ exceptions. > > Alas, this criteria often precluded simplicity. > > As it happens, I spend a little of my spare time working on an idea I have > for an educational game. The exception library I wrote for it is even > simpler than PowerPlant's UExceptions. You see, I too believe that for > some applications, simplicity is more important than adherence to some > external standard. > > Jim Lloyd > afcjlloyd@aol.com -or- Jim_Lloyd@powertalk.apple.com -- Sean Parent sparent@mv.us.adobe.com "The critical driver of every successful project is its focused ruthlessness." Grady Booch +++++++++++++++++++++++++++ >From objfactory@aol.com (ObjFactory) Date: 1 Sep 1994 16:48:03 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , sparent@mv.us.adobe.com (Sean Parent) writes: >How does BEL handle the case of an auto-destruct member within another >auto-destruct derived class? That is, how do you handle: >class CFoo : CAutoDestruct { > ... >} >class CBar : CAutoDestruct { > CFoo fooMember; >} >void Test { > CBar bar; > CFoo foo; > Failure(); // or throw >} >You need to thread foo and bar onto your exception stack but not fooMember >(since it's destructor will get called when bar is destructed). You seem to have answered your own question. :) Bob Foster Object Factory +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 1 Sep 1994 18:13:09 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <345em3$a1d@search01.news.aol.com>, objfactory@aol.com (ObjFactory) writes: >In article , >sparent@mv.us.adobe.com (Sean Parent) writes: > >>How does BEL handle the case of an auto-destruct member within another >>auto-destruct derived class? That is, how do you handle: > >>class CFoo : CAutoDestruct { >> ... >>} >>class CBar : CAutoDestruct { >> CFoo fooMember; >>} > >>void Test { >> CBar bar; >> CFoo foo; >> Failure(); // or throw >>} > >>You need to thread foo and bar onto your exception stack but not >fooMember >>(since it's destructor will get called when bar is destructed). > >You seem to have answered your own question. :) > >Bob Foster >Object Factory No, BEL threads all three objects on the delete stack, but Sean's assumption that the fooMember is on the top of the stack is incorrect -- subobjects are constructed before their owning object. So, the stack order at the time of failure is: bar.fooMember; bar; foo; BEL first calls foo.CFoo::~CFoo(), then calls bar.CBar::~CBar. The destructor of CBar implicitly calls the destructor bar.fooMember.CFoo::~CFoo(). Inside this destructor is the START_DESTRUCTOR macro, which informs BEL to pop the deletestack entry for bar.fooMember. When the destructor returns to BEL, the delete stack is now empty, so BEL doesn't try to delete bar.fooMember. This strategy results in more items being placed onto the delete stack than is theoretically necessary, but less computation at runtime to determine if an entry should be pushed onto the stack or not. We therefore have traded off a little extra storage for faster code. Jim Lloyd - AFC JLloyd --------------------------- >From nick+@pitt.edu ( nick.c ) Subject: NIM on develop, as of 19 Date: Wed, 31 Aug 94 14:50:26 GMT Organization: The Pitt, Chemistry Folks: Someone was asking about the new NIM policy for _develop_, and what volumes would be on 19 that weren't on 18. Just got 19, and noticed the absense of the Old IM and beta QD GX books, but they added as "specials" Sound and Imaging with Quickdraw. Here's a running index of NIM I'm keeping for my own use, with 19 added. If you have issue 17 and up you have 15 of the NIM, with 7 (beta) QD GX books, the Human Interface guidelines and Old IM VI. BTW, I saw a CD at the bookstore with the Human Interface Guidelines and _Making it Macintosh_ on one CD for $49. Anyone checked this out? There has got to be more on it that just that, but the package wasn't very helpfull. -- nick develop NIM Index: ~~~~~~~~~~~~~~~~~~ volume 17: (last "comprehensive") ================================= NIM (presume "core") Toolbox Essentials More Mac Toolbox Memory Files NIM (unique this CD) Overview Processes Devices (Preview) Interapplication Comm QuickTime QuickTime Components Text QD GX 1.0b3 <- Note beta Environment & Utilities Extensions & Drivers Functin Index Graphics Objects Printing Typography Misc. Human Interface Guidelines Old IM volume VI volume 18: (first "reduced") ============================ NIM (presume "core") Toolbox Essentials More Mac Toolbox Memory Files NIM (unique this CD) PowerPC Numerics PowerPC System Software QD GX b3 <- Note beta Environment & Utilities Extensions & Drivers Functin Index Graphics Objects Printing Typography Misc. Human Interface Guidelines Old IM volume VI volume 19: (second "reduced") ============================= NIM (presume "core") Toolbox Essentials More Mac Toolbox Memory Files NIM (unique this CD) Imaging With Quickdraw Sound Misc. Human Interface Guidelines The README explanation of new NIM policy: ========================================= Why aren't all of the volumes of New Inside Macintosh on this issue of the Bookmark CD? Later this year, Apple and Addison-Wesley will release the New Inside Macintosh (NIM) CD. The NIM CD will offer all Inside Macintosh volumes to date in Apple DocViewer format, a complete cross reference, and numerous prebuilt DocViewer collections to allow easy querying across the information. All of the NIM books, if purchased separately, would cost several hundred dollars. The complete electronic set, however, will be offered at the introductory price of $99 (suggested retail price). To avoid conflicts, the introduction of this product has caused us to alter our practice of providing all NIM volumes on the Bookmark CD. Because the low subscription price for develop and the Bookmark cannot support the necessary enhancements, updates, and wider distribution of the electronic NIM product, we've had to make some concessions. The initial plan was to simply remove all NIM content from the Bookmark CD. We realize, however, that this content is extremely important to a great many of you and that it is necessary for your development projects. So, we've compromised a bit - beginning with this CD, the Bookmark will include a core set of NIM volumes. Additionally, each issue of the Bookmark CD will feature other volumes of NIM. The core set will stay fairly consistent, but the featured volumes will change on each subsequent issue of the Bookmark CD. While this solution may not be optimal for all develop subscribers, it was a compromise that was necessary to make. We hope, of course, that you feel that develop and the other content on the Bookmark CD is well worth the low subscription price. Sincerely, The develop and Bookmark CD team - - _/ _/ _/ _/_/_/ _/ _/ Interet: nick@pitt.edu _/_/ _/ _/ _/ _/ _/_/_/ eWorld: nick _/ _/_/ _/ _/ _/ _/ CIS: 71232,766 _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Wed, 31 Aug 94 15:15:54 GMT Organization: The Pitt, Chemistry This might be more usefull. -- nick - - develop NIM Index: ~~~~~~~~~~~~~~~~~~ NIM: Toolbox Essentials ANY develop (17up) NIM: More Mac Toolbox ANY develop (17up) NIM: Memory ANY develop (17up) NIM: Files ANY develop (17up) NIM: Overview 17 develop NIM: Processes 17 develop NIM: Devices (Preview) 17 develop NIM: Interapplication Comm 17 develop NIM: QuickTime 17 develop NIM: QuickTime Components 17 develop NIM: Text 17 develop NIM: Imaging With Quickdraw 19 develop NIM: Sound 19 develop NIM: PowerPC Numerics 18 develop NIM: PowerPC System Software 18 develop ___ 15 volumes NIM: QD/GX Environment & Utilities 17 or 18 develop NIM: QD/GX Extensions & Drivers 17 or 18 develop NIM: QD/GX Functin Index 17 or 18 develop NIM: QD/GX Graphics 17 or 18 develop NIM: QD/GX Objects 17 or 18 develop NIM: QD/GX Printing 17 or 18 develop NIM: QD/GX Typography 17 or 18 develop ___ 7 volumes Human Interface Guidelines ANY develop (17up) Old IM volume VI 17 or 18 develop _/ _/ _/ _/_/_/ _/ _/ Interet: nick@pitt.edu _/_/ _/ _/ _/ _/ _/_/_/ eWorld: nick _/ _/_/ _/ _/ _/ _/ CIS: 71232,766 _/ _/ _/ _/_/_/ _/ _/ --------------------------- >From jflet@dir.mcc.ac.uk (J. Fletcher) Subject: Need to Stop flashing Desktop when changing palletes Date: Tue, 30 Aug 1994 18:28:53 GMT Organization: University of Manchester, UK I'm writing a small database application which displays 256 colour picts in a window. As I swap in different pictures, I set a new optimised pallette to get the best colour scheme possible. The problem is that every time a set a new palatte, everything flashes all over the place, scroll bars, desktop pattern etc. What steps can I use to minimise these visual irritations? I've got some ideas but does Anybody have any ideas on how to implement the following :- 1) Get the Desktop pattern, save it, Set it to a black/white checkerboard 'grey' ands restore at app. quit time. 2) Force all screen windows to display their window bar/controls in neat black/white (like setting to black/white only in monitors CP) yet allowing colour drawing. Julian jflet@dir.mcc.ac.uk +++++++++++++++++++++++++++ >From radixinc@aol.com (RadixInc) Date: 30 Aug 1994 18:34:01 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , jflet@dir.mcc.ac.uk (J. Fletcher) writes: <> The problem is inherent in the way the Pallette Manager and color devices work. The video card for each device has a table with and RGB entry for each color entry--there are 256 of them on an 8-bit card. When you change pallettes the Pallette Manager tries to keep everything in order, but if there aren't enough available (unused) colors in the color table it has to remap some colors, and that's when you get the flash and weird colors. Both of the solutions you propose are, in my opinion, worse than the problem. You would be making changes that affect other programs, and there is no way to tell what that will do to them. Fiddling with the desktop pattern is not a good idea; that should be under the user's control. And how would you force other apps to get only B&W controls without installing a patch at startup time? Also what will you do when your app is switched out--flip everything back? That will cause more flashing than the pallette problem. If you can't use the System Pallette, you'll have to live with the colors flashing. Gregory Jorgensen Radix Consulting Inc. +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 31 Aug 1994 09:19:24 GMT Organization: The Information Workshop > In article , jflet@dir.mcc.ac.uk > (J. Fletcher) writes: > > < flashes all over the place, scroll bars, desktop pattern etc. The problem is that we've forgotten that "the flash" is the tradeoff we had accepted for the benefit of being able to use custom color tables, which usually yield stunning color accuracy and realism for a 256-color system. There are "ways" to minimize the effects. * Use a gamma fader to fade down the monitor between pictures to hide the flash. * Utilize a "backdrop window" with a gray pattern (alternate black and white pixels) to hide the desktop and other application's windows, since black and white are always in every custom color table, and will not flash. * Use a black backdrop which is traditional with the "slide show" options of most graphics applications. * Always make sure the display window is full screen. * Always create greedy palettes with all hte entries always set to pmTolerant + pmExplicity and a tolerance of zero, so that all other applications and the Finder are forced to black and white mode. Hopefully one of these suggestions will help. There are only 256 colors available in the hardware, and that's it. Mark Hanrek +++++++++++++++++++++++++++ >From carlf2@aol.com (CarlF2) Date: 31 Aug 1994 09:45:08 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , jflet@dir.mcc.ac.uk (J. Fletcher) writes: >I'm writing a small database application which displays 256 colour >picts in a window. As I swap in different pictures, I set a new >optimised pallette to get the best colour scheme possible. >The problem is that every time a set a new palatte, everything >flashes all over the place, scroll bars, desktop pattern etc. >......[deleted] Try using a single animated palette for your application, with every entry but black and white reserved for your application. (This will force the background applications to use B&W; if you can, you might leave some other entries for them to use as well.) Then when you want to change your colors, use AnimatePalette. Since no other application is using those entries, no flash will occur. Carl Fristrom Medfield MA --------------------------- >From sbill@informix.com (Bill Stackhouse) Subject: PPostEvent mouse events Date: 26 Aug 1994 20:25:24 GMT Organization: Informix Software, Inc. I am trying to post mouseUp and mouseDown events to my application using PPostEvent. After call PPostEvent, the what field is set to -1. The return value is 0. If I scan the event queue, there are no events. Even though I set the mouse position using low mem globals before the post, the where field has a different value than where the mouse is. What does it take to post mouse events? Thanks Bill +++++++++++++++++++++++++++ >From pbonner@pbcomputing.com (Pace Bonner) Date: 29 Aug 1994 18:01:19 GMT Organization: PB Computing In article <33lj3k$k08@infmx.informix.com>, sbill@informix.com (Bill Stackhouse) wrote: > I am trying to post mouseUp and mouseDown events to my application > using PPostEvent. After call PPostEvent, the what field is set to > -1. The return value is 0. If I scan the event queue, there are > no events. Even though I set the mouse position using low mem > globals before the post, the where field has a different value > than where the mouse is. > > What does it take to post mouse events? Try this code....It works for me. /* do a mouse down with correct cmd keys */ void MakeMouse(where,Mods) Point where; short Mods; { EvQEl *MyEventPtr; OsErr err; err = PPostEvent(mouseDown, 0, &MyEventPtr); MyEventPtr->evtQWhere.h = where.h; MyEventPtr->evtQWhere.v = where.v; MyEventPtr->evtQModifiers = Mods; err = PPostEvent(mouseUp, 0, &MyEventPtr); MyEventPtr->evtQWhere.h = where.h; MyEventPtr->evtQWhere.v = where.v; MyEventPtr->evtQModifiers = Mods; } +------------------------------------------------------------------------+ Pace Bonner Macintosh & Newton 512.335.1033 PB Computing Software Development 11100 Spear Oak Cove pbonner@pbcomputing.com Services Austin, TX 78759-7004 +------------------------------------------------------------------------+ +++++++++++++++++++++++++++ >From rollin@newton.apple.com (Keith Rollin) Date: Thu, 01 Sep 1994 19:42:04 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <33lj3k$k08@infmx.informix.com>, sbill@informix.com (Bill Stackhouse) wrote: >I am trying to post mouseUp and mouseDown events to my application >using PPostEvent. After call PPostEvent, the what field is set to >-1. The return value is 0. If I scan the event queue, there are >no events. Even though I set the mouse position using low mem >globals before the post, the where field has a different value >than where the mouse is. > >What does it take to post mouse events? This is the way I did it for Macintosh Programming Secrets: PPostEvent(mouseDown, 0, &qElPtr); qElPtr->evtQWhere = location; PPostEvent(mouseUp, 0, &qElPtr); qElPtr->evtQWhere = location; This code has always worked for me so far. I don't know if there are any A/UX issues. - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton --------------------------- >From U086753@adpdp2.lanl.gov (Jeff Dunning) Subject: Sample MacTcp Programs Date: Wed, 31 Aug 94 18:49:44 GMT Organization: Los Alamos National lab. I am looking for a couple of sample MacTcp programs. Where might some be found. Thanks. jsd@lanl.gov Jeff Dunning Los Alamos National Laboratory (505)667-8418 +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 31 Aug 1994 20:52:10 GMT Organization: The Information Workshop In article , jsd@lanl.gov wrote: > I am looking for a couple of sample MacTcp programs. > Where might some be found? Jeff, Here are some leads to resources... * Snippets/network section of Developer CD * Snippets section of ftp://ftp.apple.com/ * ftp://seeding.apple.com/mactcp/MacTCP_Dev_Kit * articles in "develop" magazine ftp://ftp.apple.com * source code archives everywhere ( start at nic.switch.ch ) This should help. :) Mark Hanrek +++++++++++++++++++++++++++ >From resnick@uiuc.edu (Pete Resnick) Date: Wed, 31 Aug 1994 18:16:38 -0500 Organization: University of Illinois at Urbana-Champaign In article , hanrek@cts.com (Mark Hanrek) wrote: >In article , jsd@lanl.gov wrote: > >> I am looking for a couple of sample MacTcp programs. >> Where might some be found? > >Here are some leads to resources... > > > * Snippets/network section of Developer CD > > * Snippets section of ftp://ftp.apple.com/ Eeeek!!! No, don't use those as examples. They're horribly written, useless pieces of code. They do synchronous I/O that will hang your machine. Just say no! > * ftp://seeding.apple.com/mactcp/MacTCP_Dev_Kit I don't believe there is any code in there. > * articles in "develop" magazine ftp://ftp.apple.com Don't look at the articles by Steve Falkenburg. Same warning as above on Snippets. > * source code archives everywhere > ( start at nic.switch.ch ) Also look at the NewsWatcher source code-- ftp://ftp.acns.nwu.edu//pub/newswatcher/source-20b9.sea.hqx And some of Peter Lewis's stuff (which should be lots of places). pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Doctoral Student - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@uiuc.edu --------------------------- >From jbeeghly@u.washington.edu (Jeff Beeghly) Subject: Selecting Window via menus Date: 31 Aug 1994 17:37:50 GMT Organization: University of Washington I'm creating an app that will contain multiple windows that are dynamically created and destroyed. I was keeping track of each window and it's data via a linked-list, but some friends of mine said that the "Mac way of handling multiple child windows is to use window reference values". So I converted my app from using linked-lists to using window references (not an easy task, mind you) and I'm finding out that this method has several setbacks compared to my original method, one of which is bringing a window to the front via menus. I was digging through THINK Reference and I found out that a Window Record contains a pointer to the next window. Well, I implemented a test into my program that displays the title of each child window: i = 0; whichWindow = FrontWindow(); while( whichWindow ) { GetWTitle(whichWindow, title); MoveTo(4, 10 + i); DrawString(title); whichWindow = (WindowPtr )(((WindowPeek )whichWindow)->nextWindow); i += 20; } I'm comming across 2 problems with this: 1) In my app, if I create 4 new windows, then invoke this operation, only the top window's (window #4) title is displayed. However, if I click on one of the other windows (causing the window to be moved to the front), then invoke this function, all four titles appear. Thus, if I was to use this implementation of getting a list of windows, it wouldn't be valid until one of the windows was topped. 2) Even when the items are displayed, they aren't displayed in the order in which they were created. In other words, if I create 4 new windows, then select window #1 to come up, I would expect to see the titles of win1, win2, win3, win4 displayed. Instead, I get win1, win4, win3, win2. I've tested this out a bit more, and it seems that the nextWindow points to the window underneath the current window, not the window that was created after the current window. This makes sense, but it doesn't help me out. What I was going to do was have a counter. If menu item #2 was selected, then that must mean that the second window needs to be topped. I would then imcrement the window pointer to the second created window and select it. Obviously this will not work. So right now I'm thinking about creating an array holding the window pointers and it would look something like this: menuItem = 2; // The third window needs to be topped winPtr = ourArray[ menuItem ]; SelectWindow( winPtr ); I was wondering: Is there an easier (and more standardised) way of doing this? Are there any code examples of this floating around? P.S. I have thought about comparing the string in the menu item with the title of the window. The problem is this: What do you do if you have two windows with the same title? Suppose you have two files from two different folders opened with the same name? I know that some apps add a number at the end of the name (MyDoc:1 vs MyDoc:2), but personally, I don't like doing that. +++++++++++++++++++++++++++ >From bb@lightside.com (Bob Bradley) Date: Tue, 30 Aug 1994 02:03:58 -0800 Organization: SS Software Inc. In article <342f5e$2mf@news.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: > I was digging through THINK Reference and I found out that a Window > Record contains a pointer to the next window. Well, I implemented a test > into my program that displays the title of each child window: > > i = 0; > whichWindow = FrontWindow(); > while( whichWindow ) > { > GetWTitle(whichWindow, title); > MoveTo(4, 10 + i); > DrawString(title); > whichWindow = (WindowPtr )(((WindowPeek )whichWindow)->nextWindow); > i += 20; > } > > I'm comming across 2 problems with this: > 1) In my app, if I create 4 new windows, then invoke this operation, only > the top window's (window #4) title is displayed. However, if I click on > one of the other windows (causing the window to be moved to the front), > then invoke this function, all four titles appear. Thus, if I was to use > this implementation of getting a list of windows, it wouldn't be valid > until one of the windows was topped. One probably you may be having is you may be drawing in a part of the window that isn't visible so it's not showing up. Accessing the nextWindow field of the WindowRecord doesn't select the window. Try moving your windows apart so you know the part you are trying to draw into is visible (normally you would always do any drawing from your updateEvt handler.). > 2) Even when the items are displayed, they aren't displayed in the order > in which they were created. In other words, if I create 4 new windows, > then select window #1 to come up, I would expect to see the titles of > win1, win2, win3, win4 displayed. Instead, I get win1, win4, win3, win2. > I've tested this out a bit more, and it seems that the nextWindow points > to the window underneath the current window, not the window that was created > after the current window. You are correct, nextWindow points to the window beneath the current window. You can use this to step down thru your windows one beneath the other. > This makes sense, but it doesn't help me out. What I was going to do was > have a counter. If menu item #2 was selected, then that must mean that > the second window needs to be topped. I would then imcrement the window > pointer to the second created window and select it. Obviously this will > not work. There is an example of keeping track of windows in a menu in the book Mac Programming Secrets (Keith Rollin and Scott Knaster) and the source is available almost everyway (usually named MPS 1.0.1). They keep track of the order which the windows were created and access the windows via menus in the same manner. Another way you could do it is to attach some private data to the window that contains a variable to keep track of which menuItem # the window goes with, then write a simple routine to step thru the window list (using nextWindow) checking each window's private data for the menuItem # you're trying to find. +++++++++++++++++++++++++++ >From Matt Slot Date: 1 Sep 1994 01:43:11 GMT Organization: University of Michigan Jeff Beeghly, jbeeghly@u.washington.edu writes: > I was wondering: Is there an easier (and more standardised) way of doing > this? Are there any code examples of this floating around? - --------- I have just written such a beast. Here is some sample code that handles a windows menu. The default menu looks like this... Windows -------------------- Show/Hide Floater #1 Show/Hide Floater #2 And I add a separator when I put any document windows underneath. Basically, I keep a Mac Queue of window information, that is ordered by window creation. As I make, destroy, or rename a window, I make the appropriate call and I am magically taken care of. I map the index of the menu item into the element of the queue. Share and enjoy Matt // * **************************************************************************** * // // * **************************************************************************** * // // Menu Item numbers #define kWindowsFloater1 1 #define kWindowsFloater2 2 #define kWindowsSeparator1 3 // * **************************************************************************** * // typedef struct WindowQElem { struct WindowQElem qLink; short qType; WindowPtr win; } WindowQElem, *WindowQElemPtr; // * **************************************************************************** * // QHdr gDocsOpen; // * **************************************************************************** * // void AddToWindowsMenu(WindowPtr win) { Str255 textBuff; MenuHandle theMenu; WindowQElemPtr wQPtr; theMenu = GetMenu(kWindowsMenuID); if (CountMItems(theMenu) < kWindowsSeparator1) InsMenuItem(theMenu, "\p-", kWindowsSeparator1); if (wQPtr = (WindowQElemPtr) NewPtrClear(sizeof(*wQPtr))) { wQPtr->win = win; Enqueue((QElemPtr) wQPtr, &gDocsOpen); AppendMenu(theMenu, "\p "); GetWTitle(win, textBuff); SetItem(theMenu, CountMItems(theMenu), textBuff); DrawMenuBar(); } } // * **************************************************************************** * // // * **************************************************************************** * // void ModifyFromWindowsMenu(WindowPtr win) { short i; Str255 textBuff; MenuHandle theMenu; WindowQElemPtr wQPtr; theMenu = GetMenu(kWindowsMenuID); for(wQPtr = (WindowQElemPtr) gDocsOpen.qHead, i=0; wQPtr; wQPtr = wQPtr->next, i++) if (wQPtr->win == win) { GetWTitle(win, textBuff); SetItem(theMenu, kWindowsFirstWinItem + i, textBuff); DrawMenuBar(); return; } } // * **************************************************************************** * // // * **************************************************************************** * // void RemoveFromWindowsMenu(WindowPtr win) { short i; Str255 textBuff; MenuHandle theMenu; WindowQElemPtr wQPtr; theMenu = GetMenu(kWindowsMenuID); for(wQPtr = (WindowQElemPtr) gDocsOpen.qHead, i=0; wQPtr; wQPtr = wQPtr->next, i++) if ((wQPtr->win == win) && ! Dequeue((QElemPtr) wQPtr, &gDocsOpen)) { DelMenuItem(theMenu, kWindowsFirstWinItem + i); if (CountMItems(theMenu) == kWindowsSeparator1) DelMenuItem(theMenu, kWindowsSeparator1); DrawMenuBar(); return; } } +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Thu, 01 Sep 1994 14:55:32 +0200 Organization: Royal Institute of Something or other In article <342f5e$2mf@news.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: >whichWindow = FrontWindow(); >while( whichWindow ) >{ > GetWTitle(whichWindow, title); > MoveTo(4, 10 + i); > DrawString(title); > whichWindow = (WindowPtr )(((WindowPeek )whichWindow)->nextWindow); > i += 20; >} This looks quite allright. >1) In my app, if I create 4 new windows, then invoke this operation, only >the top window's (window #4) title is displayed. However, if I click on >one of the other windows (causing the window to be moved to the front), >then invoke this function, all four titles appear. Thus, if I was to use This is strange. You're probably doing something wrong in creating and showing the windows. Or maybe you're now showing the windows? FrontWindow() returns the frontmost VISIBLE window. If you want to get the list of ALL windows, you have to use LMGetWindowList() and walk from there. >2) Even when the items are displayed, they aren't displayed in the order >in which they were created. In other words, if I create 4 new windows, >then select window #1 to come up, I would expect to see the titles of >win1, win2, win3, win4 displayed. Instead, I get win1, win4, win3, win2. Yes; the titles come up in the order they lie in the layers. If you create each new window on top of the preceeding window, it'll be before it in the list. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. --------------------------- >From phixus@netcom.com (Chris DeSalvo) Subject: SetDialogDefaultItem real? Date: Wed, 17 Aug 1994 08:28:47 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Think Reference mentions two traps: SetDialogDefaultItem and SetDialogCancelItem They are supposed to take care of button hiliting, outlining, and keyboard mapping of things like return/enter and escape. The traps are definied in the Universal Headers but they don't seem to work. They are not documented in the Dialog Manager section of NIM:Toolbox Essentials. Are these entries just place holders or is there some magic I have not learned to get them to work? Thanx Chris -- +-----------------------------------------------------------------+ | phixus@netcom.com | Macintosh: Changing the world, | | Chris De Salvo | one person at a time! | | Professional Mac Geek | ----------------------------- | | for MacPlay, Inc. | (I wish they'd hurry up!) | +-----------------------------------------------------------------+ Any opinions expressed, or implied, are my own! They should not be considered representative of the opinions or policies of my employer, MacPlay, a division of Interplay Productions, Inc. +++++++++++++++++++++++++++ >From spencerl@crl.com (Spencer Low) Date: Wed, 17 Aug 1994 12:24:56 -0800 Organization: LowTek Creations In article , phixus@netcom.com (Chris DeSalvo) wrote: > The traps are definied in the Universal Headers but they don't seem to > work. They are not documented in the Dialog Manager section of > NIM:Toolbox Essentials. Make sure that you don't have an extension that messes with ModalDialog filter procs - I was running the cool Escapade, but it seemed to stop this "default" behavior. If you have your own custom filter proc, make sure it calls the Standard proc with GetStdFilterProc(). Spencer (please correct me if I'm wrong..) +++++++++++++++++++++++++++ >From phixus@netcom.com (Chris DeSalvo) Date: Thu, 18 Aug 1994 11:03:40 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Spencer Low (spencerl@crl.com) wrote: : In article , phixus@netcom.com (Chris DeSalvo) : wrote: : > The traps are definied in the Universal Headers but they don't seem to : > work. They are not documented in the Dialog Manager section of : > NIM:Toolbox Essentials. : If you have your own custom filter proc, make sure it calls the Standard : proc with GetStdFilterProc(). That is probably the case, I do indeed have a custom event filter on this dialog. I will check it out. Thanx Chris -- +-----------------------------------------------------------------+ | phixus@netcom.com | Macintosh: Changing the world, | | Chris De Salvo | one person at a time! | | Professional Mac Geek | ----------------------------- | | for MacPlay, Inc. | (I wish they'd hurry up!) | +-----------------------------------------------------------------+ Any opinions expressed, or implied, are my own! They should not be considered representative of the opinions or policies of my employer, MacPlay, a division of Interplay Productions, Inc. +++++++++++++++++++++++++++ >From Chris Anthes Date: Thu, 18 Aug 1994 17:25:43 GMT Organization: DSEA In article Chris DeSalvo, phixus@netcom.com writes: >: If you have your own custom filter proc, make sure it calls the Standard >: proc with GetStdFilterProc(). > >That is probably the case, I do indeed have a custom event filter on >this dialog. I will check it out. Even if you are using a custom dialog filter, you can still use SetDialogDefaultItem, SetDialogCancelItem, and SetDialogTrackCursor. After you are done processing whatever you need to in your filter, make a call to the Standard Dialog Filter. This is all explained in detail in Mac Tech Note #304. Here is the code I use to handle custom dialog filters. This code differs slightly because I use returnVal to determine whether or not I need to call the standard dialog routines. I did this I think because I needed to filter Return & Enter and alias them to Tab when all of the data in my dialog wasn't entered (e.g. OK button grayed out). /***** myDialogFilter *****/ pascal Boolean myDialogFilter( DialogPtr theDialog, EventRecord *theDialogEvent, short *theDialogItem ) { ModalFilterProcPtr standardProc; Boolean returnVal = false; WindowPtr temp; // // Do all of your filter processing here... // // Go to the standard dialog filter if the event wasn't completely // handled if ( returnVal != true ) { GetPort( &temp ); SetPort( theDialog ); GetStdFilterProc( &standardProc ); returnVal = ((ModalFilterProcPtr)standardProc)( theDialog, theDialogEvent, theDialogItem ); SetPort( temp ); } return( returnVal ); } If you need some more info on this, send me an email. Cya L8r, Chris *************************************************************************** * * * * It's not the crime, * Chris Anthes (chrisa@dsea.com) * * It's not the thought, * --------------------------------------- * * It's not the deed, * DAINIPPON SCREEN ENGINEERING OF AMERICA * * * 3700 West Segerstrom Avenue * * IT'S IF YOU GET CAUGHT!!! * Santa Ana, CA 92704 * * * * *************************************************************************** +++++++++++++++++++++++++++ >From b-clark@nwu.edu (Brian Clark) Date: Wed, 17 Aug 1994 11:00:34 -0500 Organization: Northwestern University In article , phixus@netcom.com (Chris DeSalvo) wrote: > Think Reference mentions two traps: > > SetDialogDefaultItem and > SetDialogCancelItem > > Are these entries just place holders or is there some magic I have not > learned to get them to work? They work fine, but only when the standard system dialog filter proc is called (either because you haven't specified your own, or you explicitly call it from within your custom filter proc. +++++++++++++++++++++++++++ >From andrew@csgrad.cs.vt.edu (Andrew Southwick) Date: 19 Aug 1994 14:02:53 GMT Organization: IBM SWSD, Lexington, KY, USA b-clark@nwu.edu (Brian Clark) writes: > phixus@netcom.com (Chris DeSalvo) wrote: >> SetDialogDefaultItem and >> SetDialogCancelItem >They work fine, but only when the standard system dialog filter proc is >called (either because you haven't specified your own, or you explicitly >call it from within your custom filter proc. Also, these traps have to be defined by the headers that you are using. The headers that come with ThinkC up til (at least) 6.0 don't define them, so you have to do one of those void SetDialogDefaultItem( blah ) 0xYYYY; things at the top of your code. Sorry, don't have the trap number with me. It's mentioned in the ThinkC Programming Primer, though, and ThinkRef might have the trap numbers, too. Best Premises, andrew@csgrad.cs.vt.edu Andrew R. Southwick asouthwick@vnet.ibm.com +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Thu, 1 Sep 1994 16:52:43 GMT Organization: Apple Computer, Inc. In article Chris DeSalvo, phixus@netcom.com writes: >SetDialogDefaultItem and >SetDialogCancelItem > >The traps are definied in the Universal Headers but they don't seem to >work. They are not documented in the Dialog Manager section of >NIM:Toolbox Essentials. They were documented in the Technotes, but do to a race condition were never included with IM:Toolbox Essentials. During the PowerPC effort, we figured this out and added them to the headers. >Are these entries just place holders or is there some magic I have not >learned to get them to work? Yes they work, but you must supply a dialog filter proc which calls StdFilterProc in order to make them work as advertised. See technote TB 37 "Pending Update Perils". Whenever using modal dialogs it is best to always supply a filter proc to keep pending updates in your application from blocking background processing. The same technote which documents these calls explains this problem in more detail. Watch for an upcomming issue of MacTech, which will include "Sprocket", an application shell with code that deals with these calls. -Dave Falkenburg -Apple Computer, Inc. --------------------------- >From Bernd Mathiske Subject: Stack sniffer - how can I turn it off? Date: 16 Aug 1994 18:02:53 GMT Organization: Universitaet Hamburg Dear internet-community! Help! Do you know how I can get rid of the very annoying vbl-"stack sniffer" that causes error #28 when I move the stack pointer into the heap? I do not see the point why I should not have my stacks allocated where I like them to be, in particular if there are several of them between which I want to switch around, the latter allowing me to implement coroutines. Any idea anybody? % ====================================================== % Bernd Mathiske % voice: +49-40/54715-330 % e-mail: mathiske@dbis1.informatik.uni-hamburg.de % snail mail: Universitaet Hamburg % Vogt-Koelln-Strasse 30 % D-22527 Hamburg, Deutschland % ====================================================== +++++++++++++++++++++++++++ >From bobo@reed.edu (Eric Bowman) Date: 17 Aug 1994 04:24:16 GMT Organization: Reed College, Portland, Oregon In article <32qv0d$7t1@rzsun02.rrz.uni-hamburg.de>, Bernd Mathiske wrote: >Do you know how I can get rid of the very annoying vbl-"stack sniffer" >that causes error #28 when I move the stack pointer into the heap? >I do not see the point why I should not have my stacks allocated >where I like them to be, in particular if there are several of them >between which I want to switch around, the latter allowing me to >implement coroutines. To disable the stack sniffer, Ptr oldTopOfStack = LMGetStackLowPoint(); LMSetStackLowPoint(NULL); To undo the damage, LMSetStackLowPoint(oldTopOfStack); cheers, bobo +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Wed, 17 Aug 1994 17:20:16 +0800 Organization: Department of Computer Science, The University of Western Australia In article <32qv0d$7t1@rzsun02.rrz.uni-hamburg.de>, Bernd Mathiske wrote: >Do you know how I can get rid of the very annoying vbl-"stack sniffer" >that causes error #28 when I move the stack pointer into the heap? >I do not see the point why I should not have my stacks allocated >where I like them to be, in particular if there are several of them >between which I want to switch around, the latter allowing me to >implement coroutines. No it won't (: There are problems with putting the stack in the heap, specifically a number of toolbox calls expect the stack to be above the heap and get very upset when it isn't. If you want to do co-routines, use the Thread Manager. btw You can disable the stack sniffer by putting 0 into the low memory global StkLowPt. I've also seen Apple code that disables it by patching SysError and preventing error 28 getting through (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Wed, 17 Aug 1994 17:54:25 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Quinn "The Eskimo!" wrote: >In article <32qv0d$7t1@rzsun02.rrz.uni-hamburg.de>, Bernd Mathiske > wrote: > >>Do you know how I can get rid of the very annoying vbl-"stack sniffer" >>that causes error #28 when I move the stack pointer into the heap? >>I do not see the point why I should not have my stacks allocated >>where I like them to be, in particular if there are several of them >>between which I want to switch around, the latter allowing me to >>implement coroutines. > >No it won't (: There are problems with putting the stack in the heap, >specifically a number of toolbox calls expect the stack to be above the >heap and get very upset when it isn't. If you want to do co-routines, use >the Thread Manager. You can fool them into being happy by setting 3 low-memory globals. It's tricky though. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From sparent@mv.us.adobe.com (Sean Parent) Date: Wed, 17 Aug 1994 22:48:18 GMT Organization: Adobe Systems Incorporated It is tricky to fool the toolbox because one of the lowmem globals that has to be set is the HiHeapMark (thus confusing the memory manager). The cleanest way (other than using the Thread Manager) that I have seen is to just BlockMoveData your alternate stacks into the stack. It costs a few extra cycles but can save you a boat load of time getting other stuff working. In article , ari@world.std.com (Ari I Halberstadt) wrote: > In article , > Quinn "The Eskimo!" wrote: > >In article <32qv0d$7t1@rzsun02.rrz.uni-hamburg.de>, Bernd Mathiske > > wrote: > > > >>Do you know how I can get rid of the very annoying vbl-"stack sniffer" > >>that causes error #28 when I move the stack pointer into the heap? > >>I do not see the point why I should not have my stacks allocated > >>where I like them to be, in particular if there are several of them > >>between which I want to switch around, the latter allowing me to > >>implement coroutines. > > > >No it won't (: There are problems with putting the stack in the heap, > >specifically a number of toolbox calls expect the stack to be above the > >heap and get very upset when it isn't. If you want to do co-routines, use > >the Thread Manager. > > You can fool them into being happy by setting 3 low-memory globals. > It's tricky though. > -- > Ari Halberstadt ari@world.std.com > One generation passes away, and another generation comes: but the > earth abides for ever. -- Ecclesiastes, 1:4. -- Sean Parent sparent@mv.us.adobe.com "The critical driver of every successful project is its focused ruthlessness." Grady Booch +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Thu, 18 Aug 1994 03:00:21 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Sean Parent wrote: >It is tricky to fool the toolbox because one of the lowmem globals that >has to be set is the HiHeapMark (thus confusing the memory manager). The >cleanest way (other than using the Thread Manager) that I have seen is to >just BlockMoveData your alternate stacks into the stack. It costs a few >extra cycles but can save you a boat load of time getting other stuff >working. There is a third solution. It is very similar to the Thread Manager, but has context switch times from over 2 to nearly 4 times faster than the Thread Manager. It's my free Thread Library (not to be confused with Apple's ThreadsLib). It's called ThreadLib-10d4.hqx (or some similar name, depending on the archive), includes full source code, and is available from info-mac mirrors in the dev/src directory, and from the alt.sources.mac archive. I tested it under emulation on a PowerPC, and it ran fine. It has been tested on a Plus, Quadra 950, and PowerPC, with systems 6.0.5, 7Pro, and whatever the PowerPC needed (7.1.1, or something like that). My Thread Library does not run in native PPC mode, and does not support preemptive threads. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From Clinton Bauder Date: Tue, 23 Aug 1994 19:28:07 GMT Organization: Apple Computer Inc. In article <32qv0d$7t1@rzsun02.rrz.uni-hamburg.de> Bernd Mathiske, mathiske@dbis1.informatik.uni-hamburg.de writes: >Do you know how I can get rid of the very annoying vbl-"stack sniffer" >that causes error #28 when I move the stack pointer into the heap? >I do not see the point why I should not have my stacks allocated >where I like them to be, in particular if there are several of them >between which I want to switch around, the latter allowing me to >implement coroutines. > >Any idea anybody? You should use the Thread Manager if you can. If you can't - say your code is a driver or something - then you can disable the Stack Sniffer by clearing the low memory global StkLowPt (0x110 - 32 bits). Of course when you are done using your private stack you should put it back to what it was. Also your stack should be at least 4K in size plus whatever you expect to use in your own code. This should be sufficient for most interrupt code which might end up using your stack. Note that this is not the worlds most forward compatible kind of programming but if you can accept the possibility of future incompatibility then this is a useful technique. Clinton - ------------------------------------------------------------- Clinton Bauder | Opinions expressed are very likely to SCSI Grunt and Chief | be entirely different from the official Herpetoculturist | party line of Apple Computer Inc. Apple Computer Inc. | Support your local herp society. - ------------------------------------------------------------- +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Wed, 24 Aug 1994 01:37:38 GMT Organization: The World Public Access UNIX, Brookline, MA In article <1994Aug23.192807.4763@gallant.apple.com>, Clinton Bauder wrote: >it was. Also your stack should be at least 4K in size plus whatever you >expect to use in your own code. This should be sufficient for most >interrupt code which might end up using your stack. Note that this is Actually, you want at least MinStack bytes, plus whatever your app will need. MinStack is a low-mem global. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Wed, 31 Aug 1994 16:44:55 GMT Organization: Apple Computer, Inc. In article <32qv0d$7t1@rzsun02.rrz.uni-hamburg.de> Bernd Mathiske, mathiske@dbis1.informatik.uni-hamburg.de writes: >Dear internet-community! > >Help! >Do you know how I can get rid of the very annoying vbl-"stack sniffer" >that causes error #28 when I move the stack pointer into the heap? >I do not see the point why I should not have my stacks allocated >where I like them to be, in particular if there are several of them >between which I want to switch around, the latter allowing me to >implement coroutines. > >Any idea anybody? The stack sniffer can be turned off by zeroing out STKLOWPT. However, this isn't enough to keep the Macintosh working if you plan on calling the toolbox from your coroutines. The supported way of doing coroutines on the Macintosh is to use the Thread Manager. The Thread Manager is available in the form of an extension for System 7.0 or later, and has been rolled into the base system software in System 7.5. The current version of the extension is 2.0.1, which includes support for PowerPC machines. -Dave Falkenburg -Apple Computer, Inc. --------------------------- End of C.S.M.P. Digest **********************