Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-091.TXT

Text File | 1992-06-30 | 50.0 KB | 1,336 lines

C.S.M.P. Digest             Sat, 23 May 92       Volume 1 : Issue 91

Today's Topics:

    How to convert bitmap to PICT resource
    Gestalt() doesn't know about 'rsrc'!
    File System Question
    Fast Screen Drawing
    THINK Pascal: Need to wait for single keypress
    Writing  apps that use plug-ins?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Tony Ng)
Subject: How to convert bitmap to PICT resource
Date: 20 Apr 92 03:41:00 GMT
Organization: University of Illinois at Urbana

I don't know if this is a FAQ or not. But I really would like to
know how one can convert the bitmap of a window/port into
PICT resource. In other words, how one can copy the image of a window
into the clipboard so that the picture can be pasted somewhere else.

Any suggestions or help appreciated!


- --
Tony Ng
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 20 Apr 92 20:43:45 GMT

In <[e-mail]> [e-mail] (Tony Ng) writes:

>... But I really would like to
>know how one can convert the bitmap of a window/port into
>PICT resource.

This is a question I've had also.  I solved it by creating an offscreen
pixmap of the same size and depth of the window.  Then, be sure to set
forecolor to black and backcolor to white or the pixmap's colors will
be very odd.  Then I opened the picture, copied the bits from the screen
to the offscreen pixmap, closed the picture, and sent it off to the
clipboard.  Worked like a charm.  I'll send anyone who wants some code
that I did in Pascal to do this.

Problem is that this is overkill.  A copy of the picture exists on screen,
off screen, and in the picture.  Really, allocating and deallocating the
offscreen pixmap is totally unneccessary because it doesn't do anything
useful--it just fools the pict into picking those bits up also.

I tried to CopyBits from the portbits to the portbits, but it didn't
do anything.  Then I tried to go from the window's portbits to the WMgrPort
portbits, but CopyBits was too smart for me there, also.  I just gave up
and lived with the redundancy because I had to get the project done by
the end of the week.

I had forgotten about it until just now when I read that message.  It
still bugs me.  Is there any way to go directly from bits to pict?  It
should not be neccessary to allocate more bits when they won't even get
used except to waste memory and processor time.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Kenneth Knight)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Mon, 20 Apr 92 22:18:55 GMT

In article <[e-mail]> [e-mail] (Tony Ng) writes:
>I don't know if this is a FAQ or not. But I really would like to
>know how one can convert the bitmap of a window/port into
>PICT resource. In other words, how one can copy the image of a window
>into the clipboard so that the picture can be pasted somewhere else.

Here is a code fragment that will first make a QuickDraw PICT out of the
contents within a window and then copy that PICT into the cliboard.

PicHandle    thePict;
long        picSize;
OSErr        err;

err = ZeroScrap();
if (err == noErr) {
thePict = OpenPicture(&(theWindow->portRect));
  CopyBits((GrafPtr)theWindow)->portBits, (GrafPtr)theWindow)->portBits,
           &(theWindow->portRect, &(theWindow->portRect), srcCopy, nil);
ClosePicture();
picSize = GetHandleSize((Handle)thePict);
HLock((Handle)thePict);
PutScrap(picSize, 'PICT', (Ptr)*thePict);
HUnlock((Handle)thePict);
DisposeHandle((Handle)thePict);
} /* if */

This fragment first makes a QD picture by simply CopyBitt() the
contents of the window onto itself. Then that PICT is placed in
the cliboard with the PutScrap() call.

Hope that helps.


+++++++++++++++++++++++++++

From: [e-mail]
Date: 21 Apr 92 22:02:59 EST
Organization: Wright State University

In article <[e-mail]>, [e-mail] (Kenneth Knight) writes:
> Here is a code fragment that will first make a QuickDraw PICT out of the
> contents within a window and then copy that PICT into the cliboard.
>
> PicHandle    thePict;
> long        picSize;
> OSErr        err;
>
> err = ZeroScrap();
> if (err == noErr) {
> thePict = OpenPicture(&(theWindow->portRect));
>   CopyBits((GrafPtr)theWindow)->portBits, (GrafPtr)theWindow)->portBits,
>            &(theWindow->portRect, &(theWindow->portRect), srcCopy, nil);
> ClosePicture();
> picSize = GetHandleSize((Handle)thePict);
> HLock((Handle)thePict);
> PutScrap(picSize, 'PICT', (Ptr)*thePict);
> HUnlock((Handle)thePict);
> DisposeHandle((Handle)thePict);
> } /* if */

Also do ClipRect(theWindow^.portRect) before the call to OpenPicture.

Is DisposeHandle((Handle)thePict) <-> KillPicture(thePicture)?

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 22 Apr 92 12:05:23 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] writes:

   > HLock((Handle)thePict);
   > PutScrap(picSize, 'PICT', (Ptr)*thePict);
   > HUnlock((Handle)thePict);
   > DisposeHandle((Handle)thePict);

   Also do ClipRect(theWindow^.portRect) before the call to OpenPicture.

Very true ! You cando it after opening the picture, though, and
the call will be recorded, too.

However, if you DON'T, you'll have problems drawing this picture
in any other position than it's "home" position.

   Is DisposeHandle((Handle)thePict) <-> KillPicture(thePicture)?

