[Coco] new problem with unpack

[Wayne Campbell]

I felt it important enough to supply this short test program that shows a
path number being passed to a different procedure, which then acts on the
file.

PROCEDURE filePathTest
(* Procedure to test passing file path byte to another procedure *)
DIM fPath:BYTE
DIM killTime:REAL
DIM fOpen:BOOLEAN
DIM fName:STRING[29]; test$:STRING

PRINT "We will demonstrate passing a path number to another procedure."

test$:="Hello testProc"
fName:="testPath.txt"
fOpen:=FALSE

CREATE #fPath,fName
fOpen:=TRUE
PRINT #fPath,test$

PRINT "The path: "; fPath; " is opened to the file: "; fName
PRINT "I am passing the message: """;test$;""" to testProc through the
file."
FOR killTime:=1.0 TO 1000. STEP 1.
NEXT killTime

RUN testProc (fPath,fOpen)

SEEK #fPath,0
READ #fPath,test$
PRINT "I received the message: """;test$;""" from testProc"

CLOSE #fPath
fOpen:=FALSE

END

PROCEDURE testProc

DIM test$:STRING
DIM killTime:REAL

PARAM fPath:BYTE; fOpen:BOOLEAN

PRINT "testProc here, and I was passed path#: "; fPath

IF fOpen THEN
SEEK #fPath,0
READ #fPath,test$
PRINT "I received the message: """;test$;""" from filePathTest"

test$:="Hi back, filePathTest"
PRINT "I am sending back the message: """;test$;""" to filePathTest"
SEEK #fPath,0
PRINT #fPath,test$
ENDIF
FOR killTime:=1.0 TO 1000. STEP 1.
NEXT killTime

END



On Thu, Oct 31, 2013 at 12:41 PM, Wayne Campbell <asa.rand at gmail.com> wrote:

> On Thu, Oct 31, 2013 at 11:49 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>
>> Just a quick question, I haven't read carefully enough probably, but you
>> aren't trying to access a file path opened in one module from a different
>> module are you? I wouldn't think that could work.  Ignore me if this is
>> irrelevant.
>>
>
> Actually, this is not only what I am doing, it also works very well.
> Basic09 allows you to pass a file path variable to another procedure and
> that procedure will act on the open file. That is how getHeader works. It
> gets the header from the open filepath, determines the parts it needs to
> determine, and passes control back to unpack with one of three outcomes:
>
> 1. file is not executable, close path and end with error report
> 2. file is executable and module is not I-Code, skip module and continue
> 3. file is executable and module is I-Code, process module and continue
>
>
>> Also to add another possible mechanism for sharing data between processes
>> check out "data" modules.  These can be accessed from multiple processes
>> simultaneously and can be used to implement simple locking/synchronization
>> mechanisms.  You could (for instance) have one program load the data
>> module, chain to a program that parses it, chain to another that outputs
>> it.  Stuff like that, with each step in the chain having access to all the
>> memory used by any of the steps.
>>
>
> You and I discussed this before. I can think of many uses for data
> modules, but I need to learn more about compiling them and setting entry
> and exit points so different processes can make use of different parts of
> the same data module.
>
> Wayne
>
>


-- 
The Structure of I-Code
http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code

decode
http://cococoding.com/wayne/