Re: [Pythoncard-users] List problem in 0.8

[Kevin A. <al...@se...>]

On Aug 25, 2004, at 9:20 AM, Alex Tweedly wrote:

>  Kevin, I must have read that paragraph a dozen times in trying to=20
> answer Adrian's question - and I just didn't "get it", and I'm not=20
> sure I do yet.
>
>  Could I suggest adding an additional paragraph that says (IF this is=20=

> correct)
>
>  So for example,
> =A0=A0=A0=A0=A0=A0 0.7 and earlier=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 0.8
>  =A0 list.getSelectionIndex()=A0=A0=A0=A0=A0=A0=A0=A0 list.selection
>  =A0 list.getSelection()=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
list.stringSelection
>  =A0 list.selection=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 list.selection
> etc. if more are needed to clarify it.
>
Well the old way was to use a selection or selected attribute and=20
sometimes one of those did dual-duty by checking the input arg on 'set'=20=

which allowed you to pass in a string or integer, but of course the=20
'get' version could only return one type. To make matters worse, not=20
all the components used the attribute names in the same way. This was=20
just one of those issues that existed from some of the earliest=20
versions of the prototype and I kept putting off making all the=20
components consistent. I would have to go back and look at every=20
component and compare them to the 0.8 components to document all the=20
variations and frankly I would rather fix bugs or add new=20
functionality.

I think the short story is that if you were using a method or attribute=20=

related to selection or selected then you should probably just be using=20=

selection or stringSelection now and you have to look at your source=20
and resource files to update them.

What I think I will do is turn the migration_guide.txt file into HTML=20
using the reStructuredText format and stick that on the main=20
documentation page so fewer people miss it.

ka