No. It may work now, if the user has no accelerated graphics
card, but in general, don't assume it is. Dispose regions
with DisposeRgn, and resources with ReleaseResource etc.

Never mix different manager calls, since the picture data in
theory could be accumulated on a graphics card, and the mac
Memory Manager wouldn't get at it as a memory manager block.

- --
"You should meet yourself someday. I'm sure you would hate it."
- - Me: [e-mail]; Jon W{tte (The Diplomat - NOT!)

---------------------------

From: [e-mail] (Doug McNaught)
Subject: Gestalt() doesn't know about 'rsrc'!
Date: 19 Apr 92 02:09:23 GMT
Organization: California Institute of Technology


  My application uses the System 7 partial resource routines, so I call
Gestalt() with the selector gestaltResourceMgrAttr (which is defined in IM6
and the C header files as 'rsrc'). However, Gestalt doesn't know this selector!
It returns gestaltUndefSelectorErr (-5551) as its result code. I know the
routines are there, because when I blindly go ahead and use them, they work.
It's not a huge deal, because I test for a bunch of other sys7-specific stuff,
and I figure anything that has real TempMem handles, the new Standard File
calls, and FindFolder will have the partial resource routines. But I'm trying
to be Apple-obedient, and it bugs me that this selector doesn't work. BTW,
I know it's not the glue that's causing the problem, because I watched it
call the actual trap with Macsbug, and that's where the error code comes from.
So has anybody else run into this? Should I submit it to Apple.Bugs? Oh, I'm
using 7.0.1 + Tuneup 1.1.1 on a 4meg Classic.
thanks,
doug

- --
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>
<> Doug McNaught                                [e-mail] <>
<>  Help!!! I'm addicted to *Spaceward Ho!* Is there a support group? <>
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 22 Apr 92 01:48:32 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Doug McNaught) writes:
>
>
>   My application uses the System 7 partial resource routines, so I call
> Gestalt() with the selector gestaltResourceMgrAttr (which is defined in IM6
> and the C header files as 'rsrc'). However, Gestalt doesn't know this selector!
> It returns gestaltUndefSelectorErr (-5551) as its result code. I know the
> routines are there, because when I blindly go ahead and use them, they work.
> It's not a huge deal, because I test for a bunch of other sys7-specific stuff,
> and I figure anything that has real TempMem handles, the new Standard File
> calls, and FindFolder will have the partial resource routines. But I'm trying
> to be Apple-obedient, and it bugs me that this selector doesn't work. BTW,
> I know it's not the glue that's causing the problem, because I watched it
> call the actual trap with Macsbug, and that's where the error code comes from.
> So has anybody else run into this? Should I submit it to Apple.Bugs? Oh, I'm
> using 7.0.1 + Tuneup 1.1.1 on a 4meg Classic.
> thanks,
> doug
>

  You're right.  We forgot.  This was one of those things that slipped through
the cracks in the heat of trying to go final.  This well of course, be remedied
in a future version of system software.  Just don't ask when.


  -- Dean Yu
     Blue Meanie, Negative Ethnic Role Model, Window Cleaner,
      Skanky Hack Consultant, etc.
     Apple Computer, Inc.

---------------------------

Organization: University of Illinois at Chicago
Date: Monday, 20 Apr 1992 11:20:15 CDT
From: John Galidakis <[e-mail]>
Subject: File System Question

 Howdy gurus, again.
IM IV states that the file manager has the capability to read consequtive
bytes from files in the so called "newline mode" where a sentinel
(usually a CR) is used to terminate the Read. (page 95)
However I can't find any references on how this is done.
Somebody out there knows anything about it, or do I simply have to
use FSRead one byte at a time and store the chars in a buffer?
If I have to do the above (simulating a readln myself) I suppose the
Note in IM is pretty much useless...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ John "the Baptist" Galidakis +  "Only JCN won the fight with +
+ Programmer/Designed Data Co. + the great goddess. The rest   +
+ Paranoid Evangelist          +  just tried..." HLC           +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++

From: [e-mail] (Chris Wysocki)
Date: 21 Apr 92 01:51:08 GMT
Organization: Harvard University, Cambridge, MA

In article <[e-mail]>, [e-mail] (John Galidakis) writes:

> IM IV states that the file manager has the capability to read consequtive
> bytes from files in the so called "newline mode" where a sentinel
> (usually a CR) is used to terminate the Read. (page 95)
> However I can't find any references on how this is done.

I used newline mode in a DA I wrote a couple of years ago; here's the
relevant section of code:

    /*
     *  Here we use "newline mode", meaning that all read operations will
     *  terminate at a newline character.  We select newline mode by setting
     *  bit 7 of ioPosMode and specifying the newline character (here, the
     *  ASCII CR (0D hex)) in the high-order byte of ioPosMode (leading to
     *  the "0x0D80" below)
     */

    pb.ioRefNum = refNum;
    pb.ioBuffer = (Ptr) str + 1;
    pb.ioReqCount = sizeof(Str255) - 1;
    pb.ioPosMode = fsAtMark | 0x0D80;       /* set newline mode */
    err = PBReadSync(&pb);

See the note on IM IV-121 for the complete story.

