gft_robert@gsbacd.uchicago.edu (01/09/90)
Date: 8 JAN 90 14:15:23 Organization: University of Chicago Graduate School of Business ----------- I'm writing a moderately complicated stack and I've run into a strange problem: my stack behaves differently when it's started up by itself (that is, when the stack itself is double-clicked) than when it's launched once one is already in HyperCard. Specifically, in my openStack handler, I set userModify to TRUE (this will eventually be running off a write-protected server) and I click in a particular field so that the user can immediately enter data. This works find if I launch the stack from within HyperCard or if I move to it from another stack. But if I launch the stack itself from the Finder, things _seem_ to get set up right (the I-bar appears in the proper field and userModify is set right), but right after openStack there's a bit of disk-trashing, and my I-bar disappears and userModify is set back to FALSE. Yo no comprendo. What could be executing after openStack? I checked the home card for the startUp handler, but it didn't really seem to contain anything that would cause this. What am I missing? Any info appreciated! Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
ldo@waikato.ac.nz (Lawrence D'Oliveiro) (01/13/90)
I've come across similar behaviour myself, and I think I know what's happening: HyperCard is going to the Home stack and invoking the OpenStack handler there, *after* it's done the same for your stack! There seem to be all kinds of problems with the order in which HyperCard invokes various handlers. One case that's been bugging me for a long time now is that, when I create a new card, the OpenCard message is sent *before* the NewCard one! The way I get around this is to check, in my OpenCard handler, if certain important fields (which should have been initialised in NewCard) are still empty; if so, OpenCard exits without doing anything. Also, my NewCard handler ends with an explicit call to OpenCard. Yuk. All I can suggest is, stick a few "Answer" statements inside various handlers to help you determine the order in which HyperCard is calling them; once you've done that, *then* you can sit down and figure out what to do about it. Lawrence
gft_robert@gsbacd.uchicago.edu (08/30/90)
----------
I know Pascal well, and I thought I had a pretty good idea of C, but I'm
getting a bit lost in what seem to fairly elementary questions involving C and
the Mac ToolBox.
1) How does one determine if a key is down using KeyMap? It's simple in
Pascal: an array of booleans, but in the C interfaces it's declared as
typedef struct KeyMap
{
long Key[4];
}KeyMap;
which is considerably less obvious.
2) How does one return a Str255 from a function? THINK complains "can't return
array from function"? But aren't I returning a pointer to the first (Oth) char
of the Str255 if I "return myString"? Do I need Str255 *MyProc() if I want to
pass back any reference to a Str255 at all?
See, I told you these were weenie. And I'm supposed to learn C++? :->
Robert
============================================================================
= gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to =
= * all my opinions are * compute" =
= * mine * -Kraftwerk =
============================================================================bob@xanadu.com (Bob Schumaker -- "Software-in-a-bucket") (08/31/90)
> 1) How does one determine if a key is down using KeyMap? It's simple in > Pascal: an array of booleans, but in the C interfaces it's declared as Boolean CheckKey (map, key) KeyMap *map; int key; { long i = (1 << (31 - (key % 32))); #ifdef applec /* or AppleC in MPW 3.2 :-( don't ask me why! */ return (*map[key/32] & i); #else return (map->Key[key / 32] & i); #endif } ------------------------------------------------------------------------ This life is a test. It is only a test. Had this been a real life, you would have been told where to go and what to do. ------------------------------------------------------------------------ Bob Schumaker The AMIX Corporation 2345 Yale, Palo Alto, CA 94306 Addresses: bob@amix.com uunet!markets!amix!bob amix.com!bob@uunet.uu.net sun!xanadu!amix!bob Any opinions expressed herein probably *are* the opinions of my employer. ------------------------------------------------------------------------ -- ------------------------------------------------------------------------ This life is a test. It is only a test. Had this been a real life, you would have been told where to go and what to do. ------------------------------------------------------------------------
johnsone@uxh.cso.uiuc.edu (08/31/90)
/* Written 2:21 pm Aug 29, 1990 by gft_robert@gsbacd.uchicago.edu */ >2) How does one return a Str255 from a function? THINK complains "can't return >array from function"? But aren't I returning a pointer to the first (Oth) char >of the Str255 if I "return myString"? Do I need Str255 *MyProc() if I want to >pass back any reference to a Str255 at all? I was going to suggest declaring the function: char *MyProc() but I just tried it and it doesn't work. Using this will work: MyProc( Str255 myString ) { . . . } called with: Str255 aString; . . . MyProc( aString ); This doesn't give you a function, but it may serve your purpose. Erik A. Johnson, Graduate Student \ Internet: johnsone@uxh.cso.uiuc.edu Aeronautical & Astronautical Engineering \ University of Illinois at Urbana-Champaign \
jason@ux1.cso.uiuc.edu (Jason) (09/06/90)
johnsone@uxh.cso.uiuc.edu writes: >/* Written 2:21 pm Aug 29, 1990 by gft_robert@gsbacd.uchicago.edu */ >>2) How does one return a Str255 from a function? THINK complains "can't return >>array from function"? But aren't I returning a pointer to the first (Oth) char >>of the Str255 if I "return myString"? Do I need Str255 *MyProc() if I want to >>pass back any reference to a Str255 at all? >I was going to suggest declaring the function: > char *MyProc() >but I just tried it and it doesn't work. Using this will work: > MyProc( Str255 myString ) >called with: > Str255 aString; >This doesn't give you a function, but it may serve your purpose. In a Think C function, if you make a declaration of the form: type anArray[ A_SIZE ]; the compiler will not allow such an array to be returned to the calling function because the return value would point to the first character of the array--an array whose memory space was allocated on the stack _temporarily_ and which is released when the function returns. Therefore, a pointer returned in this way actually points to an undefined object and is not usable. The above method ( MyProc( Str255 myString ) ) works because the object being passed to MyProc() is declared in the calling function (or in that function's calling function, etc., or globally) giving it a broader "scope" than this occurrance of the function MyProc(). In other words, myString is good for more than just the duration of MyProc(). If you *really* want a function to return an array, its storage can be allocated on the heap using NewPtr() or NewHandle(). This method is unwise, so I won't go into the complications it presents. -- | | |====================| | | | Jason Watts | \ |\ |\ \ | (jazzin@uiuc.edu) |