console driving me NUTS

[Fairlight]

Top posted for ya, John...

I'm using entries that contain PV.  And it's not just linux.  As I said,
I've had this happen since 1993 with SCO from 3.2.4.2 through 6.0.  When I
have a PV-containing termcap in use, when I exit from runmenu I'm -not-
back to my colours as they were before I went into runmenu, for instance.
I'm defaulted to white on black and have to manually reset it.  Problem is,
I'm not doing anything special in fP.  I only have to run runmenu and hit X
to exit to get this...no processing at all.  Only thing changing colours is
runmenu itself in that case--but not setting them back on either platform.

Literally:

runmenu
X

Colors are white on black until I do something to reset them.  It's that
simple.  Happened with scoansi last week on OSR6--it's not just linux.

I just made aliases for rreport, rclerk, rcabe, ddefine, and p.  I'll add
one for dscreen when I need it, but you know what I'm using this for--I
don't need it.  :)

mark->


>From inside the gravity well of a singularity, John Esak shouted:
> I don't think filePro "sets" any colors and certainly doesn't leave its
> choices up after runmenu runs.  So what could be going on?  For example, if
> I run filePro with the PV specifier not in my termcap undre SCO, I get to
> use the 6 O/S colors.... When I go into filePro they *stay* the same as in
> the O/S and when I leave filePro absolutely nothing  changes.  When I *do*
> have the PV specifier in my termcap, filePro goes into using its full ansi
> color mode.... then, when I leave filePro, I'm back to my six colors again?
> 
> Anything other than that behavior must be on Linux's part... or,another
> possibility  while you are inside filePro, you are running something which
> changes the colors and leaves them that way... a problem I had with my
> fpWord product.  It worked well with the PV full ansi setup, but if it ever
> ran without that PV going for it, wen you came out of fpWord, you were left
> with white on black and that's it. Sucks.  Could you be doing something like
> this? Running an ansi color program inside filePro that screws with your
> colors and then leaves them that way. Certainly, I have never needed a
> "wrapper" around filePro just so it wouldn't screw with my colors... it has
> always treated them perfectly.
> 
> John
> 
> t
> 
> > -----Original Message-----
> > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> > Behalf Of Fairlight
> > Sent: Sunday, March 04, 2007 9:03 PM
> > To: filePro Mailing List
> > Subject: console driving me NUTS
> >
> >
> > Okay, here's the problem...  Whether it's SCO or linux, I'm having severe
> > issues whenever quitting out of runmenu, as it refuses to reset the
> > terminal colours to what they were.  It insists on leaving it
> > with white on
> > black.
> >
> > Under SCO, not so big an issue...I wrap it in an alias that calls setcolor
> > afterwards.
> >
> > Under linux, I'd swear I used to know how to do this...at least on virtual
> > consoles.  I've tried tput with setb and setf, and that does
> > nothing.  I've
> > tried tput reset, and it will reset the background with a screen
> > redraw--BUT, not the foreground colour, and the background
> > reverts to black
> > as you type, making it ugly as sin.
> >
> > Worse still, I'm using Anzio for this one particular purpose, and
> > if I tell
> > it to reset the terminal, it doesn't reset the drawing to use the
> > colours I
> > defined, it actually sets the colours to things that were -not-
> > saved...looks like it reverts to defaults for the terminal type.
> >
> > How the BLOODY hell do I get linux to reset both foreground and background
> > colours after filePro refuses to clean up its mess.  The only surefire way
> > I've found is to use something else that has screen control, like vim.
> > Then it resets just fine.  That's not a solution.
> >
> > I can't lay this at Anzio's feet, as fP does this under any
> > emulator on any
> > system if you use colour.  I mean, I can have mutt up in full colour that
> > doesn't match the actual colours I set, and if I suspend it, my
> > terminal is
> > as it should be...with the colours I had defined.  Only fP does
> > this to me.
> >
> > I don't really care whose fault it is, I just want a solution under
> > linux--from remote, not on a VC.  Already have one for SCO.  I've wasted
> > an hour of time trying to get this %()&! thing fixed, and I'm -quite- put
> > out with fP at the moment.  Instead of getting something done,
> > I'm fighting
> > with something that's been broken since at least 1993 and never fixed.  (I
> > had this problem with 4.1 on SCO 3.2.4.2 and had to institute the setcolor
> > fix then, too.)
> >
> > Surely someone's tackled this and solved it before...do tell,
> > please.  Save
> > what little of my sanity is left.
> >
> > mark->
> > --
> > Fairlight->   ||| Was Jesus a stable release?        | Fairlight
> > Consulting
> >   __/\__      |||                                    |
> >  <__<>__>     |||                                    |
> http://www.fairlite.com
>     \/        |||                                    | info at fairlite.com
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list

-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!