mwm@violet.berkeley.edu.UUCP (05/21/87)
I need to twiddle a window in ways that require closing and re-opening it. I'd like to keep as much of the context around as possible, and just close/re-open those things that really depend on the window. I'm happy with the way everything works except the console.device. It would appear that I can create the ports and IOStdReq structures once, and then do the OpenDevice every time I open the window. Closing the window then needs an AbortIO & CloseDevice. This works fine, except that I keep getting spurious messages which cause the last character I typed before the open/close to appear in the input stream. Not reasonable. Creating the ports & IOStdReq every time, and shutting them down to close the window, works like a charm. But I shouldn't have to do all that. Anyone know what I'm doing wrong here? Thanx, <mike -- How many times do you have to fall Mike Meyer While people stand there gawking? mwm@berkeley.edu How many times do you have to fall ucbvax!mwm Before you end up walking? mwm@ucbjade.BITNET
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/23/87)
[ First time 'inews' ever bit me. Fascinating. ]
In article <3665@jade.BERKELEY.EDU> mwm@violet.berkeley.edu(Mike (My watch has windows) Meyer) writes:
+
+ I need to twiddle a window in ways that require closing and re-opening
+ it. [ ... ]
+
+ It would appear that I can create the ports and IOStdReq structures once,
+ and then do the OpenDevice every time I open the window. [ ... ]
+ This works fine, except
+ that I keep getting spurious messages which cause the last character I
+ typed before the open/close to appear in the input stream. [ ... ]
+
+ Creating the ports & IOStdReq every time, and shutting them down to
+ close the window, works like a charm. But I shouldn't have to do all
+ that.
+
Have you tried zeroing out the IOStdReq before re-using it?
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\
\_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac
O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) (05/25/87)
In article <3665@jade.BERKELEY.EDU> I wrote asking for a way to close and reopen a window with a console driver attached without having to recreate the IOStdReq & Ports associated with it. Leo Schwab suggests: >> Have you tried zeroing out the IOStdReq before re-using it? Nice idea, but it doesn't work. I even went so far (finally) as to DeleteStdIO on the IOStdReq structs, and then CreateStdIO on them when the window was opened. It no work. The last character typed still shows up in the input buffer of the new window. Also, the system crashes after a couple of open/close cycles. Surely someone has done this kind of thing before. I'd sure like to know how. <mike
phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) (05/26/87)
in article <8705250859.AA07959@violet.berkeley.edu>, mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) says: > > In article <3665@jade.BERKELEY.EDU> I wrote asking for a way to > close and reopen a window with a console driver attached without > having to recreate the IOStdReq & Ports associated with it. > > Leo Schwab suggests: > >>> Have you tried zeroing out the IOStdReq before re-using it? > > Nice idea, but it doesn't work. [ ... ] > <mike Have you tried clearing the MsgPort list header? Or before re-attaching the message port do a "while( (ULONG) GetMsg(port) ) ;". -phil ============================================================================== Phillip Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making. /* eof */
carolyn@cbmvax.UUCP (05/27/87)
In article <8705250859.AA07959@violet.berkeley.edu> mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) writes: >In article <3665@jade.BERKELEY.EDU> I wrote asking for a way to >close and reopen a window with a console driver attached without >having to recreate the IOStdReq & Ports associated with it. > >Leo Schwab suggests: > >>> Have you tried zeroing out the IOStdReq before re-using it? > >Nice idea, but it doesn't work. I even went so far (finally) as to >DeleteStdIO on the IOStdReq structs, and then CreateStdIO on them when >the window was opened. > >It no work. The last character typed still shows up in the input >buffer of the new window. Also, the system crashes after a couple of >open/close cycles. Haven't done it myself but my guess is that your failure to Remove the initial request is causing the problems. I suggest trying the same code used for aborting and removing an asynchronous printer request: /* ior is your pointer to your console read IORequest */ if(!(CheckIO(ior)) { AbortIO(ior); } WaitIO(ior); /* Removes the request */ -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
rokicki@rocky.UUCP (05/28/87)
> the message port do a "while( (ULONG) GetMsg(port) ) ;".
If you are using Manx with 16-bit ints, and GetMsg has not been
declared to return any type, this will fail with a certain very
small probability---if the lower sixteen bits of the message
returned are zero. I would estimate this probability at
approximately 1/4096, but it will vary widely. So declare all
of those externals, folks! An easy solution is to always
include "functions.h".
-tom
mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) (06/02/87)
The continueing saga of the quest for the re-openable console window. In our last episode, Carolyn Scheppner had suggested: >> Haven't done it myself but my guess is that your failure to Remove the >> initial request is causing the problems. I suggest trying the same code >> used for aborting and removing an asynchronous printer request: This was done. In fact, the code tried was: Close a window (but leave console open): if (!CheckIO(consoleReadMsg)) AbortIO(consoleReadMsg); WaitIO(consoleReadMsg) ; CloseDevice(consoleWriteMsg); if (consoleReadMsg) DeleteStdIO(consoleReadMsg); if (consoleWriteMsg) DeleteStdIO(consoleWriteMsg); And to open a window: if ((consoleWriteMsg = CreateStdIO(consoleWritePort)) == NULL) cleanup(TRUE); if ((consoleReadMsg = CreateStdIO(consoleReadPort)) == NULL) cleanup(TRUE); if (OpenConsole(consoleWriteMsg,consoleReadMsg,EmW) != 0) cleanup(TRUE); consoleMsgBit = consoleReadPort->mp_SigBit; QueueRead(consoleReadMsg,&letter); This has the exact same problems mentioned before: the last character typed before the window open/close shows up in the input queue. The code to input characters is from the RKM, and is basically the same as in Rob Peck's book: if (wakeupmask & CONSOLE_MESSAGE) { /* keyboard */ GetMsg(consoleReadPort); qchar(letter); QueueRead(consoleReadMsg, &letter); charfound = TRUE; } where qchar puts the character in an internal queue. I think the problem is that some bogus message (other than input ready) is generated by the window StdIO open/close, and shows up on consoleReadPort. However, I can't find documentation as to what should be check on the Msg coming from the port. Anyone got any ideas? Thanx, <mike -- How many times do you have to fall Mike Meyer While people stand there gawking? mwm@berkeley.edu How many times do you have to fall ucbvax!mwm Before you end up walking? mwm@ucbjade.BITNET
ewhac@well.UUCP (06/04/87)
In article <8706012228.AA20376@violet.berkeley.edu> mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) writes: >The continueing saga of the quest for the re-openable console window. > >In our last episode, Carolyn Scheppner had suggested: > >>> Haven't done it myself but my guess is that your failure to Remove the >>> initial request is causing the problems. I suggest trying the same code >>> used for aborting and removing an asynchronous printer request: > >This was done. In fact, the code tried was: [ Code deleted ] > >This has the exact same problems mentioned before: the last character >typed before the window open/close shows up in the input queue. > >Anyone got any ideas? > Try this: AbortIO (ConsoleRead); WaitIO (ConsoleRead); Wait (1L << ConsoleRead -> io_Message -> mn_ReplyPort -> mp_SigBit); When I was writing Robotroff, there were occasions that I would need to AbortIO() a timer request so I could reconfigure things. I AbortIO()ed, then WaitIO()ed. I flushed it, right? Apparently not. I would keep getting this phantom signal that Wait() would respond to. I surmised that the AbortIO() posted a reply to your reply port, raising a signal bit. WaitIO() apparently then checks to see if the queue has anything. If so, it grabs it right away, and doesn't bother to clear the signal bit. So you still have an outstanding signal pending to your task... er.. process... er.. whatever. The above convoluted Wait() statement will clear it. I suspect that, when you post the new request, then wait for it, the old signal somehow gets in and fouls things up. If CATS would like the code that created this condition, I'm sure I could hack something together. Be warned, however, that I have a sneaking suspicion that the above hack has a very low probability of working for you.... Good luck. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jesup@steinmetz.UUCP (06/04/87)
In article <3213@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <8706012228.AA20376@violet.berkeley.edu> mwm@VIOLET.BERKELEY.EDU (Mike Meyer, My watch has windows) writes: >>This has the exact same problems mentioned before: the last character >>typed before the window open/close shows up in the input queue. >> > Try this: > > AbortIO (ConsoleRead); > WaitIO (ConsoleRead); > Wait (1L << ConsoleRead -> io_Message -> mn_ReplyPort -> mp_SigBit); ... > I suspect that, when you post the new request, then wait for it, the >old signal somehow gets in and fouls things up. > >Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ Maybe a better solution: AbortIO(ConsoleRead); WaitIO(ConsoleRead); Forbid(); if (ConsoleRead->io_Message->mn_ReplyPort->mp_MsgList.lh_Head->ln_Succ == 0) /* port has no messages in it */ SetSignal(MyTask, 1L << ConsoleRead->io_Message->mn_ReplyPort->mp_SigBit, 0L); /* WARNING: order of parameters is from memory! */ /* that cleared the signal if it was spurious */ Permit(); This assumes that signal has been generated before the WaitIO returns, as was suggested by Leo. In any case, this code should not harm anything. Randell Jesup jesup@ge-crd.arpa jesup@steinmetz.uucp (seismo!rochester!steinmetz!jesup)