system command - problem resolved

[Dennis Malen]

Ken,

The existence of the SCREEN command affected our manual resolution which was 
if we were in a screen that possessed an unprotected field then we had to do 
two things: Ctrl-C (get us out of update) and Ctrl-L (redraw the screen). If 
in a screen with all protected fields, then we only had to Ctrl-L.

I can only tell you that "noredraw" worked. If we left it out we got hung 
up. Simple, so when filePro attempted to redraw the screen the system got 
hung up when "noredraw" was not present.

It appears in filePro's attempt to redraw the screen when "noredraw" is not 
present causes the cursor to hang at the end of the top third of the screen. 
When "noredraw" was present filePro did not attempt to redraw the screen as 
the screen was viewable for the user to see. Again, when filePro attempts to 
redraw the screen we have a problem. You may be right that it should not act 
that way but it does.

Regards,

Dennis
----- Original Message ----- 
From: "Kenneth Brody" <kenbrody at bestweb.net>
To: "Dennis Malen" <dmalen at malen.com>
Cc: "pmahler" <pmahler at malen.com>; "Fplist (E-mail)" 
<filepro-list at seaslug.org>
Sent: Monday, November 07, 2005 4:15 PM
Subject: Re: system command - problem resolved


> Quoting Dennis Malen (Mon, 7 Nov 2005 16:00:41 -0500):
>
> [...]
>> First, what I meant by "open fields" was that they were not restricted
>> fields. The screen could be put in update mode.
>
> Okay.  But, without the SCREEN command, your processing never takes
> you into update mode on a screen.  How does the presence/absence of
> unprotected fields (I assume that's what you mean by "not restricted"?)
> affect the behavior?
>
>> Ctrl-L did work in both types of screens. With unrestricted fields we
>> had to add the Ctrl-C and then use the Ctrl-L manually.
>
> These two statements are contradictory.  Either Ctrl-L worked without
> the Ctrl-C, or it didn't.  Which one is it?
>
>> I experimented with the screen command because of a prior request from
>> the list.
>
> Okay.
>
>> Ken I never got to the point of testing the "echo hello". I did try the
>> sleep command and that had no effect.
>
> That must have been someone else's suggestion.
>
>> Once I received John's e-mail it was easier to test his suggestions
>> first which was a combination of using the "noredraw" and the "display"
>> command.
>
> If anything, "noredraw" would make things worse, as that tells filePro
> to _not_ redraw the screen.  Since the current processing tells filePro
> to redraw the screen, yet it's not been redrawn, adding "noredraw" should
> not help the situation.
>
>> We tried system command without noredraw and used the display (@sn)
>> command. That did not work. We then added noredraw after the system
>> command and left in the display command. That did work. We then removed
>> the display command and left the noredraw in. That also worked.
>
> Huh?  Telling filePro to not redraw the screen allows the screen to be
> correct, but having filePro redraw the screen causes it to be blank?
>
>> The following is what now works:
>>
>> Then: le="echo";lg="\"\\033&o";pa="Fvar
>> searchnum="{@rn{";CompileFile(\\"260268.cs\\");\\015\""
>>
>> Then: system noredraw le<lg{pa;le="";lg="";pa="";end
>
> If the exact processing above does not work without the "noredraw",
> then things are horribly wrong with your system.  If not redrawing
> the screen means the screen is good, then redrawing the screen can't
> mess it up.  (Especially when you're saying that Ctrl-L, which will
> redraw the screen exactly the same way that SYSTEM without the
> NOREDRAW will, works fine.)
>
> [...]
>
> --
> KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
> http://www.hvcomputer.com
> http://www.fileProPlus.com
>
>
>