Process bypass

[Kenneth Brody]

On 9/27/2012 6:42 PM, Rami Mantoura wrote:
> 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.

I thought you said that it was @WEF10 in the input table that did the CHAIN?

>
> 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
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>

-- 
Kenneth Brody