>>>>Hi,
>>>>
>>>>I have an EntityList with the following "fields" App_item, App_Type and App_Value.
>>>>
>>>>It contains things like:
>>>>
>>>>"PremiumReminderDays", "I", "10"
>>>>"LapseDays", "I", "5"
>>>>"CompanyName", "C", "Samaan Systems Ltd."
>>>>
>>>>I have an AppInfo object that I want to add properties to from this list so I end up with properties like this:
>>>>
>>>>AppInfo.PremiumReminderDays = 10
>>>>AppInfo.LapseDays = 10
>>>>AppInfo.CompanyName = "Samaan Systems Ltd."
>>>>
>>>>How do I do this in C#?
>>>
>>>A couple of ideas:
>>>(a) See the DynamicObject class (actually I think you need .net 4 for that)
>>>(b) Use an embedded dictionary. Something like:

public class LooseProperties
>>>    {
>>>        public Dictionary<string, object> Properties { get; set; }
>>>        public LooseProperties() { Properties = new Dictionary<string, object>(); }
>>>       // Add other standard properties 
>>>    }

then:

LooseProperties lp = new LooseProperties();
>>>//To store:
>>>lp.Properties.Add("PremiumReminderDays", 1);
>>>lp.Properties.Add("CompanyName","Samaan Systems Ltd");
>>>//To retrieve:
>>>string company = (string) lp.Properties["CompanyName"];

But, TBH, it introduces a lot of opportunities to cause exceptions at run time and, at least to me, smacks of bad design.....
>>
>>
>>Thanks Viv,
>>
>>I'm open to any advice on a better design. I don't understand why you think it introduces potential problems though, so could you explain that, please? The possible properties will all be defined by me so I will know what is there and what I can use.....
>
>You may know what properties are there but the compiler does not - so it's not going to catch any typos or attempts to cast (either implicitly or explicitly) a value to the wrong type. All those things that could have been caught by the compiler potentially seep into runtime code. If your lucky they will be quickly caught in testing - but you've still wasted time. If your unlucky they can still exist in production code.
>
>> I've just got into the habit of doing things like this in VFP so that I just need to add any new property to the table and it is magically available for me in the code. I suppose I could just make the properties defined ones on an object and just populate them from thetable when I need to. Is that a better design?
>
>Always better to define the properties explicitly unless there is a *very* good reason not to. Perhaps if you explained why you wanted to take this 'dynamic' approach rather than adding properties into the design we could suggest the best way of doing this.

Thanks Viv,

I've implemented the properties by defining them up front and agree that this is the safer way to do it. I think I just got into this habit from the dynamic abilities of VFP making it so easy to do it. I would add some code to my main program or application object that checked for the record in the table, if it didn't exist it would add it in with the default value, then it would add the properties to the global application object. I was just wanting to keep doing things the same way as that is the way I am used to do it so that when switching between VFP and .NET I didn't have to alter my way of thinking.