🚀 go-pugleaf

In article <20606@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>>I am writing an application where I have a list of strings which I want
>>to display and then have the user select one.
>
>I do this by making an enabled userItem in my dialog. I use the list
>manager.  (Luckily for you, the default itemDrawProcedure in the list
>manager shows strings. (I never use it myself, because I prefer an
>SFGetFile style ... for long entries.))  I connect the update
>procedure for the useritem to the listManager's update call, and since
>the item is enabled, if the user clicks on it, I can detect that and
>fall through into LClick.

Um, this doesn't work, does it?  At least it didn't when I tried it.  LClick
tracks the mouse until mouse up, but so does the Dialog Manager when
resolving a mouse click.  That means that after ModalDialog returns an
indication that the mouse was down in the list user item, it's already too
late for LClick, the mouse is up.

What I had to do was put the call to LClick in my filter procedure.  That
works fine.

This is of more than theoretical interest to me.  I currently have a 'cdev'
(Control Panel file) into which I would really like to put a list.
Unfortunately, the Control Panel does not hand you mouse events in time to
pass them to LClick.  Most other events do get passed to the cdev code
resource, so this is fairly annoying.  Does anyone have a solution, short of
silliness like trap patching?
-- 
Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)