Quote from Forum Archives on November 8, 1997, 1:13 pm

Posted by: bhv11 <bhv11@...>

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@netcom.ca)

-- Brian Victor