Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Using the new AppleTalk interface from Lightspeed C 3.01
Message-ID: <6404@hoptoad.uucp>
Date: 29 Jan 89 20:25:46 GMT
References: <894@mailrus.cc.umich.edu>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 67

In article <894@mailrus.cc.umich.edu> mike@shogun.cc.umich.edu () writes:
>I'm trying to experiment with AppleTalk with my shiny new Lightspeed C
>compiler and I'm having trouble using the new "preferred interface" to
>AppleTalk listed in Volume V.  Specifically, I'm trying to write some
>code to register an entity on the network, and then look for entities
>of that type.  I can't get it to work - it usually crashes big time
>with a call to PLookupName().
>
>        search_name.objStr[0] = 0x01;
>        search_name.objStr[1] = '=';
>        search_name.typeStr[0] = 0x01;
>        search_name.typeStr[1] = '=';
>        search_name.zoneStr[0] = 0x01;
>        search_name.zoneStr[1] = '*';

You haven't stated how search_name is declared, but my best guess is
that it's your problem.  First, the documentation of LookupName in
Inside Mac II-323 is slightly misleading.  It says "EntityPtr points to
the entity's name (in the form shown in figure 13 above)."  However, in
fact the structure in figure 13 is a names table entry and you only
want to use the trailing part of that structure, the entity name.
Don't include the pointer to next entry, internet address, or "used
internally" byte.  Second, unless you have declared each of objStr,
typeStr, and zoneStr as "char[2]", you are initializing incorrectly.
The entity name is not three Str255's in a row, but three variable-size
strings with no space between them.  If you declared like "struct {
char objStr[256], typeStr[256], zoneStr[256]; }" instead, the name will
be parsed incorrectly; one string should start where the previous one ends.
It is best just to use an unstructured character buffer for formatting
entity names.

>        mpp_pb_ptr = (MPPPBptr)NewPtr(sizeof(MPPParamBlock));
>        if (mpp_pb_ptr == (MPPPBptr)0) {
>                err_code = app_memoryErr;
>                goto nomppptr;
>        }

Why not just put the parameter block on the stack?  That is, in an auto
variable?  No sense risking running out of memory and imposing an extra
allocation overhead.  However, this code is not your crashing problem.

>        mpp_pb_ptr->ioCompletion = (ProcPtr)0;
>        mpp_pb_ptr->NBPentityPtr = (Ptr)&search_name;
>        mpp_pb_ptr->NBPretBuffPtr = (Ptr)entity_buffer;
>        mpp_pb_ptr->NBPretBuffSize = 1080;
>        mpp_pb_ptr->NBPmaxToGet = 10;
>        mpp_pb_ptr->NBPinterval = 8;
>        mpp_pb_ptr->NBPcount = 3;
>        err_code = PLookupName(mpp_pb_ptr, false);

This looks fine, which is why I think the problem must be in the
search_name parameter.

One useful debugging technique in these situations is to look at the
network with Peek and see if you are actually sending out any lookup
packets and getting any response.  This should provide you with useful
information, particularly if the search name is formatted incorrectly.

One afterthought: Why are you passing "=" in the type field if you want
to look only for things of a particular type?  The string you're using,
if formatted correctly, will look for all entities of all types on
every zone your bridges can reach.  You need to fill in with a specific
type string.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Don't talk to me about disclaimers!  I invented disclaimers!"
    - The Censored Hacker