rah0777@cec1.wustl.edu (Rexford Alan Hill) (07/12/90)
I'm sorry to keep wasting bandwidth with this problem, but I've gotta correct
my previous posting:
Background:
I've compiled a CODE resource of my own type 'XFRM' in THINK C 3.0 that has
a main that looks like this:
main()
{
MoveTo(10,10);
LineTo(50,50);
}
I've written a program to read in this XFRM resource and call it. It looks
like this:
Handle theHandle;
void (**pHand)();
main()
{
/* some initialization stuff (menus, windows) */
theHandle = GetResource('XFRM',1);
HLock(theHandle);
pHand = (void (**)())theHandle;
(**pHand)();
HUnlock(theHandle);
/* some other stuff */
}
I use ResEdit to copy the XFRM resource from the compiled CODE resource file
to the application project's resource file (the one that gets copied into the
application after compilation).
Here's where my second posting was wrong:
The application works under UniFinder, but not under MultiFinder.
The program works if I run it from within THINK C only if the source-level
debugger option is on, but not otherwise.
By 'works', I mean that the line is drawn in a window that was opened by the
initialization stuff. By 'doesn't work', I mean that the program executes as
expected, but doesn't draw the line.
Could I have some stray pointers out there, boinking memory? The other
possibility is that my typecasting is wrong (if you've seen my previous posts,
the code has changed every time). Any help would be appreciated tremendously.
At wit's end,
rex
Rexford A. Hill
Washington University in St. Louis
rah0777@wucec1.wustl.edu
rex@dworkin.wustl.edu
rex@wuccrc.wustl.edumxmora@unix.SRI.COM (Matt Mora) (07/12/90)
In article <1990Jul12.140806.21704@cec1.wustl.edu> rah0777@cec1.wustl.edu (Rexford Alan Hill) writes: >Background: > I've compiled a CODE resource of my own type 'XFRM' in THINK C 3.0 that has >a main that looks like this: >main() >{ > MoveTo(10,10); > LineTo(50,50); >} > > I've written a program to read in this XFRM resource and call it. It looks >like this: > >Handle theHandle; >void (**pHand)(); > >main() >{ > /* some initialization stuff (menus, windows) */ > > theHandle = GetResource('XFRM',1); > HLock(theHandle); > pHand = (void (**)())theHandle; > (**pHand)(); > HUnlock(theHandle); > > /* some other stuff */ >} > [stuff deleted] > Here's where my second posting was wrong: >The application works under UniFinder, but not under MultiFinder. >The program works if I run it from within THINK C only if the source-level >debugger option is on, but not otherwise. >By 'works', I mean that the line is drawn in a window that was opened by the >initialization stuff. By 'doesn't work', I mean that the program executes as >expected, but doesn't draw the line. Did you actually trace your code and see that your code resource gets called? Drop into macsbug and step through the call. It sounds (and looks like according to the code you posted) like you are not setting the drawing port. I had a problem show up only after I made the a program into an application that I wasn't setting a port back to what it was. I think the THINK environment sets the ports for you to make sure that you don't draw all over the THINK environment windows. And when you actually compile your program your own sloppyness rears its ugly head and things don't get drawn. You might want to check the clip region also. This is the first quickdraw gottcha that most Mac programmers run into (or forget about). > Could I have some stray pointers out there, boinking memory? The other >possibility is that my typecasting is wrong (if you've seen my previous posts, >the code has changed every time). Any help would be appreciated tremendously. Its hard to tell from your code you posted. The line : /* some initialization stuff (menus, windows) */ doesn't tell us much. You could be screwing up there. If you think you have stray pointers or handles get the MR BussError init, it will help you find those. I don't know if you received any help via e-mail but I seen your previous posts and didn't post because I was not clear on what you were doing. If you can always post the exact code. People would probably be more willing to help if they know they are not chasing typo's :-). I can't help you on your type casting (I'm not a C programmer) but when I was debugging an Init I wrote I used the THINK pascal's Source level debugger to show me that I was stuffing the right values into a precompiled code resource. I just made the INIT an application and singled stepped through the code. Magsbug helped a lot when I was no longer in the THINK environment. >Rexford A. Hill I hope this helped. -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
hawley@adobe.COM (Steve Hawley) (07/13/90)
In article <1990Jul12.140806.21704@cec1.wustl.edu> rah0777@cec1.wustl.edu (Rexford Alan Hill) writes: >The application works under UniFinder, but not under MultiFinder. >The program works if I run it from within THINK C only if the source-level >debugger option is on, but not otherwise. >By 'works', I mean that the line is drawn in a window that was opened by the >initialization stuff. By 'doesn't work', I mean that the program executes as >expected, but doesn't draw the line. > Could I have some stray pointers out there, boinking memory? The other >possibility is that my typecasting is wrong (if you've seen my previous posts, >the code has changed every time). Any help would be appreciated tremendously. Could it be that your external function is not getting A5 set up correctly? It probably is (since in theory all you're doing is calling a function in memory from your parent program), but it wouldn't hurt to check. Make sure Think C is compiling your code so you can get at globals. There might be some glue that youy're just not seeing that is making it flakey. Steve Hawley hawley@adobe.com -- "A blow on the head is... ...worth two in the bush." -Basil Fawlty