Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!parc!lovstran
From: Lovstrand@EuroPARC.Xerox.COM (Lennart Lovstrand)
Newsgroups: comp.windows.open-look
Subject: Re: List Selection Bug
Message-ID: <1991Apr24.230649.16345@parc.xerox.com>
Date: 24 Apr 91 23:06:49 GMT
References: <1991Apr17.222421.19223@parc.xerox.com> <1991Apr19.165038.6774@uunet.uu.net>
Sender: news@parc.xerox.com
Organization: Xerox Palo Alto Research Center
Lines: 40
Originator: lovstran@roo

In article <1991Apr19.165038.6774@uunet.uu.net> karln@karln.UUCP () writes:
>In article <1991Apr17.222421.19223@parc.xerox.com> Lovstrand@EuroPARC.Xerox.COM (Lennart Lovstrand) writes:
>>Argh, I've just come across Yet Another XView Bug -- this time it's
>>the PANEL_LIST selection mechanism that is broken.  Try this:
>>[...]
>Greetings Lennart, 
>
>   I not *entirely* sure what your problem was, but I did get your code
>to work.
>
>   A few suggestions in general about programming ...
>   1: I personally *NEVER* put in malloc's without the properly executed free's
>     Certainly I never put mallocs in without frees at all.
>   2: I do not have a lot of experience with XV_KEY_DATA, but it *seems*
>      illogical to start putting key data into number 12345. I changed it to start
>      at 1. It makes more sense to start with the obvious, get it working, then
>      try to break it, if you have nothing better to do.

Bzzzt, wrong.  The malloc() is there for a particular purpose -- to waste some
space between the calls that create new instances of the panel list.  If you
remove it, you won't notice that the string pointers you're getting back come
from old, free()'d memory.

Besides, there is nothing magic about malloc()'s that aren't matched by a
corresponding free() -- it's called a memory leak, that's all.  It certainly
is bad coding practice, only barely excusable in demonstration examples and
programs with limited execution times.

XV_KEY_DATA is used to associate random 32 bit user data with XView objects
using 32 bit keys.  Again, there is nothing magic about either the key or the
data.  The key could be 12345 just as well as 54321 or the address "foo" or
whatever.

Except for destroying and recreating the list, the only other solution I've
heard of so far is to make the list non-exclusive and let the callback routine
deselect the last item itself (thanks to Jan Andersson at Ericsson for that
one).

Anyway, thanks for trying.
--Lennart