[net.micro.amiga] More VT100 Problems

danny@convex.UUCP (10/12/86)

For the nth time, I'd like to congradulate everybody involved in the VT100
program but there seems to be (another) bug.  When VT100 (old or new) starts
up, I have it set to open it's own two-color screen.  The window starts down
just a little.  Everything is fine and the window is a perfect 640X200.

BUT, after I move THE SCREEN, things change, the screen grows down a little
and the y hot point of the mouse goes down some.  What's even weirder, when
I drag the screen down, the top of the pointer (original y hot point) is at
the point where the mixed up point is normally but the y point gets mixed up
again later.  It's just plain weird.

The window before and after moving the screen is 24 lines down but after the
screen is moved, the window can move down without cutting if off.  This freaks
me out because the window shouldn't be able to move below the screen but it
does and after the screen is fixed, doesn't but can go down exactly one line.

I hope somebody can understand what I've said because I'm a little confused
myself...  Thanks.
By the way, this would be a good fix to throw in with 2.2

PLEASE ALSO when using a 4 color or more screen, change the color for bolding
instead of SetSoftStyle() and don't go and truncate the italics to fit 8x8.
Better yet, make this all optional:  either in vt100.init or menu.
Something like:  systemfontstyle=TRUE; or systemfontstyle=FALSE; and go from
there.  Double width/height fonts might be good too.  If anybody has a 6X8
font, you might even be able to do 132 columns.  The trick would be to open
a screen wider than 640.  One more thing, after the cursor gets past column
80, force a ^M^J so that I can type/see a line longer than 80 columns.  That
or put in scroll bars at the bottom ala Textcraft (Yecho! 8-)


Dan Wallach
...!ihnp4!convex!danny

vanam@pttesac.UUCP (Marnix van Ammers) (10/14/86)

In article <93500049@convex> danny@convex.UUCP writes:
>
>For the nth time, I'd like to congradulate everybody involved in the VT100
>program but there seems to be (another) bug.  When VT100 (old or new) starts
>up, I have it set to open it's own two-color screen.  The window starts down
>just a little.  Everything is fine and the window is a perfect 640X200.
>
>BUT, after I move THE SCREEN, things change, the screen grows down a little
>and the y hot point of the mouse goes down some.  What's even weirder, when
>I drag the screen down, the top of the pointer (original y hot point) is at
>the point where the mixed up point is normally but the y point gets mixed up
>again later.  It's just plain weird.
>
>The window before and after moving the screen is 24 lines down but after the
>screen is moved, the window can move down without cutting if off.  This freaks
>me out because the window shouldn't be able to move below the screen but it
>does and after the screen is fixed, doesn't but can go down exactly one line.
>
>I hope somebody can understand what I've said because I'm a little confused
>myself...  Thanks.

I think I have the same problem.  It is so hard to describe that
I haven't bothered to try.  But moving the window/screen up and
down causes problems.

As for enhancements, I would like an auto-wrap option and also a
printer on/off option.

One more thing.  I mentioned a while ago that *my* version ov VT100
leaves DTR on even after I click the go-away gadget.  I thought this
was a real neat feature.  But according to Wecker, the program does
*not* leave DTR on.  So now I've found that this thing that I thought
was a feature, actually only happens under certain circumstances.  I'm
trying to isolate just when I get this feature.  For some reason I
could not get the feature to work at all last night (DTR kept going off
when I quit the program) but I swear, the night before it was working
just as I've said: DTR remained on.  I will post the details when I
figure it all out.

I want to join the Dave Wecker fan club too.

Marnix

bill@dayton.UUCP (William T. Argyros) (10/16/86)

In article <305@pttesac.UUCP> vanam@pttesac.UUCP (-Root Admin-) writes:
>In article <93500049@convex> danny@convex.UUCP writes:
>>BUT, after I move THE SCREEN, things change, the screen grows down a little
>>and the y hot point of the mouse goes down some.  What's even weirder, when
>>I drag the screen down, the top of the pointer (original y hot point) is at
>>the point where the mixed up point is normally but the y point gets mixed up
>>again later.  It's just plain weird.
>>I hope somebody can understand what I've said because I'm a little confused
>>myself...  Thanks.
>
>I think I have the same problem.  It is so hard to describe that
 Stuff
>As for enhancements, I would like an auto-wrap option and also a
>printer on/off option.
>Marnix

I have played with the strange screen moving/pointer-hot-spot-changing
also.  What happens is this:
 You can move the window down away from the Screen Bar (If you have not
modified your source at all, it already starts 3 pixels down...). Now you
can grap the Screen Bar and move it down.  When you move the screen back
up again, there is a point, as you all know, when the screen stops moving
up because it is at the top (makes sense, no?).  If you continue to move
the mouse up at this point, the pointer will move, ON the Screen Bar.
When this happens, the "Hot Point" of the pointer remains stationary, and
the immage of the pointer moves up in relation to it.  You can "undo" this
effect by again moving the screen down, then up again, stopping your mouse
travel at the exact pixel that puts the screen at the very top.  Move any
farther up, and you re-create the problem.  As of yet I have no idea why
this happens, does anyone else?


