display vs video sync vs ^L

[Kenneth Brody]

Quoting Brian K. White (Wed, 17 Jan 2007 04:48:57 -0500):
[...]
> I'm putting
> Then: printer "destpr"
> where destpr is a script that captures stdin to a temp file and then
> runs an rclerk process
> rclerk .... -r $tempfile <$tty
>
>
[...]
> printer "destpr"
> form "someform"
> printer reset
>
>
> Except... upon returning from the printer command, the screen is left
> mostly blank except for the bottom of the screen prompts.

filePro isn't expecting to have the screen cleared when you print
something.

> I tried putting both display and video sync after the printer reset to
> no effect.

That's because filePro thinks the screen is already up-to-date and
doesn't need to display anything to refresh it.  Consider what would
happen with:

    system noredraw "cls"

> I noticed that pressing Ctrl-L does refresh the screen.

Correct.  That forces filePro to clear the screen and redraw it from
scratch, rather than simply update the things that have changed.

> I failed to find a definitive list of special codes understuud by
> pushkey to try and push a Ctrl-L from within filepro.

As you mention below, it's "DRAW".

> I finally figured out pushkey "[DRAW]"  by doing "strings rclerk |less",
[...]
> the pushkey actually did cause a refresh like Ctrl-L.
> (I was prepared to find that ctrl-l worked at the os or shell level as
> part of the tty line discipline and stty settings, and that trying to
> pushkey from inside fp wouldn't have the desired effect, that it
> needs to come from the terminal for real, happy surprise it actually
> works)

The O/S has no concept of what is on the screen.  Some screen managers,
like "screen", _may_ keep track of this to enable multiple screens on
one physical display.

Consider what happens if you press Ctrl-L at the shell prompt.

> My question is, is that really the only way to get the screen to redraw?
> I never like relying on pushkeys. Just seems too Rube Goldberg.
> The descriptions for display and video sync both say they will redraw
> the screen, why don't they?

You could do:

    system "cls"

(Note the absense of "noredraw".)  This will force filePro to assume
that the entire screen is invalid, and redraw it from scratch, just
as it does on Ctrl-L.  Any command will suffice, of course.

> Btw this is @key processing so a screen command isn't indicated.
> Besides, I tried that and the screen stayed blank. It went into update
> mode because the cursor went to the place on the screen where the first
> field would be if it were visible.
>
> Also, it would be super duper if there was some way to control how a sub
> process like a printer command gets run.

What sort of control are you thinking of?

> In this case, after getting all this working, I think I really can't use
> it anyways because:
>
> The sub process is getting run as user filepro.
> This, (or something) causes the rclerk process to be unable to read or
> write the tty the user is on.

I can't see how that is possible, as stdin/out/err are already open,
and simply passed to the child process.

[...]

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com