parnes@eniac.seas.upenn.edu (Gary Parnes) (10/27/89)
The problem is this:
How in the heck do you access data in a string handle?
I tried this reasoning: a string handle is a pointer to a pointer which points
to a Str255 data location.
So, I figured *myStringHandle returns a pointer to an Str255.
And I then figured **myStringHandle returns an Str255 data type.
But when I try setting strings like this in THINK C, it pleads complete
ignorence. It says that it's an illegal operation on an array.
So what's wrong with this?
Str255 myString;
StringHandle mystringhandle;
myString=**mystringhandle;
{ computer returns: "Yo mama!" }
Caution: neophyte Mac Programmer ahead. Dangerous when programming!
Gary
/=============================================================================\
| "You're obviously misinformed... everything | Gary Parnes |
| EAST of the San Andreas Fault is going to | Computer Science Engineer |
| fall into the ATLANTIC Ocean." | University of Pennsylvania |
| *** parnes@eniac.seas.upenn.edu *** | *NOT* Penn State, Dammit! |
\=============================================================================/CXT105@PSUVM.BITNET (Christopher Tate) (10/27/89)
In article <16004@netnews.upenn.edu>, parnes@eniac.seas.upenn.edu (Gary Parnes) says: >So what's wrong with this? > >Str255 myString; >StringHandle mystringhandle; > >myString=**mystringhandle; What you're trying to do here, in actuality, is copy every element of the Str255 you find with **mystringhandle into the Str255 variable called myString. You can't do this, for the same reason that you can't simply assign two arrays to be equal: C doesn't let you do it. That's why the compiler gives you an "illegal operation on array" message. Since you're dealing with Pascal strings, the copying gets a little messy. What I do is copy the length byte, then use it as a counter as I copy the string from **mystringhandle into myString, thus: StringHandle mystringhandle; Str255 myString; char *toPtr, *fromPtr; int i; fromPtr = (char *)(*mystringhandle); /* point to the first char */ toPtr = (char *) &myString; /* of both strings */ *toPtr = *fromPtr; /* copy the length byte */ i = *fromPtr; /* set up the counter */ toPtr++; fromPtr++; /* point to the actual string data */ for (;i>0;i--) /* do this for each character in the string.... */ { *toPtr = *fromPtr; /* copy a byte of the string */ toPtr++; fromPtr++; /* move along one byte */ } This fragment copies the contents of the string accessed through mystringhandle into the Str255 variable myString. (At least, that's what I *think* it does; I wrote it off the cuff and it may be wrong :-). I wrote out all the pointer incrementing explicitly to help you see what's going on. If you're a new programmer, you probably have the same problem with C that I had: reading it ("C" stands for "Cryptic"). Anyway, you'll probably hear different ways of doing it, but that's what springs to my mind. Hope it helps. ------- Christopher Tate | "Oh wow: not only is 57 | prime, but it's also Bitnet: cxt105@psuvm | divisible by three!" Uucp: ...!psuvax1!psuvm.bitnet!cxt105 | Internet: cxt105@psuvm.psu.edu | - a very sincere math major
tim@hoptoad.uucp (Tim Maroney) (10/29/89)
In article <16004@netnews.upenn.edu> parnes@eniac.seas.upenn.edu.UUCP (Gary Parnes) writes: >How in the heck do you access data in a string handle? Gewnerally, I don't; I use string lists and GetIndString. These are generally more convenient to access and maintain. However, when I used to use string resources, I used to use BlockMove. (Gosh, before that sentence, I never realized how convenient it was to use "use"; it has so many usages!) >I tried this reasoning: a string handle is a pointer to a pointer which points >to a Str255 data location. >But when I try setting strings like this in THINK C, it pleads complete >ignorance. It says that it's an illegal operation on an array. >So what's wrong with this? >myString=**mystringhandle; You can't assign to an array in C. You can only assign to individual elements of the array. You are on the right track, but the way to do this thing is: BlockMove(*mystringhandle, myString, 256); BlockMove doesn't touch the heap so it's safe to use this dereference even when mystringhandle is unlocked or purgeable (but not purged!) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "As I was walking among the fires of Hell, delighted with the enjoyments of Genius; which to Angels look like torment and insanity. I collected some of their Proverbs..." - Blake, "The Marriage of Heaven and Hell"
Jim.Matthews@dartmouth.edu (Jim Matthews) (10/31/89)
In article <8835@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > > BlockMove doesn't touch the heap so it's safe to use this dereference > even when mystringhandle is unlocked or purgeable (but not purged!) A paranoid note: BlockMove doesn't move memory, but since it's an OS trap most compilers get to it through glue. If that glue is in an unloaded segment, then the act of *calling* BlockMove will move memory. The moral: watch out for traps that require glue or put the glue in a segment that is never unloaded. -- Jim Matthews Dartmouth Software Development
tim@hoptoad.uucp (Tim Maroney) (10/31/89)
In article <8835@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > BlockMove doesn't touch the heap so it's safe to use this dereference > even when mystringhandle is unlocked or purgeable (but not purged!) In article <16420@dartvax.Dartmouth.EDU> Jim.Matthews@dartmouth.edu writes: >A paranoid note: BlockMove doesn't move memory, but since it's an OS trap >most compilers get to it through glue. If that glue is in an unloaded >segment, then the act of *calling* BlockMove will move memory. Excellent point. >The moral: watch out for traps that require glue or put the glue in a >segment that is never unloaded. I get a different moral out of this -- don't unload segments. I use so many function pointers in my code that it's impossible anyway, so I don't have this problem. As far as I'm concerned, UnloadSeg was relevant only to the Mac 128K.... Another moral -- if you *do* unload segments, then link your glue routines into the main code segment, so they will never be unloaded. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com These are not my opinions, those of my ex-employers, my old schools, my relatives, my friends, or really any rational person whatsoever.
lippin@sizzlean.berkeley.edu (The Apathist) (11/02/89)
Recently tim@hoptoad.UUCP (Tim Maroney) wrote: >I get a different moral out of this -- don't unload segments. I use so >many function pointers in my code that it's impossible anyway, so I >don't have this problem. As far as I'm concerned, UnloadSeg was >relevant only to the Mac 128K.... Are you crazy? Unloading segments is one of the handiest ways available to save memory. If you don't swap your code to disk using UnloadSeg, you'll have to swap your data that much sooner, and data swapping is much more expensive (as you have to write it out before purging it). Perhaps you swap nothing? Then you're forcing the user to make your MultiFinder partition much larger that it should need to be. Think of all the features of your program that are only used occasionally -- that could all be saved for data space. (BTW, using function pointers is no excuse; a true Jedi's development system uses pointers to jump table entries.) >Another moral -- if you *do* unload segments, then link your glue >routines into the main code segment, so they will never be unloaded. Now that's a good idea. Also, your low-on-memory code (you do have some, don't you?) shouldn't be swapped out, unless you're really careful about it. >These are not my opinions, those of my ex-employers, my old schools, my >relatives, my friends, or really any rational person whatsoever. Wish that were true! --Tom Lippincott lippin@math.berkeley.edu "Foo, you are nothing but a charlatan!" --Adventure