Re: Parameters by Reference/PPC Toolbox
Posted by: bhv11 <bhv11@...>
>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