sonenbli@oxy.edu (Andrew D. Sonenblick) (10/07/89)
Ok, I posted the preliminary problem yesterday (and thanks to all
those millions of subscribers who replied to it.... sorry, please
excuse my sarcasm but this problems has induced premature hair
loss, teeth grinding, and general self-disfiguring practices.)
The problem began with MenuManager calls from code resources
(which are locked, detached, unpurgable and in the system zone).
Some would seem to work (such as GetMHandle) and others wouldn't
(such as when I used the MenuHandle from said GetMHandle call
to InsMenuItem( ... ) with the result that a garbage string was
*appended* to the *worong* menu.) Now, I find that other Managers
also fail to operate properly. If my code resources put up a
window the WindowMgr seems to whimsically decide whether to put
up the window or not! Dialogs don't works properly, either.
Any time I use Pascal Str255 (I'm using LSC) such as in the call
DrawString(&myString) I get nothing (the big null, nil, void) or
garbage!
Now you can understand my frustrations---the Frigging ToolBox is
not operating as it expected to! I cannot rely on it when calling
from a code resource (How am I to trust that my "outline" for
making an INIT, a patch, etc will not end with me spending hours
coding only to have the managers fail and ruin my programming life.)
Anyway, I appreciate everyone for letting me vent my $(%#@! If
Anyone has aaaannnyyy ideas what the heck is going on, please
reply (to me is fine, perhaps to the net to appraise everyone else
of the problem/solution is better.) But if you have any insight,
please respond and save a fellow Mac enthusiast/programmer from
premature senility! Thanks again, Ando Sonenblick. My address
is: sonenbli@oxy.edu
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
What ever happened to the good ole days when we were all dinosaurs and would
wallow around eating... Ok, so half the time we ate each other, but other than
THAT, did you have any complaints?
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_oster@dewey.soe.berkeley.edu (David Phillip Oster) (10/07/89)
In article <52218@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > up the window or not! Dialogs don't works properly, either. > Any time I use Pascal Str255 (I'm using LSC) such as in the call > DrawString(&myString) I get nothing (the big null, nil, void) or If you read the documentation, you'd learn that THINK C 3.0 required you to use: #include <SetUpA4.h> main(){ RememberA0(); SetUpA4(); DebugStr((StringPtr) "\pEureka, a system call that works!"); RestoreA4(); } Wuithout the Remember, Setup, you can't get at your global variables. (Remember ahould be executed exactly once, no matter what else gets called.) THINK C v3 needed this to get at string constants. THINK C v4 doesn't need this to get at string constants, just globals. Note: the SetUpA5() macro provided in OSUtils.h is not safe for use in a multi-finder environment: it works by looking at a global variable that gets swapped in major tasks swaps, so interrupt level code routins may find the wrong value there. I handle this by cloning SetUpA4.h and changing all references to A4 to A5. > The mac is a detour in the inevitable march of mediocre computers. > drs@bnlux0.bnl.gov (David R. Stampf) --- David Phillip Oster -master of the ad hoc odd hack. Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
eta@ic.Berkeley.EDU (Eric T. Anderson) (10/10/89)
In article <52218@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > > > The problem began with MenuManager calls from code resources > (which are locked, detached, unpurgable and in the system zone)... > ... > ... Now, I find that other Managers > also fail to operate properly. If my code resources put up a > window the WindowMgr seems to whimsically decide whether to put > up the window or not! Dialogs don't works properly, either. > Any time I use Pascal Str255 (I'm using LSC) such as in the call > DrawString(&myString) I get nothing (the big null, nil, void) or > garbage! > ... The reason your manager calls are failing is probably because you are not getting a hook to your 'DATA' resource in LSC. Any string that you might pass, (e.g. "This" or "\pThat") is probably not getting located properly. For example, if you compile your code to be a driver and use LSC to get your code up and running, whenever the driver gets called, LSC is nice enough to restore your global environment by pointing A4 at the 'DATA' resource (which should be 'SYS' -- assuming that you are going to be using this resource after the application heap gets purged). (This works great for installing drivers and having them stick around.) However, if you put in a mechanism so that your code gets called without the intervention of LSC, you must restore your environment yourself or just not use global variables, etc... I believe the LSC manual suggests keeping a hook to your 'DATA' resource kept in the code within a "DC.W" assembly directive, into which you store a handle to your stuff. Good luck with this. Eric Anderson eta@ic.berkeley.edu Disclaimer: All Emcompassing.