[comp.sys.apollo] screenlock, help me

nobody@prles2.UUCP (nobody) (01/20/89)

Hi,

I'm trying to write a screenlock for a Apollo DN3000 (1280bw screen).
I'm running bsd4.2 under SR9.7. 

I'm writing this in Pascal with some system calls of course and if the
software should do what the documentation says it had to do, everything
should have worked by now. The trouble is caused by the ^Q (control Q) key. 

The idea is as follows: with a graphics library the <.._$borrow> mode is put
on (the screen is totally black now). Then I ask for a password (maybe two 
times to eliminate type errors). After this you have to type the password
again and Presto! the screen re-appears. 

The process of password asking is done by a system call namely: <.._$input_
event_wait>. The GMR library profides a feature to inhibit asynchronious
events with the call <pfm_$inhibit>. Unfortunately, it's inhibits just
once, no matter if you do a call to <pfm_$inhibit> each time before you
invoke <gm_$input_event_wait> or not. 

Nearly the same story with the GPR library. Except that with the call
<gpr_$enable_input> the call <gpr_$event_wait> never returns when a
^Q more than once in a row is invoked! You can only retrieve a running
system by shutting it!

Several permutations I have tried with <pfm_$inhibit>, <gm_$input_event_
wait> and <gm_$input_disable>. I have also written a fault handler and
installed according to the manuals. No way it works! Redefining the keys
with <pad_$def_pfk> works fine for all keys except (of course) ^Q.

Also the possibility of declaring a window as big as the screen together
with disabling the mouse buttons does not work because the mouse cursor
can pick at the borders of the window. (The disabling of the key/buttons are
only valid in the window(s) the program is pointing to and evidently there
is no overlap in the borders.) 

I haven't got ideas anymore on this one, except that I have the strong
feeling that the display manager is pulling my leg.

So, any suggestions? If there are any useful hints that will result to a
working program, I shall post the source onto the net. This will probably
take some time because I would check it out thoroughly on several machines here. 
I consider a hint as 'Don't try any further, I too have spent xx days on that
one, without any result.' as a serious one ;-).

In case there is consensus of dropping the subject I'll summarize and post it,
so from then on, only the stiff headed would crack their brains on this (old
Dutch saying :-)).


                                              Albert Willemsen

The drinks were loaded, and so were the dolls.
                        Bonzo Dog Doodah Band. 

krowitz@RICHTER.MIT.EDU (David Krowitz) (01/23/89)

Look at the 'gone' program in the ADUS library. It does exactly what you
are trying to do (namely to lock the screen and require a password). I
believe it uses one of the old SMD (the monochrome graphics) calls to
inhibit the system's handling of the quit character.


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)