jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/14/89)
In article <64@sppy00.UUCP> jmv@sppy00.UUCP (Jim Vickroy) writes: >I hope I'm not the only one who has felt the ultimate frustration in moving >MS-DOS to the Mac. So I'm going to try tapping this wealth of information: > >Do anyone out there have a blow-by-blow procedure to: >1. Change the desktop icons from the defaults to custom icons? The method for doing this is described in Inside Macintosh II in the Finder section. Unfortunately this section is not particularly clearly written, and what should be one of the easier hurdles in creating a Mac application becomes a multiple-hour exercise in confusion for a beginning Mac programmer. If someone doesn't post a step-by-step description of how to do this in the next couple of days, I will. >2. Change the font of text in a window? > Easy. Use TextFont(fontnumber). See the QuickDraw chapter in IM I. >If these are really stupid questions please bare with me... (Taking off my clothes ... :-)) Seriously, folks. These are simple questions but unfortunately not stupid questions in the Mac programming world. I find it immensely frustrating sometimes trying to discern the *simplest* things about the Toolbox and OS calls. There isn't even a good description of what a complex, real-world event loop should look like in Apple's documentation. For example: IM I has a TextEdit chapter. But where does it say that lines in the TextEdit record are terminated in carriage returns? (What should I assume? Could be LFs, NULLs, whatever!) Where does it say whether the LineStarts are 0- or 1-based? (They're 0-based). Basic stuff, NOT documented in the primary reference. I've said before that I think the Tech Notes are an abomination. IM should have been a looseleaf set from the start. Tech Notes should exist only briefly between updates to IM. There should be no IM 4 and no IM 5 and thus no need for the silly cross-reference volumn. Furthermore, there should be GOOD examples of complex Pascal and C event loops available from Apple (in a book!)--something like a Macintosh Application Programmer's Guide. Not piecemeal (Programming for Multifinder-- yuck!), but a good, solid, systematic introduction to the event loop programming style, + common idiomatic techniques, readily available. You can't expect every future Mac applications programmer to be able to attend a college class, nor expect him/her to want to spend his time trying to find a good non-Apple reference (difficult since most of them are either inaccurate or out-of-date). After 10 years of programming on everything from TRS-80 Model 1s to 11/780s running VMS and 4.3BSD, I've found the Mac the most difficult and irritating environment of all to program in. I've also found the end results the most satisfying, which is why I put up with all the bull**** in the first place. But still ... what do we user/programmers have to do to get decent reference materials from Apple? Why do we join APDA, collect inaccurate/ inadequate textbooks, buy $200 of separately-bound IM and related reference works, collect Tech Notes, post questions on USENET, then STILL run into undocumented "features", bugs, inaccurate documentation (the new Sound Manager!), and inconsistencies? -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
jmv@sppy00.UUCP (Jim Vickroy) (03/14/89)
In article <3949@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes:
=>beginning Mac programmer. If someone doesn't post a step-by-step
=>description of how to do this in the next couple of days, I will.
I have received several replys to this problem but haven't had a chance to
try them yet. I will post what works when I get that chance.
=>
=>>2. Change the font of text in a window?
=>>
=>Easy. Use TextFont(fontnumber). See the QuickDraw chapter in IM I.
I tried this but the font didn't change. I think, however, the problem is
mine because I pass to TextFont what I get from LoWord. Probably wrong.
[ commentary deleted for space ]
I can't agree with you more. I feel I'm a fairly accomplished programmer
(6+ years professionally on mainframes to micros) but I haven't been more
frustrated than trying to figure out these two seemingly simple procedures.
Another problem I have is the hundreds of dollars you have to spend just
accumulating the necessary documentation (Apple and other publishers) so
you can write the simplist of applications.
BTW, I just ordered the looseleaf edition of Inside Macintosh vI - V
because the IM's I was using were borrowed. The price tag: $130. (from APDA)
jim
--
!==================================================================!=========!
! Jim Vickroy | cbosgd!osu-cis!sppy00!jmv !/././././!
! Online Computer Library Center, Inc. |---------------------------!././././.!
! Dublin, Ohio 43017 | jmv@sppy00 !/././././!
!------------------------------------------------------------------!././././.!
! "That voodoo stuff don't do nothin' for me" -jrr !/././././!
!==================================================================!=========!bin@primate.wisc.edu (Brain in Neutral) (03/14/89)
Inside Mac isn't so bad. (But then, I like to read manuals). Consider trying to get along without it. However, the comments about lack of source code in the documentation are correct. What any beginning programmer needs to do is get his hands on the source code for already written applications and study THAT. If you're trying to understand scroll bars, get source for an application that uses 'em and study it (with IM at your side). Programming with just reference manuals is for the birds. Of course, you have to be able to get source code, and since HARDLY ANYONE POSTS ANY --- STILL!!! --- you may be out of luck. Paul DuBois dubois@primate.wisc.edu rhesus!dubois bin@primate.wisc.edu rhesus!bin
stores@unix.SRI.COM (Matt Mora) (03/15/89)
In article <3949@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >Seriously, folks. These are simple questions but unfortunately not stupid >questions in the Mac programming world. I find it immensely frustrating >sometimes trying to discern the *simplest* things about the Toolbox and >OS calls. There isn't even a good description of what a complex, real-world >event loop should look like in Apple's documentation. > >For example: IM I has a TextEdit chapter. But where does it say that >lines in the TextEdit record are terminated in carriage returns? (What >should I assume? Could be LFs, NULLs, whatever!) Where does it say whether some stuff deleted >Furthermore, there should be GOOD examples of complex Pascal and C event >loops available from Apple (in a book!)--something like a Macintosh >Application Programmer's Guide. Not piecemeal (Programming for Multifinder-- >yuck!), but a good, solid, systematic introduction to the event loop >programming style, + common idiomatic techniques, readily available. You more stuff deleted >But still ... what do we user/programmers have to do to get decent reference >materials from Apple? Why do we join APDA, collect inaccurate/ Maybe some of us on the net can draft a book (article,letter or what ever you want to call it) on the subject of beginning macintosh programming and call it "Everything that you wanted to know about mac programming but were afraid to ask!". It could include up-to-date info on the Mac and source code examples. some snippits from the net about gotchas and bugs. That way if someone asks on the net about beginning programming on the mac we could just email them a copy. just an Idea :-) Matt Mora SRI International
jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/15/89)
In article <169@indri.primate.wisc.edu> bin@primate.wisc.edu writes: > >Of course, you have to be able to get source code, and since HARDLY >ANYONE POSTS ANY --- STILL!!! --- you may be out of luck. > >Paul DuBois >dubois@primate.wisc.edu rhesus!dubois >bin@primate.wisc.edu rhesus!bin ( Hi, Paul ... ) Well, sure, so far as IM goes, it's not bad. My point is just that it doesn't go far enough. The lack of source code is miserable, especially for us 1980s-style "C" programmers. (Well, OK, I suppose you're still a Pascal type yourself; nevertheless ...) I've heard from a few people since my last posting who seem to concur that the lack of *real* programming references is acute, and that there is not much of a consensus, additionally, as to how one should organize a Mac application internally, particularly the event loop. I'd like to suggest that we USENET-ters produce a "Mac Programming Guide." In particular, we should produce a document describing, in detail, a good, workable event loop with support for everything; in addition, we should come up with a collection of efficient paradigms for dialog handling, menu item dimming/hilighting, file save & load, text editing, etc. Also, we should try to explore the general issue of event-driven programming as opposed to "conventional" programming, and what the differences between the assembler, Pascal, C and (hopefully!) C++ programming environments are. I'll be more than happy to take comments and suggestions by e-mail and post them, and I might be willing to organize and edit the project, since I have considerable interest in it. Any takers? -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
brecher@well.UUCP (Steve Brecher) (03/15/89)
In article <3949@ece-csc.UUCP>, jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: > IM I has a TextEdit chapter. But where does it say that lines in the > TextEdit record are terminated in carriage returns? IM I-375: "Normally ... the text automatically wraps around ... . A new line also begins where explicitly specified by a Return character in the text." (See also I-378, last para.) That is, "normally" there are no terminators at the end of each line; this would be the case for, e.g., most dialog box static text items -- TextEdit takes care of formatting the text with respect to lines, and calculates the contents of the lineStarts array based on the width of the destination rectangle. For line-oriented text, e.g., most program source code, there would be a CR at the end of each line of text. > Where does it say whether the LineStarts are 0- or 1-based? IM I-377: "lineStarts: ARRAY[0..16000] OF INTEGER" (see also I-379, last para.) -- brecher@well.UUCP (Steve Brecher)
sarrel@tut.cis.ohio-state.edu (Marc Sarrel) (03/15/89)
Just a meta-comment here. Could you please restrict yourselves to comp.sys.mac.programmer? That's what it's there for. Thank you for your support. --marc
stores@unix.SRI.COM (Matt Mora) (03/16/89)
In article <67@sppy00.UUCP> jmv@sppy00.UUCP (Jim Vickroy) writes: >In article <3949@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >=>beginning Mac programmer. If someone doesn't post a step-by-step >=>description of how to do this in the next couple of days, I will. > >I have received several replys to this problem but haven't had a chance to >try them yet. I will post what works when I get that chance. > >=> >=>>2. Change the font of text in a window? >=>> >=>Easy. Use TextFont(fontnumber). See the QuickDraw chapter in IM I. > >I tried this but the font didn't change. I think, however, the problem is >mine because I pass to TextFont what I get from LoWord. Probably wrong. > >[ commentary deleted for space ] > >I can't agree with you more. I feel I'm a fairly accomplished programmer >(6+ years professionally on mainframes to micros) but I haven't been more >frustrated than trying to figure out these two seemingly simple procedures. > If you are tring to get the fontnumber from a menu to change the textfont of a grafport then here is an example: menuitem:=LoWord(the_menu_item_selected) GetItem(menuhandle, menuitem, fontname); GetFNum(fontname, fontnum); TextFont(fontnum); but if you are tring to change a TE Font I had a problem with this in LSP. I think the it would be procedure CalcText; {procedure to fix line spacing} var fInfo: FontInfo; begin GetFontInfo(fInfo); with fInfo, textH^^ do begin lineHeight := ascent + descent + leading; fontAscent := ascent end; end; menuitem:=LoWord(the_menu_item_selected) GetItem(menuhandle, menuitem, fontname); GetFNum(fontname, fontnum); textH^^.txFont := fontnum; textfont(fontnum); CalcText; {call this to fix the line spacing} TECalText(textH); InvalRect(myWindow^.portrect); {force an update} I Hope This Helps Matt Mora SRI International
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (03/16/89)
In article <169@indri.primate.wisc.edu> bin@primate.wisc.edu writes: > (stuff deleted)> >Of course, you have to be able to get source code, and since HARDLY >ANYONE POSTS ANY --- STILL!!! --- you may be out of luck. > Or you can go out and get "Macintosh Revealed" Volumes I and II by Stephen Chericoff. These are available almost anywhere that sells computer books. The second volume takes you through the implementation of a text editing program that supports the Mac user interface. The two volumes together shouldn't cost more than around $50. They document the toolbox well enough that you can get away with not buying Inside Macintosh unless you are really doing some major thing or something esoteric (relatively speaking). Source code disks are available from the publisher (Hayden). The source is in Pascal. Printing is not discussed but Volume 3 (just released) covers this and some other things. Its not really essential (IMHO) unless you neep to print. I have no connection with etc, etc... ______________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) | {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/16/89)
In article <18784@srcsip.UUCP> mnkonar@gorby.UUCP (Murat N. Konar) writes: >In article <169@indri.primate.wisc.edu> bin@primate.wisc.edu writes: >> (stuff deleted)> >>Of course, you have to be able to get source code, and since HARDLY >>ANYONE POSTS ANY --- STILL!!! --- you may be out of luck. > > Or you can go out and get "Macintosh Revealed" Volumes I and II by >Stephen Chericoff. These are available almost anywhere that sells >computer books. The second volume takes you through the >implementation of a text editing program that supports the Mac >user interface. The two volumes together shouldn't cost more than >around $50. They document the toolbox well enough that you can >get away with not buying Inside Macintosh unless you are really >doing some major thing or something esoteric (relatively speaking). > I have Volumes I and II and I am ambivalent about them. I find them to have very little use to me in general since they cover only beginning and low-to-intermediate level topics, and do not address most of my "problem" areas, i.e., those that are vaguely or inadequately documented in Inside Macintosh. They are also, of course, Pascal-based, and you can really get screwed trying to figure out how to (for example) declare callback routines in "C" from descriptions of similar Pascal routines. There are *no* good "C" programming references for the Mac, unless one has been released in the past few months. I might look at MR Volume III, but if it's as leisurely-paced as the first two volumes, I'll pass on it. I'd recommend the books only if you are a novice programmer who will be working in Pascal, and would recommend you spring for at least the first four volumes of IM while you're at it, since you will run into issues MR doesn't cover as soon as you start fiddling around with controls, printing, complicated dialogs, file operations, etc. To a "C" programmer I'd recommend Lightspeed C (or MPW) and all the Tech Notes and examples you can get your hands on. Look at TransSkel--better yet, use it. (But we have to write a non-TextEdit-based editor!) -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
hammersslammers1@oxy.edu (David J. Harr) (03/16/89)
Hear! Hear! I absolutely agree! Let's take it upon ourselves to write the definitive Macintosh Programmers Guide (available at your local bookstores for the low, low price of only $79.95 [softback]). I think that would be a true example of the spirit of USENET. BTW, Joseph, if you do get chosen to do this and need any help, let me know. I may not know much about how to program the Mac, but I think I can handle organizing material for a book.
stores@unix.SRI.COM (Matt Mora) (03/17/89)
In article <3955@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >In article <169@indri.primate.wisc.edu> bin@primate.wisc.edu writes: >> >>Of course, you have to be able to get source code, and since HARDLY >>ANYONE POSTS ANY --- STILL!!! --- you may be out of luck. >> > >I've heard from a few people since my last posting who seem to concur that >the lack of *real* programming references is acute, and that there is not >much of a consensus, additionally, as to how one should organize a Mac >application internally, particularly the event loop. > >I'd like to suggest that we USENET-ters produce a "Mac Programming Guide." >In particular, we should produce a document describing, in detail, a good, >workable event loop with support for everything; in addition, we should come >up with a collection of efficient paradigms for dialog handling, menu >item dimming/hilighting, file save & load, text editing, etc. Also, we should >try to explore the general issue of event-driven programming as opposed to Don't for get about the dirty word "scrolling". I think it would be great to have a guide to get a handle on the aspects of programming the mac. I remember someone saying that before you can write you have to know how to read. That goes for any language (be it english or any computer language). let's say you wanted to write a MDEF. You could scan the back issues of Mactutor to try to find a good example (if you have all the volumes) only to find that the author wrote it in a different language. Instead you can pull out your trusty "Mac Programming Guide" look for the chapter MDEF's and there you have it. Examples in of mdef's in C, Pascal, asm or whatever. Also at the end of the chapter will be a Gothcas and bug report. Well I better stop my dreaming. (is it that close to april fools? :-)) Well if anyones counting call this a yes vote. Matt Mora SRI International
maw@romeo.cs.duke.edu (Max A. Woodbury) (03/17/89)
In article <3955@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >In article <169@indri.primate.wisc.edu> bin@primate.wisc.edu writes: >> >>Of course, you have to be able to get source code, and since HARDLY >>ANYONE POSTS ANY --- STILL!!! --- you may be out of luck. >> > >I've heard from a few people since my last posting who seem to concur that >the lack of *real* programming references is acute, and that there is not >much of a consensus, additionally, as to how one should organize a Mac >application internally, particularly the event loop. > >I'd like to suggest that we USENET-ters produce a "Mac Programming Guide." >In particular, we should produce a document describing, in detail, a good, >workable event loop with support for everything; in addition, we should come >up with a collection of efficient paradigms for dialog handling, menu >item dimming/hilighting, file save & load, text editing, etc. After two years of playing/hacking at Mac Programming, we (my Mac specialist and I) have a simple "blank" application in LSC which we could send off to whomever is collecting the stuff (or even post [gasp!]) in comp.sources.mac if the interest warrants it. I handles a simple one window situation WITHOUT controls, but it is fairly clear. I know it could be better, and more powerful, etc. but we haven't the time to research everything and still get the necessary programming done. Let me know your feelings. -- Greg Woodbury (using the account of Max Woodbury) System Manager(UNIX) and System Programmer Duke U. Center for Demographic Studies (919)684 6126 (after 1pm EST) US Mail: 2117 Campus Drive; Durham NC 27706 USA UUCP: ...mcnc!ecsgate!dukeac!dukcds!ggw or ...duke!dukcds!ggw Internet: ggw%dukcds@cs.duke.edu or ggw@dukeac.ac.duke.edu
hpoppe@bierstadt.ucar.edu (Herb Poppe) (03/17/89)
In article <24945@tiger.oxy.edu> hammersslammers1@oxy.edu (David J. Harr) writes: >Hear! Hear! I absolutely agree! Let's take it upon ourselves to write the >definitive Macintosh Programmers Guide (available at your local bookstores >for the low, low price of only $79.95 [softback]). I think that would be a >true example of the spirit of USENET. BTW, Joseph, if you do get chosen to >do this and need any help, let me know. I may not know much about how to >program the Mac, but I think I can handle organizing material for a book. ^^^^ Book, smook. Its about time we have an electronic version! How about a Hypercard stack with references linked from here to next Wednesday. You know, where you are reading a card that has the description of a record type, and you can click on a field and it takes you to the card containing the type definiton of that field. There would be a "gotcha" card which would be the starting point for a thread of links to all the caveats that are sprinkled throughout IM. You get the idea. Then have BMUG release it on CD-ROM with a copy on sumex (or your favorite net archive server). Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (03/18/89)
In article <13892@duke.cs.duke.edu> ggw%dukcds@cs.duke.edu (Greg Woodbury) writes: >After two years of playing/hacking at Mac Programming, we (my Mac specialist >and I) have a simple "blank" application in LSC which we could send off to >whomever is collecting the stuff (or even post [gasp!]) in comp.sources.mac >if the interest warrants it. I handles a simple one window situation WITHOUT >controls, but it is fairly clear. I know it could be better, and more >powerful, etc. but we haven't the time to research everything and still get >the necessary programming done. Let me know your feelings. I highly recommend TransSkel, by Paul DuBois at Wisconsin. It is available in Pascal and C versions, public domain, at your favorite archive site. It has the event loop and basic multi-window handling code. There are also extensions, TransEdit and TransDisplay, that provide additional features. Also public domain. Version 2.0 is current. Marc Kaufman (kaufman@polya.stanford.edu)
gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (03/18/89)
In article <1595@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: >Book, smook. Its about time we have an electronic version! How about a >Hypercard stack with references linked from here to next Wednesday. Nice idea, but there is one big problem - memory. Remember that this whole thread started with help for beginning programmers. Now you want them to have to be running HC whenever they are programming. So you need to be running MF. And have 2.5 Megs or more. And a large screen (since many times I want to look at my code as well as at the reference). And a CD rom with this all on. At work I've got a IIx with lots of memory (and I could steal a CD rom), so this would be great and wonderful. But at home, I've just got a Mac Plus, One Meg - which is where I do most of my development work. There is no way that I (and I suspect many programmers, especially beginners) could use this system. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "Whether you like it, or don't like it, sit | - gandreas@ub.d.umn.edu - = = back and take a look at it, because it's the | Glenn Andreas = = best going today! WOOOOoooo!" - Ric Flair | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/18/89)
In article <1595@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: >In article <24945@tiger.oxy.edu> hammersslammers1@oxy.edu (David J. Harr) writes: >>Hear! Hear! I absolutely agree! Let's take it upon ourselves to write the >>definitive Macintosh Programmers Guide (available at your local bookstores >... ^^^^ >Book, smook. Its about time we have an electronic version! How about a >Hypercard stack with references linked from here to next Wednesday. You ... This is another option, but it would have to be in addition to the normal "book" form. Unless you have the hypercard DA it's not all that convenient to browse a stack while you're programming. It's certainly more convenient (to me, at least) to browse through a well-indexed book. -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
jackiw@cs.swarthmore.edu (Nick Jackiw) (03/18/89)
In article <28672@sri-unix.SRI.COM> stores@unix.sri.com (Matt Mora) writes: > let's say you wanted to write a > MDEF. You could scan the back issues of Mactutor to try to > find a good example (if you have all the volumes) only to find > that the author wrote it in a different language. Instead you > can pull out your trusty "Mac Programming Guide" look for the > chapter MDEF's and there you have it. Examples in of mdef's in > C, Pascal, asm or whatever. Also at the end of the chapter will > be a Gothcas and bug report. > > Matt Mora > SRI International This "topic-by-topic" approach seems like it might actually work (for great examples of failed USENET-collaborative-integrated-systems, read rec.games.programmer, etc.). Someone needs to be in charge. S/he, with the help of comp.mac.programmer, compiles a list of topics, many of them gathered into a tutorial about a novice's-approach (i. e. development systems -> event loop programming -> resources -> etc.); some of them those topics which are more advanced but are spread out over 1,200 pages of Inside Mac+tech notes (e. g. MDEFs, the complete guide to offscreen bitmaps, etc.). These are put up for grabs; people who want to write the appropriate chapters grab them. Put maybe 5 or 6 people per chapter. Among themselves, they break it into subtasks, discuss its form and contents, co-author and/or co-edit it, write (review and debug) some source-examples, etc. This gets sent back to the Director, who with his/her chosen community of editors decide whether they like it, can do with it, or hate it. In the first case, they revise it and put it into a format similar to the rest of the contributions (maybe they need to work up some guidelines before we write chapters); in the second, they send it back with their objections; in the third, they trash it and put the topic back on the net as up for grabs. Does the original poster of this chain have the expertise and time to consider this? If not, does anyone out there want to? We need programmers AND PEOPLE WHO CAN WRITE. I'm in for exactly-as-long-as-this-remains-a-nonprofit-venture. -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ "Ah...I've got this CHRONIC pain." _True Believer_
lipa@polya.Stanford.EDU (William J. Lipa) (03/18/89)
In article <13892@duke.cs.duke.edu> ggw%dukcds@cs.duke.edu (Greg Woodbury) writes: >After two years of playing/hacking at Mac Programming, we (my Mac specialist >and I) have a simple "blank" application in LSC which we could send off to >whomever is collecting the stuff (or even post [gasp!]) in comp.sources.mac >if the interest warrants it. I would like to encourage any people with useful or interesting source code to send it to the Info-Mac archives at sumex-aim.stanford.edu. As a moderator, one of my goals is to make the source directory at sumex a more useful resource. To make your source code useful to others requires a few things. It should have a clear explanation attached as to what the code is intended to do. It should be as modular as possible so it can be dropped into other programs. Weird OS stuff should be commented a little. And it should have your e-mail address so that you can take advantage of the net's beta-testing ability while the net takes advantage of your debugging skills. Please don't be shy. The more examples there are, the easier programming the Mac will be. Bill Lipa Info-Mac PS. The address for submissions is info-mac@sumex-aim.stanford.edu.
bmug@garnet.berkeley.edu (BMUG) (03/18/89)
In article <1595@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: >In article <24945@tiger.oxy.edu> hammersslammers1@oxy.edu (David J. Harr) writes: >>Hear! Hear! I absolutely agree! Let's take it upon ourselves to write the >>definitive Macintosh Programmers Guide (available at your local bookstores >>for the low, low price of only $79.95 [softback]). > (stuff deleted) >Book, smook. Its about time we have an electronic version! > (stuff about HyperCard stackware version deleted) >You get the idea. Then have BMUG release it on CD-ROM with a copy on >sumex (or your favorite net archive server). > >Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu >(303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET > Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP Well, speaking on behalf of the guys who put the PD-ROM together for BMUG, I'm sure we'd be happy to include it on the next version (which is due out sometime this summer). Also, if people are serious about a definitive book of the tangible variety, BMUG may be able to help with the editing and printing; our developers SIG is considering putting together such a beast (dealing mostly with LSC issues but open to MPW, LSP and other programming environments) to be called, tentatively (and no flames, please), "The Satanic Sources". Since we have a reasonably good setup for editing, printing, and distribution, we might be able to help with the compilation and production for something which would be extremely attractively priced and available to everyone not on the net. People who'd like to discuss or contribute to this effort are encouraged to get in touch with Greg Dow of the developers SIG. He can be reached on this account or at apple!bmug!greg.dow@sun.com. John Heckendorn "We're in the business of giving away information" /\ BMUG ARPA: bmug@garnet.berkeley.EDU A__A 1442A Walnut St., #62 BITNET: bmug@ucbgarnet |()| Berkeley, CA 94709 | | (415) 549-2684 | |
fozzard@boulder.Colorado.EDU (Richard Fozzard) (03/19/89)
Regarding all this talk about being a new programmmer on the Mac: Has any one used the Prototyper program from Smethers Barnes? It seems a wonderful way to learn AND get automatic code examples for a variety of things. And will it only work with Pascal or can it also generate C code (eg for Lightspeed C)? This program reminds me of something I used a couple years ago on Symbolics Lisp machines called Framer. I hope Prototyper is a little more complete than that one. Rich Fozzard University of Colorado fozzard@boulder.colorado.edu
ech@pegasus.ATT.COM (Edward C Horvath) (03/19/89)
From article <7540@boulder.Colorado.EDU>, by fozzard@boulder.Colorado.EDU (Richard Fozzard): > Has any one used the Prototyper program from Smethers Barnes? It seems a > wonderful way to learn AND get automatic code examples for a variety of > things. And will it only work with Pascal or can it also generate C code > (eg for Lightspeed C)? Prototyper 2.0 is now available ($249 list, $149 from MacConnection where I got mine). The newer version generates C for MPW 2.0 and 3.0 and LSC, or pascal for LSP or Turbo. MPW pascal users all use MacApp :-) I haven't really played with it much yet, but it looks to support dialog and menu creation quite nicely. Detailed review when I have more experience... =Ned=