>>Rather than having this as a single grid, split it into two grids - one grid used to select the garment; one garment to a row, and then a seond grid that displays a row per 'size' - that way you can have a standard form that conforms to your display, and doesn't get affected if suddenly a garment becomes avaiable is 17 sizes, rather than the current maximum of 10. I'd normalize the underlying table structure as well; rather than a 'garment' table with a number of columns per size, slit it to two tables - a garments table, which has a unique PKey/garment, and a child table of garment sizes, with a foreign key identifying the garment record it belongs to, and a column identifying the size. This has the added benefit that the 'columns' don't have to have fixed names, either; your size field can contain Small, Medium, Large, XL, or a range of numbers, or arbitrary codes like shoe widths or cup sizes or whatever.
>
>Thanks! Looks good!
>I would like to try a 2nd grid, how do you recommend I co-ordinate them?

It's a basic parent-child relation; changing the currently-selected parent means updating the child records...

I'd use a p-view to load up the second grid with the sizes applicable to the currently-selected garment, with the parameter being the garment PKey. Create a custom promperty of the Form to hold the currently-selected garment PKey. In the first Grid's Init, and in the first Grid's AfterRowColumnChange event, if the row has moved, the Pkey will not match the custom property, so a new garment is being displayed; when you detect the change, write the new Pkey into the custom property, update the parameter value for the p-view driving the second grid, requery, and refresh - the second grid now shows the records for the currently selected garment. To simplify things, I'd create a method for handling the grunge work of updating the child grid, and call it as needed. Makes its own sauce.