ching@amd.UUCP (Mike Ching) (06/07/86)
I received numerous responses to my request for help and thought others might benefit from my mistakes. I had written a program in Lightspeed C using the "unix main.c" environment while I ironed out the algorithm. When I tried to make the program macish, I failed to add calls to initialize the various managers and got a bomb for my efforts. InitGraf(&thePort); InitFonts(); InitWindows(); etc. are automatically called by some compilers but must be called explicitly in Lightspeed. It's in the manual but I was using code examples from other compilers as a guide. Thanks again Larry and David. Mike Ching
dlc@lanl.ARPA (Dale Carstensen) (06/08/86)
> the algorithm. When I tried to make the program macish, I failed > to add calls to initialize the various managers and got a bomb for > my efforts. I almost replied before, but I would not have had the correct suggestion. But maybe someone else would like to know this. By reading Inside Macintosh about SFGetFile (and SF etc.), it appears that in C you can pass a file-type selection array of length one by '1, "TEXT"' -- but, the code uses a ".w" instruction, and you have a .5 probability of an address error. (Maybe that is an ID=02 error??) I found it on my second use of the trick. Now I do it this way: long ftl; . . . ftl = (long)'TEXT'; SFGetFile( . . . 1, &ftl, . . . Even making your C code more like Apple's Pascal may not guarantee the array starts on an even address, so you should probably union the character string with a long to insure the correct boundary. Too bad Apple picked Pascal, such poor handling of variable length arrays and strings. And it looks like the Intel processors have at least one advantage over Motorola -- no odd address bombs. PS: Inside Macintosh also lies when it says "prompt" is not used in SFPutFile. Of course, the garbage text in your dialog the first time you believe IM tells you to not believe IM.