Screen ghost?? Part 2

[ivan]

OK.  So it does this system call fine now... the first time.   If another equipment(new file in record) is added then I get this: "Enter Processing Password For input:  " when the record is saved.

What processing password would this be asking for?  And why didn't I need it to save the first one?

-Ivan

--- On Tue, 1/5/10, Nancy Palmquist <nlp at vss3.com> wrote:

From: Nancy Palmquist <nlp at vss3.com>
Subject: Re: Screen ghost??
To: "ivan" <deweyweekender at yahoo.com>
Date: Tuesday, January 5, 2010, 7:49 PM

Ivan:

Try this:

declare doit(150)

doit="$PFPROG/fp/dclerk fesequip -sadd -lx -xa -d -t 130000 -r \""&pm{"\" -h 'EQUIPMENT FILE'  "

system doit{""

If that is still funky try dropping the -h stuff at the end.  See if it is any better.

I have had issues in the past with the system command and generating an expression after the command.  I have had much better luck with giving the system command the expression already evaluated.

You could also expand the PFPROG for it by doing this:

doit=getenv("PFPROG"){"/fp/dclerk fesequip -sadd -lx -xa -d -t 130000 -r \""&pm{"\" -h 'EQUIPMENT FILE'  "

Hope that helps.  You know this kind of logic can be a real bear, opening another session during the first session.  It does work and I have seen entire systems written from one process table and system calls like this.  It seemed messy to my mind but seemed to work for them.  Sometimes I have to get my brain around this and it starts to add too many issues.

I do want to suggest that you want to be sure that you do not have any open lookups with locks when you do this.  It can put you in a deadlock very easily.

Nancy


ivan wrote:
> I was hoping that would be the answer Nancy, but there is no show in that file. There is an input popup command in the line above the system command but that variable is only 10 characters long.  When that line is disabled nothing changes.  Problem is still there.
> 
> Here is the system call we use:
> 
> system "$PFPROG/fp/dclerk fesequip -sadd -lx -xa -d -t 130000 -r \""&pm{"\" -h 'EQUIPMENT FILE'  "
> 
> This line is used in two files and one file runs great, no problems.  
> The other file loads the screen, the debugger that is in the fesequip file shows at the bottom of the screen and the first line after the debug code shows: cr(7,rj), which is the line after a trigger key for getting into field 1, so it starts running some of the file, but then it is like it jumps into... space or something.  
> If I hit the d then only a d appears on the screen, if I hit enter the screen jumps up a line for every time I hit enter.
> 
> What is throwing me is why it works fine in one file but not the other.  And why it would work fine under root for the file it doesn't in, but go through the problem I described when logged in under a regular user. 
> So do you have any other ideas to look at?!?
> 
> -Ivan
> 
> --- On Tue, 1/5/10, Nancy Palmquist <nlp at vss3.com> wrote:
> 
>   
>> From: Nancy Palmquist <nlp at vss3.com>
>> Subject: Re: Screen ghost??
>> To: "ivan" <deweyweekender at yahoo.com>
>> Cc: "filepro" <filepro-list at lists.celestial.com>
>> Date: Tuesday, January 5, 2010, 4:03 PM
>> Ivan,
>> 
>> If you have a show at the bottom of the screen, such as:
>> 
>> show("23","1") variable
>> 
>> Where the variable might be longer than 80
>> characters.  It will scroll the screen exactly as you
>> indicate.  Fix would be to do this:
>> show("23","1") variable{""
>> 
>> to remove any blank space at the end of the variable.
>> 
>> The debugger will often scroll the screen funny so I would
>> not worry about that.  Try the command "D" in the
>> debugger to redisplay the screen.
>> 
>> Nancy
>> 
>> ivan wrote:
>>     
>>> Hi all.  I am having some difficulty tracking
>>>       
>> down an issue that one of our files is having.  We do a
>> system call from two separate files to add information into
>> another file. The call from one file works fine, and the
>> exact same call from another file brings up the screen to
>> add information, then if the user hits enter the screen
>> jumps up one line at a time and not from field to field like
>> it should be.      
>>> Here's where I get confused... when I set the
>>>       
>> debugger, the screen loads and has a line of code at the
>> bottom.  All is normal, then if I hit the enter key to
>> jump to the next line of code the screen moves up a line
>> like when not in debugger mode.  The line of code is
>> just assigning a variable, so there isn't anything that
>> should affect the screen.
>>     
>>> Now if I run this as root, everything works fine. So I
>>>       
>> checked all of the permissions, mod, and owner of the two
>> files that run these system calls and they are exactly the
>> same.  So I'm a little lost here...  Anyone else
>> have this problem? Anyone find a solution???
>>     
>>> We are running filePro version 5.6.06 on a sco unix
>>>       
>> machine.
>>     
>>> Losing more hair by the minute,
>>> -Ivan Chason
>>> 
>>> 
>>>          
>>    _______________________________________________
>>     
>>> Filepro-list mailing list
>>> Filepro-list at lists.celestial.com
>>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>> 
>>>          
>> 
>> -- Nancy Palmquist        MOS & filePro Training Available
>> Virtual Software Systems    Web Based
>> Training and Consulting    PHONE: (412) 835-9417          Web site:  http://www.vss3.com
>> 
>> 
>>     
> 
> 
>       
>   


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




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20100107/4e0966e9/attachment-0001.html