The general question here:
Is hardcoding data a good idea?
often comes up concerning how to populate Comboboxes/Listboxes and the same applies to your specific question/situation.
If the data will never, ever, ever change the possible values for txtFood...i.e. you'll never add another kind of fruit, never edit a given fruit's txtType, txtWeight or txtColor, and you'll never decide you need to add another descriptive component (say 'genetically modified' or 'non-genetically modified') then sure, hard code it.
But if there's any chance at all of having to do this, down the line, then take the Table approach as already suggested. Then if you have to do change, for example, apple's txtColor to green, you simple change it in the underlying Table, rather than having to go back into your code and change the hard-wiring.
Experience has told veteran developers that, unless the only possible values are never, ever going to change (i.e. the value for "Has employee previously worked here?" can only be 'Yes' or 'No') you shouldn't hard wire data.
Who knew, thirty years ago, that the question "Gender" could be answered with anything but 'male' or 'female?' Who knew, once more, thirty years ago that 'Type of telephone' could be 'Landline,' 'Cell', or 'Satellite' instead of simply 'Landline?'
When in doubt don't hard wire!
Linq ;0)>
The problem with making anything foolproof...is that fools are so darn ingenious!
All posts/responses based on Access 2003/2007