[comp.lang.smalltalk] ScheduledWindows in r4

dik@comp.lancs.ac.uk (Mr R. M. Bentley) (06/18/91)

I'm writing some code that requires Windows to be opened without
terminating the active process. ScheduledWindow provides a method
for this purpose - openIn:terminateActive:  I then go on to open
some more windows at points dependent on the position of the Window.
I'm getting problems in that sometimes the inputOrigin of the 
Window is not initialised properly, so Window returns the incorrect
origin in response to the message globalOrigin.

An example may help - 

  aWindow openIn: aRectangle terminateActive: false.
  Transcript show: aWindow globalOrigin printString.

Window changeCreationOrigin: aPoint is invoked twice during Window
initialisation. I sometimes pick up the value before the second 
invocation has set the correct globalOrigin. This should not be the
case if the activeProcess - the one running the code - is blocked
until the Process opening the Window has terminated (which I assumed
it was). I've tried forking the process that opens the Window at a
higher priority - (Processor activePriority + 1) - which has no  
effect.

Any comments welcome !

Richard Bentley

+------------------------------------+----------------------------+
| uucp :  ...!mcsun!ukc!dcl-cs!dik   |   Department of Computing  |
| arpa :  dik%lancs.comp@ucl.cs      |   University of Lancaster  |
| janet:  dik@uk.ac.lancs.comp       |   Bailrigg, Lancaster      |
| tel  :  (44) 524 65201 x3119       |   LA1 4YR,   UK.           |
+------------------------------------+----------------------------+

hubert@cs.uni-sb.de (Hubert Baumeister) (06/19/91)

In article <1374@dcl-vitus.comp.lancs.ac.uk>, dik@comp.lancs.ac.uk (Mr R. M. Bentley) writes:
|> I'm writing some code that requires Windows to be opened without
|> terminating the active process. ScheduledWindow provides a method
|> for this purpose - openIn:terminateActive:  I then go on to open
|> some more windows at points dependent on the position of the Window.
|> I'm getting problems in that sometimes the inputOrigin of the 
|> Window is not initialised properly, so Window returns the incorrect
|> origin in response to the message globalOrigin.
|> 
|> An example may help - 
|> 
|>   aWindow openIn: aRectangle terminateActive: false.
|>   Transcript show: aWindow globalOrigin printString.
|> 
|> Window changeCreationOrigin: aPoint is invoked twice during Window
|> initialisation. I sometimes pick up the value before the second 
|> invocation has set the correct globalOrigin. This should not be the
|> case if the activeProcess - the one running the code - is blocked
|> until the Process opening the Window has terminated (which I assumed
|> it was). I've tried forking the process that opens the Window at a
|> higher priority - (Processor activePriority + 1) - which has no  
|> effect.
|> 

The second changeCreationOrigin: message is the result of an event generated
by the window manager from outside Smalltalk. There is a process in InputState
the processes the events from outside (created in InputState class>install and consists out of InputState>run). This process runs with LowIOPriority
which is higher than UserSchedulingPriority and thus can interrupt 
your process when an event is received. So you have to wait 'long enough'
to get the right result.

Hubert

-- 
					Hubert Baumeister
					Max-Planck-Institut f"ur Informatik
					Im Stadtwald
					6600 Saarbr"ucken

					Telefon: (x49-681)302-5432
					e-mail: hubert@cs.uni-sb.de