If all the cards have the same structure, you can group all the objects and turn on the group's backgroundBehavior. This way all the objects are created automatically on any new card. You can also put your scripts in the group or it's objects, so that they really only exist in one place.
The cards method is much the easiest to learn and implement but with 3000 cards, it may turn out too slow. The next best option is probably to have a data storage section and a display section. Suppose you are storing names & addresses. Instead of having one per card, you could enter them, then amalgamate all the data fields into a single line separated by tabs or some unusual character. When you need to display that data again, get the line, set the item delimiter to whatever character you chose and place each item in the appropriate field. This method allows very fast searching using the filter command or lineOffset. Also, if you build the application, the display stack can be the mainStack (so not writable) but your data can be in a separate subStack and able to be saved. Cheers, Sarah On Monday, October 14, 2002, at 08:56 am, Mike Doub wrote: > I am planning the design of an address book like application. I have > been > studying the Employee database tutorial and have noticed that the > scripts > are duplicated on each card. I am planning to support about 3000 > entries. > That would seem to be pretty wasteful. > > Can anyone comment of their experience with lots of cards? I am > concerned > with both memory and performance. I have no experience with using a > databases so I was trying not to lean in that direction. > > --Thanks > Mike > > > > _______________________________________________ > use-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
