On 01/12/2005 10:23:20 AM, Don Allingham wrote:
> The *_column_order functions allow you to assign the column information
> on a database by database basis. However, the get_*_column_order should
> be smart enough to handle new columns without changing the database
> For example,
> def get_person_column_order(self):
> Returns the Person display common information stored in the
> database's metadata.
> default =3D [(1,1),(1,2),(1,3),(0,4),(1,5),(0,6),(0,7),(0,8)]
> if self.metadata =3D=3D None:
> return default
> cols =3D self.metadata.get('columns',default)
> if len(cols) !=3D len(default):
> return cols + default[len(cols):]
> return cols
> The "default" determines the available columns. When you add a new
> column, just add a new tuple to the list [ (0,9) ]. The first number of
> the column indicates if it is visible, the second is the interface
> column index controlled by the interface.
> If we get a value that is only 4 entries, but we expect 8, the routine
> will automagically add the remaining ones with their default values by
> picking of the trailing values from "default"
But Martin's patch was inserting columns, e.g. in between 3 and 4.
so the cols in the database were, e.g.
and we're making our new default to be
so that the new is now number 4, and the old 4 is now 5.
This would mess up the columns, wouldn't it?
On one of my machines, I got same name twice in the Column
editor, and I think it was because of this mixup.
Creating new database fixes it, but should we now change the code
to only append columns to the end?
Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html
Dept. of Neuroscience, Lions Research Building
2001 6th Street SE, Minneapolis, MN 55455
Tel (612) 625-7566 FAX (612) 626-9201