Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Finding The Workbench Screen
Message-ID: <3207@amiga.UUCP>
Date: 19 Dec 88 23:51:27 GMT
References: <1982@van-bc.UUCP> <7796@well.UUCP> <13231@ncoast.UUCP> <7907@well.UUCP> <5034@garfield.MUN.EDU> <5508@cbmvax.UUCP>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 62

--

I thought it was pretty well explained what LockIBase() is and is not for.

It is for protecting your walking down the linked lists in the PUBLIC part
of IntuitionBase.

Hostile functions, such as calling ActivateWindow on a window which is not
your own (and which you cannot assure is going to stay open) is NOT part of
the job of LockIBase().

It turns out that ActivateWindow() is safe: if the window disappears, the
system will not crash.  But clearly, we have to make stronger position statements
on what "hostile" Intuition activity is proper (such as sizing somebody else's
window).  We'll address this as we can in V1.4.  The general theme will be
that we will try to make all functions you might want to "impose" on somebody's
window as safe as possible.  We'll provide easier ways to do the trickier
functions, like popping a window to full size.  Interim hacks, such as my
own IHelp, are iffy at best, and can be replaced after V1.4 with solid, supportable
programs.  The keyword here is "supportable."

Many of the things one might do while hacking Intuition stuff is NOT safe
under Forbid, because it can be deferred, and because it can block: either for
the Blitter or for lower level internal semaphores.

Let me make it very clear:  Only Intuition has any business performing
critical operations on Intuition data structures: LockIBase() is provided for
you to EXAMINE a select few linked lists which Intuition might want to
modify, if there were no arbitration.  (It turns out that the only public list
is the screen chain, based on FirstScreen).

Make ZERO Intuition function calls while LockIBase() is in effect.

The FD file is not the documentation.  The documentation is in the AutoDocs
and the Enhancer manual.  You pass LockIBase() a zero, and you pass UnlockIBase
whatever LockIBase() returned.

GetScreenData() is also well-documented as being a copy of the workbench screen,
and the caveat is that pointers found therein cannot be assumed to be valid
(since the workbench screen may close at any time).  In V1.4, this will
be made obsolete by a more general function to actually get a lock on a
screen itself, insuring that it is not closed, and you would then be allowed to
look indirect at data pointed to by the screen structure.

Don't give bad advice, folks, please.

I fully sympathize with the call for better examples of difficult functions
in the future.  We'll try to accomodate.  In the meantime, read the documents
we have out there.  Don't assume that Intution is a wonderful asynchronous
toolkit which you can run around in and munge.

	jimm

PS: And in case you haven't heard, programs using the private part of IntuitionBase
will neither compile nor work under V1.4.  Sympathy in this area will be very
hard to get out from me.

-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.