Process bypass

[Rami Mantoura]

Ken,

Ok, I think I got it but I guess something changed. The way I had it when
it went to the chained prcess the first thing it did was @wef10.... I now
changed that to @update.

It works...

Thanks
Rami

On Thu, Sep 27, 2012 at 5:19 PM, Rami Mantoura <ramim at foremostsystems.com>wrote:

> OK, Let me try...
>
> Menu Item "rclerk gwotoday -s1 -h "working"
> We go into add records. Its starts with auto of course and at the end of
> that it goes to input (by itself of course)
> wef10: chain "chscr1". We are now on screen 1, field 10. We enter data.
> and when done we hit esc esc. It should at that point go to the top of
> chscr1 table (at least that is what is supposed to do). Thats what it does
> on old system. Instead it jumps straight to auto and leaves me on the
> screen in field 10. If I create the second record then it does what it is
> supposed to and goes to the top of the chscr1 table.
>
> I really dont get it and yes I am sure we are using the exact tables. I
> have been testing and debugging.
>
> Thanks
> Rami
>
> On Thu, Sep 27, 2012 at 4:54 PM, Kenneth Brody <kenbrody at spamcop.net>wrote:
>
>> On 9/27/2012 4:44 PM, Rami Mantoura wrote:
>>
>>> When in input it checks a status and the command is (chain "chscr1"). it
>>> leaves me in screen 1. I update the fields and hit esc esc. My old server
>>> would go to the top of chscr1 table. not it goes directly to auto.
>>> Nothing
>>> changed. All I did was move the complete file from one server to the
>>> other.
>>> It still works on the old server now.
>>>
>>
>> You still haven't explained all the steps that goes on.
>>
>> Break it down, step by step...
>>
>> How is input processing started in the first place?
>>
>> When does the CHAIN occur?
>>
>> What happens in the chained processing?
>>
>> What causes the person to enter update on a screen while in the chained
>> process?
>>
>> Are you 100% certain that you have identical processing on the old system
>> and the new system?
>>
>> Where, exactly, does processing go on the old "working" system, when the
>> user presses SAVE while updating the screen from within the chained process?
>>
>>
>> Note that the only time processing implicitly starts at line 1 of the
>> input table is when pressing SAVE on a screen when no processing was
>> currently running.  Yet, you say you are already running processing when
>> filePro somehow starts at line 1.
>>
>>
>>
>>  On Thu, Sep 27, 2012 at 4:26 PM, Kenneth Brody <kenbrody at spamcop.net>
>>> wrote:
>>>
>>>  On 9/27/2012 3:26 PM, Rami Mantoura wrote:
>>>>
>>>>  Here is the sequence and keep in mind it does work on the SCO box
>>>>> currently
>>>>> so I am wondering if something changed.
>>>>> Auto process starts, then input processing, It does a chain command to
>>>>> a
>>>>> second process. (here is the problem) They fill in data and hit esc
>>>>> esc.
>>>>> (it should go to the top of the second process at that point....
>>>>> Correct?)
>>>>> then back to auto and then input.
>>>>>
>>>>>  [...]
>>>>
>>>> How, exactly, does "then input processing" occur?  What causes input
>>>> processing to start?  Where does it do the CHAIN?  How does the
>>>> chained-to
>>>> process enter update on a screen?
>>>>
>>>
>> --
>> Kenneth Brody
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20120927/22c513e4/attachment.html