Chris Wysocki
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 22 Apr 92 14:48:08 GMT
Organization: Reed College, Portland OR


   [e-mail] (John Galidakis) writes:
.  IM IV states that the file manager has the capability to read consequtive
.  bytes from files in the so called "newline mode" where a sentinel
.  (usually a CR) is used to terminate the Read. (page 95)
.  However I can't find any references on how this is done.

   It's significantly faster to read as much as you can, then parse it,
even if it means you have to write your own white-space recognizer. You
can always have the Script Manager tokenize for you.
   Just an observation,
   Theus ([e-mail])

---------------------------

Subject: Fast Screen Drawing
From: Michael Joseph Raneri <[e-mail]>
Date: Tuesday, 21 Apr 1992 16:03:38 EDT
Organization: Penn State University

I am hoping someone could help me out with drawing PICTs on screen rapidly.
I need this for the creation of a game of mine.  I'm somewhat experienced in
Mac programming but I've never written this type of program.  I need to paste
small 256 color PICT resources (preloaded, of course) on screen.  These will
all use the same color table, which is different than the standard palette used
by the system.  Should I abandon quickdraw and write a dedicated procedure?
(using Think C, by the way.)  Should I use the Palette manager for color?
(Probably not.) Should I use the graphics device manager to change the CLUT of
the screen device???  Any help on this matter would be greatly appreciated.
                                          -Mike
                                           [e-mail]
P.S.  Forgive me if this is a FAQ.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 22 Apr 92 14:05:44 GMT
Organization: Kalamazoo College

[e-mail] (Michael Joseph Raneri) writes:
>
>I am hoping someone could help me out with drawing PICTs on screen rapidly.
>I need to paste
>small 256 color PICT resources (preloaded, of course) on screen.  These will
>all use the same color table, which is different than the standard palette used
>by the system.
>
>Should I abandon quickdraw and write a dedicated procedure?

No.  Or at least, you should go through QuickDraw first, and then if you
don't have enough speed, then you can go ahead.  But that shouldn't be
your first route.

>Should I use the Palette manager for color? (Probably not.)

Yes!

>Should I use the graphics device manager to change the CLUT of
>the screen device???

No!

If you read the Color Manager chapter, do so for informational purposes
only.  The Palette Manager has a fairly steep learning curve, but it's
worth it.  Trust me on this one.

What you want to do is set up your palette with pmExplicit+pmTolerant
colors, with zero tolerance, and draw a PICT into an off-screen PixMap.
Save the pixels of that PixMap to disk, probably as a custom resource
type.  Repeat for every PICT you have.

Then, to display them, read in the pixel data, set up a PixMap around it
properly, activate a palette of the same colors, and CopyBits the data
to the screen.  CopyBits will work much faster because (1) it's
optimized for fast animation, and (2) it doesn't have to decompress the
PICT before displaying it.

When displaying the pixels, you may want to use pmExplicit+pmAnimated
colors instead of pmExplicit+pmTolerant, if you're going to do special
effects like fades or whatnot.  _Don't_ do this when you're creating the
pixel data in the first place;  DrawPicture() will not use pmAnimated
colors, so your data would end up not using all the colors that you
so carefully chose for it.

If none of that made sense, go read the Palette Manager chapter a few
times.  :-)  Those last three paragraphs are just kind of an overview of
what you have to do;  if you need more specific help, try me or the
net again, we'll be glad to lend a hand...
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Youth culture killed my dog...

---------------------------

From: [e-mail] (Eric Hansen)
Subject: THINK Pascal: Need to wait for single keypress
Date: 22 Apr 92 03:52:30 GMT
Organization: University of Rochester - Rochester, New York

I'm writing a program where I'd like to wait for the user to hit a key on
the keyboard (in THINK Pascal).  I would like to figure out how to wait
(keep monitoring the keyboard) until a key is pressed, and then somehow
put the 'key pressed' into a variable.  This is similar to a
10 get a$: if a$ = "" then goto10
kind of thing in BASIC, but how can I do this in Mac Pascal?!  I thought the
read(X) command was supposed to do this, but it requires a <return> after the
keypress, and that won't do...  Any help would be much appreciated!
reply to:

[e-mail]

Thanks!!

Eric Hansen

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Organization: Oberlin College Computer Science
Date: Wed, 22 Apr 1992 20:11:43 GMT

In article <[e-mail]> [e-mail] (Eric Hansen) writes:


>   I'm writing a program where I'd like to wait for the user to hit a key on
>   the keyboard (in THINK Pascal).  I would like to figure out how to wait
>   (keep monitoring the keyboard) until a key is pressed, and then somehow
>   put the 'key pressed' into a variable.  This is similar to a


Okay, hold on.  This may sound a little difficult, but it's worth it
to understand.

Probably the best way to do this is to use the event queue.  The event
queue is how the macintosh stores keypresses, mouse clicks, disk
inserted events, etc.  until it wants to deal with them.  Each item in
the queue contains informaction as to where the mouse was when it
happened, what time it happened, what type of event happened, what
modifier keys(shift,control,option,command) were held down when
pressed, and
additional information that pertains to specific types of event.
    I don't have inside mac I in front of me now (which, by the
