At 1:29 AM -0500 11/8/97, M Goodes wrote:
>Correction #2:
>>  thePortRefNum&=thePPCOpenPBRec.portRefNum
>    BLOCKMOVE @thePPCOpenPBRec+_portRefNum,thePortRefNum&,2
>    BLOCKMOVE @thePPCOpenPBRec+_nbpRegistered&,nbpRegisteredflag&,4

That's quite a mouthful.  Is there currently any way to get a local
variable to share memory space with a variable that is passed in?  If not,
could this be a potential FB3 request?

Example: in pascal, the following is valid:

procedure foo(var bar: integer);

begin
   bar:=123;
end;

begin
   myInt:=321;
   foo(myInt);
   writeln(myInt);
end;


The output is 123, since foo changed it.  It's certainly a lot simpler,
both to create and to read, if changes to values were variable assignments
rather than memory moves.

That said, your solution has worked.  Thanks for the hand. :)

>(Possible) correction #3:
>   There is an inconsistency in the way you assign strings to the records.
>You have fixed record lengths but you are
>   passing strings which vary in length.  The way that Toolbox records
>usually get around this is to require you to
>   specify the address of the string, not the string itself.
>Alternatively, they may require a string to be a specific
>   length, as with the strings that we use to identify resouce types.  I
>suggest double-checking your documentation
>   to make sure that you are specifying the string information correctly.

Good point.  In this case, the calls are, for the most part, asking for 32
character strings.  I had thought that the DEF LEN = 32 would solve that,
but perhaps it didn't.  When I changed

theLocationNameRec.nbpType$ = "PPC Example"

to:

myString$ = "PPC Example"
theLocationNameRec.nbpType$ = myString$

the crashes stopped.  Could this perhaps be because DEF LEN doesn't
actually limit such string assignments to records to its length?  Or could
someone offer me a more accurate explanation?

As of right now, though, I've gotten to the point where my crashes are
occurring later at the program, and only when I try to use certain ports.
I'll try to puzzle out the crashes on my own before I bug the list about
what is likely a simple mistake.

>M Goodes (wave@...)

-- Brian Victor