Reuseable entry screen/processing...

[Nancy Palmquist]

Chad McWilliams wrote:

> Wanted to get everyone's input on this.  Maybe I'm overlooking something.
> 
> I have an input screen, along with it's associated processing, that I want
> to use in two different programs.  Is there anyway to do this without having
> to embed the input processing within the 2 programs (thus doubling my work
> and potential errors anytime I need to make a change to the input
> processing) with which I want to use it?  Incidentally, I am trying to call
> this, in both situations, from currently running input processing.
> 
> I have tried to CALL the processing from within my program, but from what I
> see, field triggers aren't support within called processing.
> 
> I realize I can just system out and run the processing, but this would not
> be possible on a single user license, as I understand it.  I only have
> multiuser systems presently, so I have no way to test that.
> 
> Any ideas?
> 
> -Chad McWilliams
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 
Chad,

You can use CHAIN and it will CHAIN to a process in another file.

I do this with CALL but I since CHAIN will also take a path, it would 
work just as well with CHAIN.

I have a file called: library

It contains all the programming that will be shared between files.

CHAIN PFDATA{PFDIR{"/filepro/library/process"

where you have properly loaded PFDATA and PFDIR from the environment.

CHAIN replaces the table for input or output and will process to END. 
If you want the programming to return to the table that you started on, 
just CHAIN back.

It is not a subroutine and does not return to the place it was called in 
the logic.  It starts execution at the top.

CALL does do @WHEN's , but CHAIN is exactly like INPUT processing so it 
is what you want.

CALL can not function as a full data entry routine.  It is good for 
routines that do not interact with data entry or have very simple data 
entry that can be done with a popup.  I have designed printer selection 
functions, authorization functions, logging functions and others to be 
called and one table provides that for 40+ files, greatly simplifying 
the update of the logic, since as all good programmers know, it is 
easier to have only one place to go to fix something.  IT is cleaner, 
easier to debug and much more reliable.

If the two files you speak of have identical maps, it could easily be done.

Since the call is done from the point of view of the file you are in, it 
would assume references to real fields would be in the current file.

Good luck

Nancy


-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com