-- 
UUCP: ihnp4!rosevax!dayton!bill         Bill Argyros
ATT:  (612) 375-2816                    Dayton-Hudson Dept. Store. Co.
                                        700 on the Mall
                                        Mpls, Mn. 55402

hamilton@uiucuxc.CSO.UIUC.EDU (10/16/86)

> One more thing.  I mentioned a while ago that *my* version ov VT100
> leaves DTR on even after I click the go-away gadget.  I thought this
> was a real neat feature.  But according to Wecker, the program does
> *not* leave DTR on.  So now I've found that this thing that I thought
> was a feature, actually only happens under certain circumstances.  I'm
> trying to isolate just when I get this feature.  For some reason I
> could not get the feature to work at all last night (DTR kept going off
> when I quit the program) but I swear, the night before it was working
> just as I've said: DTR remained on.  I will post the details when I
> figure it all out.

    are you switching back and forth between terminal emulators?  or
are you using a midi interface on the serial port?  i think that if
DTR happens to be high when vt100 (or anything else that uses the Exec
serial.device interface) opens the serial device, it will be restored
to that state when the device is closed.  thus, if you want DTR on all
the time, you could write a short hack that would poke the 8520 port
that controls DTR.  this would "break" the hangup() code in vt100 v2.2,
but you could use +++/ATH0 to hangup manually.

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton%uiucuxc@a.cs.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%uiucuxc@uiuc.csnet	Phone:	(217)333-8703
CIS:    [73047,544]			PLink: w hamilton

danny@convex.UUCP (10/17/86)

I've found out that to do a printer toggle (on just about any stupid terminal)
just simply save to the file:
prt:

yes, 'p','r','t',':'

That's the printer device - it will ask for your Workbench if you haven't 
already used it so it can load the driver.  I myself use 'par:' since my
printer's on the parallel anyway (Epson FX-85) and for some reason, 'prt:'
spits out an extra blank line on top (grrrr.  Bug alert!  Bug alert!)

Dan Wallach

mwm@eris.berkeley.edu (Mike (Don't have strength to leave) Meyer) (10/17/86)

In article <212@dayton.UUCP> bill@dayton.UUCP (William T. Argyros) writes:
>I have played with the strange screen moving/pointer-hot-spot-changing
>also.  What happens is this:
> You can move the window down away from the Screen Bar (If you have not
>modified your source at all, it already starts 3 pixels down...). Now you
>can grap the Screen Bar and move it down.  When you move the screen back
>up again, there is a point, as you all know, when the screen stops moving
>up because it is at the top (makes sense, no?).  If you continue to move
>the mouse up at this point, the pointer will move, ON the Screen Bar.
>When this happens, the "Hot Point" of the pointer remains stationary, and
>the immage of the pointer moves up in relation to it.  You can "undo" this
>effect by again moving the screen down, then up again, stopping your mouse
>travel at the exact pixel that puts the screen at the very top.  Move any
>farther up, and you re-create the problem.  As of yet I have no idea why
>this happens, does anyone else?

My 2.1 never does that. Then again, I got rid of the screwy
screen/window lengths and positions before I ever turned it on. Since
Dave is doing oddness with sizes (longer than legal windows starting
at the bottom of the screen, etc), that it behaves in odd ways is not
surprising. The fixes are in init.c, and vt100.h for completeness.
I'll post them if I get sufficient requests.

Meanwhile, I'd like to know why Dave does things that way. Is there a
reason that I can't see?

Finally, I've also got changes (again, to 2.1 - any posted versions
will be to 2.2) to allow a custom screen to be opened using the colors
from the workbench. Since it didn't appear that these got into 2.2,
I'll probably mail to Dave and any one else that asks.

	<mike

vanam@pttesac.UUCP (Marnix van Ammers) (10/18/86)

In article <148600164@uiucuxc> hamilton@uiucuxc.CSO.UIUC.EDU writes:
>> when I quit the program) but I swear, the night before it was working
>> just as I've said: DTR remained on.  I will post the details when I
>> figure it all out.
>
>    are you switching back and forth between terminal emulators?  or

Yep, that was it.  If I use MaxiComm first, then vt100 will work
such that it leaves DTR on when I click the go-away gadget.  I don't
understand why though.  MaxiComm turns DTR on when I start it and
off when I quit it, so I figure it must be doing things correctly.
I tried running MaxiComm twice in a row, but DTR would still turn
off whenever I quit.

If I use vt100 anytime after I've used MaxiComm, then DTR works
the way I like it.  Good grief.  What a kludgy way for me to
get DTR to stay on.

Marnix
-- 
Marnix A.  van\ Ammers
Home: (707) 644-9781		Work: (415) 545-8334
{ihnp4|ptsfa}!pttesac!vanam	CIS: 70027,70