way it sounds as if you don't have it.  It would be a very good idea
to buy it, or download the inside mac DA (vols. 1-3) from sumex-aim info-mac/da,
or the Spinside Mac (vols 1-5) card stack from ftp.apple.com
/dts/mac/docs/stacks/spinside.  The DA is smaller and faster, but is
pre-mac plus information.  Still, volumes I and II are necessary to
program the mac) but, assuming that you have declared a var of type
EventRecord, you can get the pending event with:

var TheEvent  : eventrecord;
    IsEventPending : boolean;
...
isEventPending:=GetNextEvent(Everyevent,TheEvent);

isEventPending will be true if a key pressed, mouse down, etc. event
is in the queue.

EveryEvent is a constant (predefined in Think) that tells GetNextEvent
what events you want to look at.  If you use the constant KeyDownMask
(might not be the actual name, can't remeber for sure) then
isEventPending will only be true if a key pressed event is in the
queue.

Now TheEvent has a field called .message which comtains the character
code of the key pressed, as well as some other stuff.  The way to get
the character is
ch:=char(band(TheEvent.message,CharCodeMask))

should work.  All this does is takes away all the stuff in message
that you don't want.

so, synopsis-

var TheEvent : EventRecord;
    IsEventPending : Boolean;
    ch : char;

...
repeat
  IsEventPending:=GetNextEvent(everyevent,TheEvent); {Get the next event}
  if IsEventPending = TRUE then           {If there's something there then}
     If TheEvent.what = KeyDownEvt then   {If it's a key pressed event then}
       begin
     ch:=chr(BAND(TheEvent.message,CharCodeMask)); {extract the char}
     {Do what you want with ch}            {do something with it}
       end;

until you want to stop


Note: som constants may be wrong - Get Inside Mac I
      If you want to check for mouse clicks, check if theevent.what =
mousedownevt, theevt.where is the global coordinates (from topleft
corner of screen) whereit was clicked.
      You should use WaitNextEvent, actually, to be nice to
multifinder, but that's a little involved.

Hope This Helps

- -Matt Hall
- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


---------------------------

From: [e-mail] (James Davis)
Subject: Writing  apps that use plug-ins?
Date: 6 Apr 92 17:28:35 GMT
Organization: Computing Services, UC Davis

Hi,
    I want to write something, that can take plug-ins that reside
in different files.  Similar to Superpaint, etc etc..
Anyway, the theory seems easy.  If I have a code resource sitting
in this external file, I should be able to just load the resource and
make a call to it. But how?  Since which resources are available (which plugins)
is determined dynamicly, none of them can reside in the jump-table can they?
Anyway, if anyone can point me in the right direction, or refrence me
off to the correct example or paper Id appreciate it.

THanks
James Davis ([e-mail]) Computing Services, U of Cal.

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Date: 7 Apr 92 02:55:16 GMT
Organization: The World Public Access UNIX, Brookline, MA

Calling plug-ins is pretty straightforward. Pseudocode follows:

typedef pascal OSErr (*PlugInProcPtr)(short selector, long param1, etc);

short refNum;
Handle plugInResource;
PlugInProcPtr plugInProc;

plugInResource = Get1Resource(kPlugInType,kPlugInID);
HLock (plugInResource);
plugInProc = (PlugInProcPtr)StripAddress(*plugInResource);
err = (*plugInProc)(selector, param1, ...);

You should also have error checking code (nil empty handle for the
code resource, resource file not opening, etc) as well. If you're
designing the plug-in specs, it might be useful to have descriptive
resources in the plug-in as well, which you can then parse.

Hope this helps,

- -Ivanski
- ---
Ivan Cavero Belaunde
DiVA Corporation
#include <std.disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (Ed Watkeys)
Date: 7 Apr 92 10:17:22 GMT
Organization: Guerrilla Networking Project


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Ivan M CaveroBelaunde) writes:
> Calling plug-ins is pretty straightforward. Pseudocode follows:
>
> typedef pascal OSErr (*PlugInProcPtr)(short selector, long param1, etc);
>
> [...]
>
> You should also have error checking code (nil empty handle for the
> code resource, resource file not opening, etc) as well. If you're
> designing the plug-in specs, it might be useful to have descriptive
> resources in the plug-in as well, which you can then parse.
>
> Hope this helps,
>
> -Ivanski

While I didn't make the original post, I have a question about this... I'm
writing a BBS program, and I have routines to do i/o over the connection (with
the CTB, of course...); how can I have the plug-in call routines within my
program's code?

Ed

- --
Ed Watkeys (Drexel U. Comp Sci)  "...if you wish to strive for peace
[e-mail]              of soul and pleasure, then believe;
[e-mail]           if you wish to be a devotee of truth,
ls.com!phlpa!caligula!edw         then inquire...." -- Nietzsche

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Date: 7 Apr 92 13:36:26 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Ed Watkeys) writes:
>While I didn't make the original post, I have a question about this... I'm
>writing a BBS program, and I have routines to do i/o over the connection (with
>the CTB, of course...); how can I have the plug-in call routines within my
>program's code?

Basically, one of the parameters you pass to the plug-in must be a procPtr
with well-defined calling conventions. The procptr could be one of the
explicit parameters (this I haven't seen done), or a field inside a
parameter block (XCMDs and Photoshop plug-ins do it this way). Then you
would take the procPtr, cast it to the right type (if necessary), and issue
the callback to your program.  HyperCard's callback structure is a good
example of a flexible callback spec that allows a wide variety of callbacks
with widely varying parameters via the same procPtr, and it's pretty well
documented as well. You might want to use that as a model.

BTW, when you process the callbacks from the plug-in in your code, be careful
not to do things like unlocking the plug-in resource or closing the resource
file; also, the spec for the callback should specify what you expect the
world to look like (chances are you should expect it restored to the state
it was when the plug-in was initially called. This means that if the plug-in
creates an A5 world for its globals, or changes the graphics world
(port/gdevice) and the like, they should be restored to the ones on entry
before calling. I know these might sound obvious, but they are easily
avoidable pitfalls that you should be careful about.

- -Ivanski
- ---
Ivan Cavero Belaunde
DiVA Corporation
#include <std_disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (James Davis)
Date: 7 Apr 92 16:33:14 GMT
Organization: Computing Services, UC Davis

In article <[e-mail]> [e-mail] (Ed Watkeys) writes:
>
>While I didn't make the original post, I have a question about this... I'm
>writing a BBS program, and I have routines to do i/o over the connection (with
>the CTB, of course...); how can I have the plug-in call routines within my
>program's code?
>
>Ed
>

This is an important point that I was wondering too.  I sort of assumed
that you could access routines in the main code the same way you
can access global variables.  Something about setting up the A5 World.
At any rate I had intended to do some more reading of IM, before showing
my ignorance in this area, but since at least one other soul was confused,
thought it'd be safe to add my voice. :-)

James Davis ([e-mail]) : Computing Services : UCDavis

+++++++++++++++++++++++++++

From: [e-mail] (Robert Horn)
Organization: SUNY at Stony Brook where no one gets an education
Date: Tue, 7 Apr 1992 23:20:48 GMT

In article <[e-mail]> [e-mail] (Ed Watkeys) writes:
>
>
>While I didn't make the original post, I have a question about this... I'm
>writing a BBS program, and I have routines to do i/o over the connection (with
>the CTB, of course...); how can I have the plug-in call routines within my
>program's code?
>

The plug in has no access to your applications jump tables (?) (at least in
THINK languages) and so would not be able to call your application's routines
unless you pass the addresses of the routines to your plug-in resource/routine,
and could only then call your routines through the pointers to the functions.
(Pascal can't do this as it doesn't allow you to call a function through a
pointer.) (you might want to glance at your favorite(sp?) C book's section on
pointers to functions)

i.e.,

<<File FuncBlock.h>>
typedef struct FuncBlock FuncBlock, *FuncBlockPtr;
typedef pascal void (**MagicFunctionHandle)(const FuncBlockPtr);

struct FuncBlock
{
    /* pointers to functions, NOT methods */
    void (*func1)(short, short);
    pascal OSErr (*fluffyFunc)(const Rect *);
};

<<File Plug-In.c>>
#include "FuncBlock.h"
// this gets compiled as a resource, in a seperate project.
pascal void main(const FuncBlockPtr pBlock)
{
    Rect        theRect;
    OSErr        theErr;
    // assorted other stuff... (Lock down this handle)

    theErr = (*pBlock->fluffyFunc)(&theRect);
        // valid call.

    // assorted other things...
}

<<File app.c>>

    ...
    MagicFunctionHandle    hFunc;
    FuncBlock        block;

    block.func1 = some_function;
    block.fluffyFunc = some_other_function;

    hFunc = GetResource(your_resource_type, your_resource_id);

    // Lock hFunc if it doesn't lock itself

    (**hFunc)(&block);        // call plug in module
                    // the plug in module has access to
                    // some_function and
                    // some_other_function through the
                    // FuncBlock's func1 and fluffyFunc
                    // members.

    // Unlock and/or release plug-in?

    ...


hope this helps,
Rob

- ---
[e-mail] (not a wombat)

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Organization: Oberlin College Computer Science
Date: Wed, 8 Apr 1992 00:54:13 GMT

In article <[e-mail]> [e-mail] (James Davis) writes:

>   Hi,
>       I want to write something, that can take plug-ins that reside
>   in different files.  Similar to Superpaint, etc etc..
>   Anyway, the theory seems easy.  If I have a code resource sitting
>   in this external file, I should be able to just load the resource and
>   make a call to it. But how?  Since which resources are available (which plugins)
>   is determined dynamicly, none of them can reside in the jump-table can they?
>   Anyway, if anyone can point me in the right direction, or refrence me
>   off to the correct example or paper Id appreciate it.
>

 Tech note #256 goes into great detail in pascal and c on how to do
this, including how to implement global data storage.

- -matt hall
- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Mr. Neb)
Date: 8 Apr 92 06:53:50 GMT
Organization: Bowling Green State University B.G., Oh.

>From article <[e-mail]>, by [e-mail] (Robert Horn):
> The plug in has no access to your applications jump tables (?) (at least in
> THINK languages) and so would not be able to call your application's routines
> unless you pass the addresses of the routines to your plug-in resource/routine,
> and could only then call your routines through the pointers to the functions.
> (Pascal can't do this as it doesn't allow you to call a function through a
> pointer.) (you might want to glance at your favorite(sp?) C book's section on
> pointers to functions)
>
 [stuff deleted...]

    Just making the call to the code resource should not change the value
of the A5 register, which points to the application's global variables as
well as the jump table.  If you knew (through previous compilation) the
correct offset into the jump table, couldn't you just jump to that location
in the jump table, using the A5 offset?

    As far as I know, it would seem that this should work.  Does anyone
agree or disagree with this.  I am curious to see if it is felt that this
method would work or not.


    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Robert Horn)
Organization: SUNYat Stony Brook where no one gets an education
Date: Wed, 8 Apr 1992 16:44:04 GMT

In article <[e-mail]> [e-mail] (Mr. Neb) writes:
>From article <[e-mail]>, by [e-mail] (That's me!):
 [ stuff deleted ]
> [stuff deleted...]
>
>    Just making the call to the code resource should not change the value
>of the A5 register, which points to the application's global variables as
>well as the jump table.  If you knew (through previous compilation) the
>correct offset into the jump table, couldn't you just jump to that location
>in the jump table, using the A5 offset?
>
>    As far as I know, it would seem that this should work.  Does anyone
>agree or disagree with this.  I am curious to see if it is felt that this
>method would work or not.
>
>
>    [e-mail]

I've tried something like that: passing an object to a code resource, and
could not access any of the objects methods. (and when i checked the link it
complained that they were not defined) I would assume that the same is true
for functions. When you are compiling your code resource, the compiler would
have no way of knowing where in the application's jump table to look for a
function or procedure or method; and if this were possible, it would have to
resolve the function's location in the jump table at runtime. I don't think
that the jump table has the names of functions or anything else that might
identify the functions in it (Of course, i could be entirely wrong, have never
looked at the jump table in any way, and probably wouldn't understand it if I
did. This last part is pure speculation on my part. Any similarity between it
and any real events or persons is purely coincidental.)

(I was hoping that objects would contain a pointer to a block of pointers to
functions to implement its methods, but I was apparently wrong.)

Rob
- ---
[e-mail] (not an aardvark)


+++++++++++++++++++++++++++

From: [e-mail] (Ed Watkeys)
Date: Wed, 8 Apr 92 19:47:02 EDT
Organization: Guerrilla Networking Project


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Robert Horn) writes:
> In article <[e-mail]> [e-mail] (Mr. Neb) writes:
> >From article <[e-mail]>, by [e-mail] (That's me!):
>  [ stuff deleted ]
> > [stuff deleted...]
> >
> >    Just making the call to the code resource should not change the value
> >of the A5 register, which points to the application's global variables as
> >well as the jump table.  If you knew (through previous compilation) the
> >correct offset into the jump table, couldn't you just jump to that location
> >in the jump table, using the A5 offset?
> >
> >    As far as I know, it would seem that this should work.  Does anyone
> >agree or disagree with this.  I am curious to see if it is felt that this
> >method would work or not.
> >
> >
> >    [e-mail]
>
> I've tried something like that: passing an object to a code resource, and
> could not access any of the objects methods. (and when i checked the link it
> complained that they were not defined) I would assume that the same is true
> for functions. When you are compiling your code resource, the compiler would
> have no way of knowing where in the application's jump table to look for a
> function or procedure or method; and if this were possible, it would have to
> resolve the function's location in the jump table at runtime. I don't think
> that the jump table has the names of functions or anything else that might
> identify the functions in it (Of course, i could be entirely wrong, have never
> looked at the jump table in any way, and probably wouldn't understand it if I
> did. This last part is pure speculation on my part. Any similarity between it
> and any real events or persons is purely coincidental.)
>
> (I was hoping that objects would contain a pointer to a block of pointers to
> functions to implement its methods, but I was apparently wrong.)
>
> Rob
> ---
> [e-mail] (not an aardvark)
>
>

Is the object you wanted to pass to the CODE resource used in the program
anywhere? If I recall correctly, THINK C (or Pascal or both) will, as an
optimization, not include methods in an object that are not called when it
does a smart link, therfore your methods won't exist if you don't use them
from inside the application.

Or I could just be dead wrong...

Ed

- --
Ed Watkeys (Drexel U. Comp Sci)  "...if you wish to strive for peace
[e-mail]              of soul and pleasure, then believe;
[e-mail]      if you wish to be a devotee of truth,
ls.com!phlpa!caligula!edw         then inquire...." -- Nietzsche

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 9 Apr 92 14:15:49 GMT
Organization: The World Public Access UNIX, Brookline, MA

<< If I recall correctly, THINK C (or Pascal or both) will, as an
optimization, not include methods in an object that are not called when it
does a smart link, therfore your methods won't exist if you don't use them
from inside the application. >>

I think you're wrong. I've alwasy understoodthat THINK C's Smart Link is
on a FILE BY FILE and NOT a ROUTINE BY ROUTINE "smartness."


- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 9 Apr 92 14:51:07 GMT
Organization: ICE Engineering, Inc.


Please take a look at integrating "tcl" into your applications
instead of external code resources!!!

Tickle-tcl gives you a COMPLETE scripting language, plus Apple Events,
PLUS external code resources (including the ability to load your own
"coercion" routines for Apple Events)! Furthermore, Ed Lai at Apple
is writing code to let Tickle run HyperCard XCMDs and XFCNs, as well
as FKeys (Shift-Cmd-Number). All of this for free with NO effort.

To see what "tcl" is, go get tickle from the MSEN ftp server and have
a look (ftp.msen.com - pub/vendor/ice/tickle).
Why go to all the effort that has alread been done for you?

Several applications are currently being written to include "tcl"
including Alpha and Harvest C. More will be forthcoming and all will
be "script-compatbile".

tim.

In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Mr. Neb) writes:
> >From article <[e-mail]>, by [e-mail] (Robert Horn):
> > The plug in has no access to your applications jump tables (?) (at least in
> > THINK languages) and so would not be able to call your application's routines
> > unless you pass the addresses of the routines to your plug-in resource/routine,
> > and could only then call your routines through the pointers to the functions.
> > (Pascal can't do this as it doesn't allow you to call a function through a
> > pointer.) (you might want to glance at your favorite(sp?) C book's section on
> > pointers to functions)
> >
>  [stuff deleted...]
>
>     Just making the call to the code resource should not change the value
> of the A5 register, which points to the application's global variables as
> well as the jump table.  If you knew (through previous compilation) the
> correct offset into the jump table, couldn't you just jump to that location
> in the jump table, using the A5 offset?
>
>     As far as I know, it would seem that this should work.  Does anyone
> agree or disagree with this.  I am curious to see if it is felt that this
> method would work or not.
>


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Gavin Eadie)
Date: 9 Apr 92 13:24:19 GMT
Organization: University of Michigan

