Reuseable entry screen/processing...

[Brian K. White]

----- Original Message ----- 
From: "Chad McWilliams" <chad at computiprint.com>
To: "'filePro mailing list'" <filepro-list at seaslug.org>
Sent: Thursday, April 28, 2005 9:34 AM
Subject: Reuseable entry screen/processing...


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
---------------------

I wouldn't say @wef/@wlf don't work from a call table. I would say they 
don't work as might be expected. Further, I'll say they don't work as I 
expect or desire.

I recently discovered the hard way that if you have a screen command in a 
call table, and the screen has real fields in it, and there are @wef/@wlf 
for those fields in the parent process, then when the call table reaches the 
screen command, the processing jumps back to the parent table to run the 
@wef and @wlf, ... And Stays There! The next line of code executed after the 
first @wlf of the screen field, is the line after the call command in the 
parent table! This call table did not have any @wef/@wlf in the call table 
itself by the way. I wasn't surprised that the wrong @w* ran, I was 
surprised that any @w* ran, and even more surprised that my call processing 
was not proceeding past that screen statement.

The available work-arounds as I see them are to redraw the screen with 
dummies and use the dummies in the call table and ensure that no @wef/@wlf 
for those dummies exist in the parent. That should stop you from popping out 
of the call back to the parent before you wanted, but the other half of the 
battle, I haven't tested if putting @wef/@wlf-dummy in the call table works 
or not. Or do everything with other forms of input.

Most of my call tables don't happen to collect input via screen fields so I 
don't have a lot of help, just that gotcha I just happened to hit yesterday. 
I don't necessarily mean to suggest that this is a bug or even contrary to 
the documentation. I do feel that this is one of those many little things 
that aren't spelled out explicitly in the docs, and should be, because in my 
opinion this isn't something that can be deduced from them as they are, and 
is something a developer needs to know. I have no strong opinion on whether 
the behavior should be changed, or if changed, in what way.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani