hehe...I understand.

I wasn't thinking about the right designer. Actually that is where I prefer setting the property for the class. It's an exposed property, and will apply to all created objects from that class. Perfect.

Chalk it up to too much time wearing my executive hat and not enough time in Visual Studio...

I posted a sample of how to do this at this post: http://forum.strataframe.net/Topic3766-6-1.aspx 

As for the designer to use I was just referring to the component designer ... you know, double-click on a BO from the solution explorer.  It will open up that blank gray screen on the left, but all of the properties for the class will appear within the property sheet.  I know you know what I am talking about at this point.  When you set a property within this designer it updates the InitializeComponent of that class.

But I think the subclasses BusinessLayer would be a better direction because you would only have to create a single class and all of your BOs would then follow suite after you change the declaration.

Which designer could I use to set that property? The designer for the instance of the class? I guess I could do that, but to me it's part of the class behavior. In other words, would I ever have an instance of this class where PKAutoInc would be set to True. The answer is no, by definition of this class. So while that would work, I then have to remember to set the property everywhere I use an instance of the class...

As far as changing the base type, obviously that would work too, but I need to consider that. I would just create a new derived class from BusinessLayer that has the three constructors calling the base constructors, set PKAutoInc to False there. And then change the base type for my BO to the newly-created type? Then anytime I wanted to have this behavior, I would just point to a new base type?

I could probably live with that, but then if I want another point-specific behavior, do I want to start creating new base types everywhere...not sure where that would take me from a pure design point of view, but like I said, I need to consider it.

Thanks!

Well, we take the same approach in many cases as well.  First of all, is there a reason you did not just use the designer and set the PrimaryKeyIsAutoincrementing property to false?  I guess I don't understand why you set this in the constructors.  Next, you can subclass a BO and set it one time and all of your future BOs will already have this property set to false.  If you'll notice, the inherits or declaration is in the main file and not the partial file.  This allows you to change this once and never have to worry about the rebuild of the partial class overwriting this declaration.

I guess my point is that there are a lot of ways to do this without touching the constructor...though you idea is a good one, I just see several other avenues for you to address this as we speak.

Whenever I write a class with multiple constructors, I like to also create a ConstructorCommon() method that is called from each overloaded constructor.

Obviously, this method is a good place for dropping code in common to each of the overloads.

So I'd like to see the generated SF Business Object classes (those inheriting from MicroFour.StrataFrame.Business.BusinessLayer, specifically) adopt a similar idiom.

This came up for me today as I had to set PrimaryKeyIsAutoIncremented to false on a BO. Not a big deal, but the right place to do it is in the BO constructor, which meant that I had to do it in all three constructors.

Which again three constructors is not overly-taxing to modify, but as the framework grows over time, it's reasonable to assume the BOs will evolve to having more constructors and not fewer, so the leverage of a ConstructorCommon() method would grow over time.

Thanks!