>writing a BBS program, and I have routines to do i/o over the connection
(with
>the CTB, of course...); how can I have the plug-in call routines within
my
>program's code?

+++++++++++++++++++++++++++

From: [e-mail] (Gavin Eadie)
Date: 9 Apr 92 13:25:16 GMT
Organization: University of Michigan

>writing a BBS program, and I have routines to do i/o over the connection
(with
>the CTB, of course...); how can I have the plug-in call routines within
my
>program's code?

    The usual trick for this is to pass a parameter to your plug-in that is
the
    address of a list of routine addresses (sometimes called a transfer
vector).
    Then the plug in can call back to your main program via the addresses
that
    you provide therein ...

Gavin Eadie, U of Michigan Information Systems

+++++++++++++++++++++++++++

From: [e-mail] (Ed Watkeys)
Date: 9 Apr 92 18:28:37 GMT
Organization: Guerrilla Networking Project


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Joe Zobkiw) writes:
> << If I recall correctly, THINK C (or Pascal or both) will, as an
> optimization, not include methods in an object that are not called when it
> does a smart link, therfore your methods won't exist if you don't use them
> from inside the application. >>
>
> I think you're wrong. I've alwasy understoodthat THINK C's Smart Link is
> on a FILE BY FILE and NOT a ROUTINE BY ROUTINE "smartness."
>

