It might be reflecting properly, but the Me.DesignMode will never work within the constructor (or any constructor for that matter, I think), because the value of the control/parent object is never set until after the control is created.  That's why I recommended moving the code to the OnCreateControl() method because it's the first thing that get called after the constructor/InitializeComponent().  We figured this one out the hard way... several days of trying to determine whether we were at design-time because we thought the DesignMode property was broken.

But, if none of your calls are in the constructor/InitializeComponent(), then it very well could be that nesting user controls confuses the DesignMode property.  I haven't actually tried this.

And don't worry about nesting UserControls... it's actually good practice   Any time you can re-use code is a good thing (without copying it ).

Okay, I spent the majority of the day troubleshooting this problem and believe I have found the source. 

I have a form that contains a UserControl. This UserControl has a few different sections which are also UserControls and those UserControls also contain another user control. (I only did this because this particular display is used on various forms).   It appears that if you go deeper that two user controls the me.DesignMode is no longer recognized. When I commented out this code the form loaded properly. 

Are there any files in the GAC, on disk, etc. that may be getting loaded rahter than was is reflected in your source code?  I have seen that happen as well which can wreak havoc on your patience  Also, if your assembly gets loaded in the GAC, you must get out of Visual Studio and come back AFTER you build before the new changes take effect.

Thanks Ben.  Is there anyway to determine the line of code this is happening or perhaps doing a trace. It's very strange because I took a backup before I started making changes and the backup copy displays fine, and when I undo pending changes and compare the two programs they are identical... very strange.

The business objects won't try to access the database by themselves.  Most likely, there is a call to a fill method somewhere in a form constructor (or another place that gets called at design-time, like OnCreateComponent).  If you try to fill a business object at design-time, it will try to create its DataLayer, which will try to access the data source.  So, on the form in question, check the constructors of the form and any user controls/custom controls that are used on the form as all of these constructors will be called by the designer.  If you have a Fill call in one of them, then you'll have to pull that call out and instead, override OnCreateControl and put it at the top of that method (before the MyBase.OnCreateComponent() call), but wrap your Fill in a test for design-time like:

If Not Me.DesignMode Then
    myBo.FillWhatever()
End If

This will keep it from trying to access the database at design-time.

As for the SharedDataTableProblem, I believe there is an outstanding issue on the SharedDataTables at design-time (we might have forgotten a test on Me.DesignMode ourselves).  If this is the case, it will be fixed soon.

I have had my SF application running for a while  now and I've had no problem in the past opening up a form in Visual Studio, but for some reason today I have been getting a lot of weird problems, such as the above error, on a form which I have opened and closed without problems earlier today. Nothing has changed in the Business Object side, I am just changing the UI. "NET" is my datasource key for one of my databases.

I have also had problems with my forms that use a SharedDataTableKey.  All of a sudden I can't open these forms because the sharedDataTableKey is not defined.

Any idea's why this is happening and how to resolve?  I have tried cleaning and rebuilding my solution but it didn't help.

Thanks,

Tim