acs@amdahl.uts.amdahl.com (Tony Sumrall) (03/04/88)
Case A: I have a requester up in a window. The requester does NOT have NOISYREQ set. When I click on the window close gadget I hang. Case B: I have a requester up in a window. The requester DOES have NOISYREQ set. When I clock on the window close gadget I get a WINDOWACTIVE message. Does this seem strange to anyone besides me? Is this a bug? This was discovered upon investigation into a bug reported in VT100 2.8. As iut turns out, VT100 2.8 is case A. Clicking the window close gadget of the VT100 Info/Xfer Status window while a requester is displayed will cause the VT100 task to hang. It will be fixed via patch within the next few weeks. -- Tony Sumrall acs@amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/05/88)
In article <23669@amdahl.uts.amdahl.com> (Tony Sumrall) writes: >Case A: I have a requester up in a window. The requester does NOT have >NOISYREQ set. When I click on the window close gadget I hang. > >Case B: I have a requester up in a window. The requester DOES have >NOISYREQ set. When I clock on the window close gadget I get a WINDOWACTIVE >message. > >Does this seem strange to anyone besides me? Is this a bug? I have noticed this behaviour as well, and just wrote it off as 'normal' Basically, there are a few message classes that will get through to your requester and when you think about it, it is useful that they do. One of them is of course, CLOSEWINDOW since it is entirely possible to put up a requester in a very small window that gets clipped into nothing at all. Like so : Window +-+-------+ |+|=======| +-+-------+ | | | | +----------------+ +---------+ | | | Requester | +----------------+ Now because the requester is rendered completely outside the boundarys of the window it is clipped to zilch. And there is no way to hit it's ENDGADGET. So what to do? Well, since you will see a CLOSEWINDOW message you can escape by doing an EndRequest and exiting. Note I also see ActiveWindow messages as well. What this points out is something that makes for better C programming and that is, when you are switching on a value (such as a Message class) it is preferable to use a switch() statement with a default: clause. Rather than a bunch of if-else constructs. That would save you from this sort of problem. Generally I have a standard "handle intuimessages" loop that I copy around. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
acs@amdahl.uts.amdahl.com (Tony Sumrall) (03/16/88)
In article <23669@amdahl.uts.amdahl.com> I wrote about an anomaly in the
results obtained with NOISYREQ set. It turns out that I was wrong in my
assessment of the situation. VT100 does not hang when you click on the
WINDOWCLOSE gadget of the Xfer/Status window...it is waiting for the
requester to be satisfied. Apparently a CLOSEWINDOW msg will not be sent
when the user presses the WINDOWCLOSE gadget of the window while there is
a requester up in the window. This I found by observation (using SDB as
well as MonIDCMP) regardless of the state of NOISYREQ. Again I ask, does
this seem strange to anyone besides me? Is this a bug? Have I missed
some other means of providing this function? Seems that I, as a
programmer, should not have to resort to FOLLOWMOUSE while a requester is
up in order to provide a well-behaved interface to the user (i.e. allow
the user to do the equivalent of pressing a DONE gadget by attempting to
close the window).
--
Tony Sumrall acs@amdahl.uts.amdahl.com <=> amdahl!acs
[ Opinions expressed herein are the author's and should not be construed
to reflect the views of Amdahl Corp. ]cg@myrias.UUCP (Chris Gray) (03/17/88)
Tony Sumrall (acs@amdahl.uts.amdahl.com) suggests that he wants to be able
to see a window-close event when a requester in that window is active.
I so NO to this!! One of the points behind requesters is that they must be
handled before any other events for the window are. I've written a couple
of library routines (e.g. a palette editor) that can simply be passed a
pointer to the window, and will do their thing without any other knowledge
of what the window is doing. (I properly save and restore the IDCMP flags.)
When I use them, the other gadgets in the window do not even respond to
mouse actions, and this is precisely what I want - they are not currently
accessible, and not responding at all shows this to the user. If you want
out-of-band signals when you are asking for a file name, then use a second
window and merge the IDCMP streams from all of the ones you are using - don't
change the way requesters work!
--
Chris Gray Myrias Research, Edmonton +1 403 428 1616
{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cgacs@amdahl.uts.amdahl.com (Tony Sumrall) (03/18/88)
In article <571@myrias.UUCP> cg@myriasa.UUCP (Chris Gray) writes: >Tony Sumrall (acs@amdahl.uts.amdahl.com) suggests that he wants to be able >to see a window-close event when a requester in that window is active. >I so NO to this!! One of the points behind requesters is that they must be >handled before any other events for the window are. This conflicts with the definition of NOISYREQ, doesn't it? I can get key press events from the window while the requester is up...I can even get window active messages...why can't I get a CLOSEWINDOW? -- Tony Sumrall acs@amdahl.uts.amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
john13@garfield.UUCP (John Russell) (03/19/88)
For me as a user of umpteen VT100 versions, changing from a requester to a requester inside a second window (the xfer window) has both good and bad points. GOOD - you don't lose the ability to type into the main window while the requester hangs around on the screen. Also you can move and resize the window if you like. BAD - it is $%#@$% irritating to have a large part of the screen obscured every time I want to do some sort of file operation; especially doing something like turning off capture, and having to click a close-gadget of a window that tells me capture has ended. I move the window around, resize it, move it to the back, but it always seems like it gets in the way the next time I change directories, or has to be made bigger to monitor a kermit. Again on the bad side, you can make it 'hang' by performing a normal action - clicking a close box - if you do it at the wrong time (for me this was 10 seconds after the first time I booted it). I'd like to see the interface modified a bit. There should be some way to say "make the window go away as soon as possible" so it would maybe display messages for a few seconds then scat. Perhaps a "set window position and size" option in the config file. And it shouldn't have a close box at times when the close box is dangerous -- maybe during file transfers it could be made borderless so as not to get in the way? John PS There are problems with the "done" gadget in the requester as well at certain times.
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (03/21/88)
In article <4599@garfield.UUCP>, john13@garfield.UUCP (John Russell) writes: > BAD - it is $%#@$% irritating to have a large part of the screen obscured > every time I want to do some sort of file operation; especially doing > something like turning off capture, and having to click a close-gadget of > a window that tells me capture has ended. [ Cross-posted to .tech for a reason. See below. ] This will happen if you've *closed* the Status/Xfer window, but NOT if you just push it to the back after having responded to the requester when you initiated the Capture function. This is true for all infomational messages written to the Status/Xfer window. As long as it's open (but in back of the main window), it should stay there until you do something that causes a requester to pop up for input. One exception: when you specify an initial script on the command line when first invoking vt100 (e.g., "run vt100 callwork") the Status/Xfer window gets opened and is WindowToFront()'d. I'd like to see it left in the back myself. If this is not the case for you, please email details of your setup (screen type, etc.) Your vt100.init script could prove useful. > I move the window around, resize > it, move it to the back, but it always seems like it gets in the way the > next time I change directories, or has to be made bigger to monitor a kermit. His name is "Murphy". :-) > Again on the bad side, you can make it 'hang' by performing a normal action - > clicking a close box - if you do it at the wrong time (for me this was 10 > seconds after the first time I booted it). Tony's looking at this, I think. > I'd like to see the interface modified a bit. There should be some way to > say "make the window go away as soon as possible" so it would maybe display > messages for a few seconds then scat. Good suggestion. Maybe a toggle in the Utilities menu that would optionally cause a WindowToBack() on the Status/Xfer window? Having it happen immediately after the requester is responded to shouldn't require much code. For *now*, try using one of the PD programs that brings a window to the front with a couple of mouse clicks (ClickToFront, ClickUpFront, others). Chances are, your mouse pointer won't be in the Status/Xfer window area, so you won't even have to move her ... just reach over, and click-click. > Perhaps a "set window position and size" > option in the config file. I've talked with Tony before about specifing the size and position of the Status/Xfer window in the vt100.init file. It'd be a fair amount of code to do all the parsing and error checking of the input parms, and of limited value because, as you mention, you'll probably move it around and resize it anyway. I'd rather see the code used to support additional protocols, etc. Wouldn't you? And you *do* have the sources, so you can always tailor the window's initial position ... > And it shouldn't have a close box at times when > the close box is dangerous -- maybe during file transfers it could be made > borderless so as not to get in the way? Maybe just get rid of the close altogether, and rely on front/back gadgets to get it out of the way? I would also like to see the close gadget removed from the main vt100 screen, and it be made into a menu item. Only. More times than I'd like to admit I've been doing something on another screen, flipped over to vt100, and hit the L-Mouse-Button (well, really I use L-Alt-Amiga) to select it's screen. Naturally, the mouse pointer was right on top of the close gadget area. You know the rest. This has usually happened within 10% of finishing a looooong file xfer. Murphy, remember. > PS There are problems with the "done" gadget in the requester as well at > certain times. Being looked into. Now, here's one I'd like some info on (and why I've cross-posted this to .tech): Ever notice while resizing a window or moving it around that an in-progress file xfer *stops* until you release the L-Mouse-Button? Well, it does [see, led's on modems *are* good for something]. This is not restricted to vt100's window(s) either, but applies to any window in the system. This can cause havoc if you're trying to talk to a system that doesn't relax their timeout specs between packets. I forget why Tony said this happens (something to do with Layers, if my memory serves me right), but does anyone know of a solution. Seems a shame if there isn't one, as this *is* a multitasking machine, and moving windows about has NOTHING to do with the serial port, per se. Anyone? Finally, I should mention that Tony is still accepting suggestions for what goes into v2.9 or v2.10 (or will that one be v3.0 ?). His email address is the same as mine ... just substitute "acs" in place of "kim", or you can send them to me. A couple of things I've asked for is support for multiple active "on" and "wait" script commands, and for the ability to set/change the function key definitions "on the fly", rather than just from a script. Tony's looking at these, but they may not make v2.9. Keep those cards and letters coming in ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
snyderw@pawl23.pawl.rpi.edu (Wilson P. Snyder II) (03/21/88)
I would like to know if there is a easy way of terminating the protocal receiving/transmission in the middle of a file. On a slightly related issue, how can you set the packet size larger? I have set the packet size larger on the machine I am transmitting to, but then VT100 seems to ignore it and send 96 character blocks. ______________________________________________________________________ Wilson P. Snyder II beowulf!lunge!snyderw@steinmez.UUCP 318 Crockett Hall, RPI (uunet!steinmez!bewulf!lunge!snyderw) Troy, NY 12180-3590 518-276-2764, 802-658-3799 in summer ______________________________________________________________________
acs@amdahl.uts.amdahl.com (Tony Sumrall) (03/22/88)
In article <564@imagine.PAWL.RPI.EDU> snyderw@pawl23.pawl.rpi.edu (Wilson P. Snyder II) writes: >I would like to know if there is a easy way of terminating the protocal >receiving/transmission in the middle of a file. The docs say to press ESC from the main VT100 window. You may have to do it several times. This only holds for KERMIT and the 2 XMODEM protocols. >On a slightly related issue, how can you set the packet size larger? >I have set the packet size larger on the machine I am transmitting to, >but then VT100 seems to ignore it and send 96 character blocks. You need to say "KMAXPACK xxx" (omit the quotes) in your vt100.init or a script file. I believe the default is 1000 or thereabouts so if it ain't working for you check your HOST comm pgm (I use it all the time on this UTS machine with no problem). It can get kind of tricky if you use C-Kermit cause it has both a send and receive packet size. If you set the send packet size to > 94 it will send large packets but tell the other kermit to send "normal" packets. The maximum that VT100 will do is around 1000 bytes. >______________________________________________________________________ >Wilson P. Snyder II beowulf!lunge!snyderw@steinmez.UUCP >318 Crockett Hall, RPI (uunet!steinmez!bewulf!lunge!snyderw) >Troy, NY 12180-3590 518-276-2764, 802-658-3799 in summer >______________________________________________________________________ -- Tony Sumrall acs@amdahl.uts.amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (03/22/88)
In article <25198@amdahl.uts.amdahl.com>, acs@amdahl.uts.amdahl.com (Tony Sumrall) writes: > In article <564@imagine.PAWL.RPI.EDU> snyderw@pawl23.pawl.rpi.edu (Wilson P. Snyder II) writes: > >On a slightly related issue, how can you set the packet size larger? > >I have set the packet size larger on the machine I am transmitting to, > >but then VT100 seems to ignore it and send 96 character blocks. > > You need to say "KMAXPACK xxx" (omit the quotes) in your vt100.init or > a script file. I believe the default is 1000 or thereabouts . . . Also, be aware that you may need to increase the "timeout" parameters on your host's kermit, or you may confuse the poor thing into having a seizure (can't describe what happens any better than that, in less than 1000 words). I use the commands: set receive timeout 15 set send timeout 15 in my .kermrc file on the host. Works on our UTS system, but your milage may vary. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
dpvc@ur-tut (Davide P. Cervone) (03/25/88)
In article <25089@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: >Ever notice while resizing a window or moving it around that an in-progress >file xfer *stops* until you release the L-Mouse-Button? Well, it does [see, >led's on modems *are* good for something]. > >This is not restricted to vt100's window(s) either, but applies to any window >in the system. This can cause havoc if you're trying to talk to a system that >doesn't relax their timeout specs between packets. This has to do with layers. When you size or move a window, Intuition locks the screen's layers so that rendering does not occur to the window or screen while you are moving the window around. In general, this is a good thing, but it also means that any I/O to a window on that screen will block until you let go of the window. I assume that VT100 is updating a status window (telling you how many packets are transfered). This update is being blocked, so VT100 does not go on to receiving the next packet until the output occurs. That's the holdup. There's very little that can be done about it, unfortunately. Holding down the MENU button also locks the layers. >/kim >UUCP: kim@amdahl.amdahl.com Davide P. Cervone dpvc@tut.cc.rochester.EDU
john13@garfield.UUCP (John Russell) (03/27/88)
In article <1504@ur-tut.UUCP> dpvc@tut.cc.rochester.edu.UUCP (Davide P. Cervone) writes: >That's the holdup. There's very little that can be done about it, >unfortunately. > >Holding down the MENU button also locks the layers. As I said a little while ago, adding " | RMBTRAP" to the source code of a program which *doesn't* use menus can avoid this. Much like adding " | NOCAREREFRESH" avoids another behaviour you might not notice, but which may be bothersome in some situations. I've found at least one program that has a bug because of this where it may fail to recognize SELECTUPs if you have the RMB pressed. I'll test any others I can find and see if it's widespread; I can remember though having other programs exhibit the same behaviour, it may be for this reason or a button release during a forbid. John PS The author of the article I'm replying to wrote "ClickUpFront" a similar but different program from Bryce's "ClickToFront". Davide, any chance of having Heliosmouse, WKeys, and CUF bundled into one to save space on the WB and loading time in the startup-sequence?