If that's the case, then that's a stupid way to do a smart link.

>  joe zobkiw                     [e-mail]

- --
Ed Watkeys (Drexel U. Comp Sci)  "...if you wish to strive for peace
[e-mail]              of soul and pleasure, then believe;
[e-mail]      if you wish to be a devotee of truth,
ls.com!phlpa!caligula!edw         then inquire...." -- Nietzsche

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 9 Apr 92 20:11:31 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
><< If I recall correctly, THINK C (or Pascal or both) will, as an
>optimization, not include methods in an object that are not called when it
>does a smart link, therfore your methods won't exist if you don't use them
>from inside the application. >>
>
>I think you're wrong. I've alwasy understoodthat THINK C's Smart Link is
>on a FILE BY FILE and NOT a ROUTINE BY ROUTINE "smartness."

I know for certain that THINK Pascal 3.0 or newer does smart linking on a
routine-by-routine basis, and I would suspect recent versions of THINK C
would work in a similar fashion.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 10 Apr 92 14:37:24 GMT
Organization: Symantec Corp.

>>>>> On 9 Apr 92 20:11:31 GMT, [e-mail] (JohnC) said:

 > In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
In article <[e-mail]> [e-mail] (JohnC) writes:

>><< If I recall correctly, THINK C (or Pascal or both) will, as an
>>optimization, not include methods in an object that are not called when it
>>does a smart link, therfore your methods won't exist if you don't use them
>>from inside the application. >>
>>
>>I think you're wrong. I've alwasy understoodthat THINK C's Smart Link is
>>on a FILE BY FILE and NOT a ROUTINE BY ROUTINE "smartness."

 > I know for certain that THINK Pascal 3.0 or newer does smart
 > linking on a routine-by-routine basis, and I would suspect recent
 > versions of THINK C would work in a similar fashion.

