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