At 08:05 PM 10/2/2007, Alan Colburn wrote: >If you were going to initially show your grid with 100 rows, I suppose >you could initially also make 100 objects for the collection, each with >blank attributes. As text was entered into grid cells, object attributes >would be changed. Somehow this seems inefficient ... I figured there are >better ways.
What I would do is NOT allow users to just enter data into rows in the grid. Having that functionality, while it may initially be more comfortable for users that are used to a spreadsheet, will only be confusing when those users reach the point that they realize your app is NOT a spreadsheet. If you avoid acting a little bit like a spreadsheet you also avoid the users asking for more and more spreadsheet-like features! I would instead provide a button and menu choice for them to request a new row be added. This gives you a discrete event to use to add a row to the grid. The focus would then jump to the grid and into the first column so they could then fill in that row. All very natural and users will understand it. (If they really want to enter things in batches they will quickly learn they can click the button 10 times and then go enter 10 rows of data. But that is their choice.) Of course you will also need to provide a way to delete rows if that is allowed in your application. The grid would initially be empty (or perhaps contain only one row that was ready to be filled in). The grid would then size itself to match the contents of the collection of data it was displaying whenever the Add or Delete actions were requested. _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