You'd think so, right :) ? Well, THINK C 4.x and 5.x both have the
same level of "smart linking" that C 3.x had. They will only leave out
code if an entire file of it is not referenced at all. There are a
couple other things to note:

 - if you add a project file to use as a library (like ANSI), you'll
 get smart linking on a file by file basis *inside* the library. Eg,
 if you just call sin(), you'll just get math.c.

 - C 5.0 lets you create objects by name, like Pascal 3 and 4. You
 can run into cases where you try to create a class on the fly that
 has been linked out. TCL programmers should check out CApplication
 ::ForceClassReferences for more info.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 10 Apr 92 17:17:11 GMT
Organization: Kalamazoo College

[e-mail] writes:
>[e-mail] (Joe Zobkiw) writes:
>>
>>I've alwasy understoodthat THINK C's Smart Link is
>>on a FILE BY FILE and NOT a ROUTINE BY ROUTINE "smartness."
>
>I know for certain that THINK Pascal 3.0 or newer does smart linking on a
>routine-by-routine basis, and I would suspect recent versions of THINK C
>would work in a similar fashion.

No, it's by file.  See the User's Manual, p. 96.  There was also a
ReadMe file that clarified this, maybe the one on the TCL 1.1.2 upgrade.

Out of curiosity, how fast are ThP 3.0's smart links?
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Almost all portables today employ passive-matrix LCDs, and no one expects
 active-matrix screens to be cost-competitive for a few years" -PC World 2/92

