Hi Garrett --

>>
>>>I understand your point about not wanting to expose the interface. But I think at design time - you need flexibility.<<
>I personally abhor design-time, and consider it somewhat the mark of an amatuer
>to rely on setting properties at that point. That's just my opinion, but
>that's how I see it.

Interesting opinion: can you elaborate a bit?
<<

Well, there are a lot of aspects to this, so I'll just quickly touch on a few.

I write a lot of code that gets passed around. I also work a lot with code others wrote. In both these cases, it's infinitely easier to overlook design-time property settings than it would be were they coded. Coding the properties not only puts them in clear view, should someone need to debug. You also have complete control over the order in which they are set, again helping in the debugging phase.

In short, it makes team-work easier, and also serves to document your application better. As a columnist, there's the added benefit of just slapping the properties into a listing, rather than walking someone through all the settings they would otherwise need to make at design-time (back to that better documentation point).

Another thing we're seeing is a proliferation of incompatable controls (mainly from MS, but also from other sources). I'm not sure what happens in VFP if someone sends you a project that uses an incompatable (generally newer or beta) control? In VB, the project loads sans the control. The design-time property settings are gone. Bummer. If they were coded, you'd just drop in your own version of the control, and be off to the races.

I'll probably think of some more good rationale, but that's the view off the top of my head.

Later... Karl