Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!seismo!cmcl2!lanl!dlc
From: dlc@lanl.ARPA (Dale Carstensen)
Newsgroups: net.micro.mac
Subject: Re: Thanks for the help (SFGetFile)
Message-ID: <4046@lanl.ARPA>
Date: Sat, 7-Jun-86 23:22:09 EDT
Article-I.D.: lanl.4046
Posted: Sat Jun  7 23:22:09 1986
Date-Received: Mon, 9-Jun-86 01:42:06 EDT
References: <2598@amd.UUCP>
Organization: Los Alamos National Laboratory
Lines: 24

> 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.