Path: utzoo!mnetor!uunet!husc6!bbn!rochester!ur-tut!dpvc
From: dpvc@ur-tut (Davide P. Cervone)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IDCMP ports
Message-ID: <1942@ur-tut.UUCP>
Date: 2 May 88 17:27:42 GMT
References: <2336@mit-amt.MEDIA.MIT.EDU> <353@ardent.UUCP> <4540@batcomputer.tn.cornell.edu>
Reply-To: dpvc@tut.cc.rochester.edu.UUCP (Davide P. Cervone)
Distribution: na
Organization: Univ. of Rochester Computing Center
Lines: 36
Keywords: screens windows

In article <4540@batcomputer.tn.cornell.edu> hsgj@tcgould.tn.cornell.edu (Dan Green) writes:
>An additional point is that you can use a 1x1 pixel window, but make
>sure you set the flag (forget the name) that notifies you when you
>are no longer  the active window.  I think its (INACTIVE_WINDOW) or
>something like that.  Anyways, when you get that message, it means the
>user clicked on the screen.  With the message is the mouse X,Y, in case
>you need that info.  So then you do an Activate() call to make your
>window active again so you can get more IDCMP input.

NO, PLEASE DON'T DO THIS!  This will make it IMPOSSIBLE to select any window
on any other screen!  When you select, say the CLI window, then your program
will get a window-inactive message, and will reactivate your winodw.  The CLI 
will become inactive again, even though the CLI window is on another screen.

The borderless, backdrop approach is the right way to do this.  Let the USER
decide when to activate windows.

>Please note that everyone will chastize you if you do this sort of
>behavior on a screen where windows from other programs exist!  

We'll chastize you wherever you do this!

>Thus
>you can only do this on your own custom screen, which I gather was
>the original intent.

Wrong!  See above.  You should not use this approach even on a custom screen.

>-- Dan Green
>ARPA:  hsgj@tcgould.tn.cornell.edu
>UUCP:  ihnp4!cornell!batcomputer!hsgj   BITNET:  hsgj@cornella

Davide P. Cervone
dpvc@tut.cc.rochester.edu
dpvc@ur-tut.UUCP
DPVC@UORDBV.BITNET