[comp.sys.amiga] How much of the console.device do I need to close?

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)