Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!dwb
From: dwb@Apple.COM (David W. Berry)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Re: A plea for help (double-clicking disabled in Finder...)
Message-ID: <25305@apple.Apple.COM>
Date: 4 Feb 89 19:58:06 GMT
References: <379@lclark.UUCP> <2580011@hpausla.HP.COM>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 52

In article <2580011@hpausla.HP.COM> jcl@hpausla.HP.COM (Jeff Laing) writes:
>In article <379@lclark.UUCP>, dan@lclark.UUCP (Dan Revel) writes...
>> Chernicoff's program has several bugs in it, and this is a manifestation
>> of one of them.  I think he sets the event mask (filtering out mouseUp ?)
>
>One of the saddest realizations I had was that even Chernicoff's code had
>bugs in it; I found it out the easy way, by reading it in as I typed it (yes,
>I had to type from the book).  Its also amazing how much other source code
>I have seen floating around that has the same problem.  So, in the interest
>of letting someone else avoid a problem that 'nearly' got me.
>
>You really need to watch those handles being locked and unlocked a lot. The
>number of times I have seen ...
>
>a()
>{	
>	HLock(h);
>	b(h);
>	*h->x = ...	/* this would no survive a heap scramble */
>	HUnlock(h);
>}
>
>b(h)
>Handle h;
>{
>	HLock(h);
>	...
>	HUnlock(h);
>}

	Something that I don't believe is very explicitly spelled out
in Inside Mac, although it is mentioned several times is that you really
do want to restore the previous lock state.  Most times your code should
look like:

	short		state = HGetState(handle);

	HLock(handle);
	...
	HSetState(handle, state);

That way you get to make sure it's locked and at the same time don't destroy
anybody else's notion that it's locked.

	


Opinions:  MINE, ALL MINE! (greedy evil chuckle)

David W. Berry
apple!dwb@sun.com	dwb@apple.com	973-5168@408.MaBell