+++++++++++++++++++++++++++

From: [e-mail]
Date: 10 Apr 92 19:28:58 GMT
Organization: Adept Solutions

In article <[e-mail]> [e-mail]
(Robert Horn) writes:
> In article <[e-mail]> [e-mail] (Ed
Watkeys) writes:
> (Pascal can't do this as it doesn't allow you to call a function through a
> pointer.) (you might want to glance at your favorite(sp?) C book's section on
> pointers to functions)

If HyperCard can, then you certainly can, and here's how. First you define a
calling structure for your code resource. I usually use one parameter, a
app-specific param block, so the code-resource routine looks something like:

Function CodeMain(blockPtr:myParamBlockPtr):OSErr;

Then in my app, I have a stub that looks like:

function CallCodeRSRC(blockPtr:myParamBlockPtr; codeResource:Handle):OSErr;
INLINE $205F, $2050, $4E90;

The inline's basically pop the handle off the stack, dereference it, then jump
to it. Be sure to lock down the codeResource after getting it.

If have a routine in your app, that you wanted to call in the resource, first
make a procPtr field in your parameter block. (myParamBlockRec, in our case);

    myParamBlockRec.myRoutine := @myRoutine;
    ..
    codeResource := GetResource('myCO',128);    { What you compiled }
    HLock(codeResource);
    err := CallCodeRSRC(&myParamBlockRec,codeResource);
    ..

Assuming there is a

    Function myRoutine(var r:Rect):Boolean;

in your app, you would call back this routine, in your code resource, by
having a stub that has the same parameters, (including return value), with an
additional procPtr at the end.

    Function appMyRoutine(var r:Rect; callback:ProcPtr):Boolean;
    INLINE $205F,$4E90;

Therefore, in your code resource, to call the app routine, you have this:

    Function CodeMain(blockPtr:myParamBlockPtr):OSErr;
    var
        b:Boolean;
        r:Rect;
    begin
        ..
        b := appMyRoutine(r,myParamBlockPtr^.myRoutine);
        ..
    end;

The INLINE stuff is an assembly glue to do what 'c' can do syntactically.
the code would have simply been:

    b = (*myParamBlockPtr->myRoutine)(&r);

and for calling a handle:

    err = (**codeResource)(&myParamBlockRec);

(With all the appropriate prototyping & type checking left as an exercise for
the reader). :-)

Hope this helps.
- --
Roy Lovejoy      | internet:  [e-mail]
Head RGB Guy     | AppleLink: adept
Adept Solutions  | CIS:       72447,1447
.................| dual certified developer: NeXT & Apple ;)

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 12 Apr 92 03:59:20 GMT

In <[e-mail]> [e-mail] (Joe Zobkiw) writes:

><< If I recall correctly, THINK C (or Pascal or both) will, as an
>optimization, not include methods in an object that are not called when it
>does a smart link, therfore your methods won't exist if you don't use them
>from inside the application. >>

>I think you're wrong. I've alwasy understoodthat THINK C's Smart Link is
>on a FILE BY FILE and NOT a ROUTINE BY ROUTINE "smartness."


Yes, it does do it file by file.  But, can you trust this not to change?
Defensive programming now might save you a lot of debugging time in
the future.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Thomas R. Kimpton)
Date: 22 Apr 92 17:30:06 GMT
Organization: Digital Technology, International

Since I haven't seen anyone mention it, 4D can use externals
in it's scripting.  As has been discussed (in the abstract),
4D uses a "dispatcher" routine that is visible to it (located
at the beginning of the resource), with selectors to call your
routines.  The programmer makes his routines available to
4D by filling in a STR# resource with the name of the routine
and it's arguments:

    myRoutine(&I,&R,&S):&I

meaning a function returning an integer(short) whose arguments
are an integer, real(float), and str255.  All arguments are
passed by pointer in an array of arguments.  The index into
the STR# is the number of the selector passed to the "dispatcher".

In addition 4D passes a pointer to a global data handle.  When
the external is first loaded it is called with a selector of
- -1, this tells the external to do any initialization it needs
and to allocate any global storage it needs. When the external
is to be disposed it is called with a selector of -2 allowing
it to dispose of any allocated memory.

There is an entire manual full of callback routines, but I
never had the need to use them for what I was doing.




- --
- ---
Tom Kimpton                            [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

---------------------------

End of C.S.M.P. Digest
**********************