I have a DLL called CommonBOs.DLL containing over 60 business objects.  One of the BOs in that DLL is called PropertyBO. 

In Visual Studio 2005 SP1, I have a VB2005 StrataFrame project with a form that contains an instance of PropertyBO.  Whenever I display the form in design mode the IDE crashes.

I rebuilt and cleaned the project multiple times with the problem continuing to occur.

I started another instance of Visual Studio and attach it to the instance that crashes and sent the debug code to the new instance.  I receive the following message.

I've rebuilt the business objects, recompiled the DLL and replaced the original DLL in the project.  If I remove the old and drop the new PropertyBO on the form it causes the same problem.  I can reproduce the problem by clicking on the PropertyBO1 instance in design mode.  If I drop other BOs from the DLL onto the form no crash occurs. 

So far I haven't noticed the IDE crashing unless I'm displaying the form in Design mode.

Any ideas on how to troubleshoot this further?

Thanks!

I have identified the cause of the issue.  I have a column called Locked(varchar(1), null) in the Property table that the PropertyBO is based on.  The steps I took to identify it were as follows:

1) Removed all references to the Locked property in the PropertyBO.vb and Property.designer.vb files.  Recompiled the CommonBOs.DLL file.  Replaced the reference to CommonBOs.DLL in my StrataFrame project with a reference to the new version.  Dropped an instance of PropertyBO on my form.  No IDE crash.

2) Added a column called Locked(varchar(1), null) to the Customers table in the StrataFrame sample database.  Used the Business Object Mapper to generate the updated partial class.  Created a new test project and added the new version of CustomersBO to the project.  Created a new StrataFrame maintenance form.  Dropped an instance of CustomersBO on the form.  The IDE crashes.  As before, I trapped the error in another instance of Visual Studio and verified that it was the same error as in my original post.

Any ideas why having a column called Locked is a problem?  I'm assuming that this is because Locked is a property in a different namespace used in my project.  Would there be any way to work around this short of renaming the column in the database or manually modifying the partial class?  Are there other column names that cannot be used in conjunction with StrataFrame Business Objects?

Thanks!

If you create a column with a different name does the error persist?  I think it will.  I don't think that the column name Locked is your problem.

The error message that you are getting indicates that it is trying to read from the table, which at design time, has no data within it.  If you have created a custom control or something that is firing a New() or constructor code in the designer then you will need to test on whether you are in design mode or not....otherwise this error will always appear.

The message just indicates that the Get is being fired and CurrentRowIndex and CurrentRow does not actually represent any data.  So you need to see where the Locked property is trying to be read and then you should be able to work backwards.

FYI....to test on design mode use the DesignMode property of the user control or form you are working on:

This has nothing to do with SF but rather .NET....and you can name a column pretty much anything you want...including reserved words or types in most cases, such as Type.  I could create a property named type and just make sure that in VB.NET it is surrounded with square brackets or preceeded with an @ symbol in C#.

I understand what you are saying but this is just a generated BO with no additional code being dropped on a brand new SF Maintenance Form that contains only SF generated code itself.  I'm not using any custom control other than SF controls and there is no custom code in the BO in order to perform a data read.  If I simply change the name of the column I created in verification Step 2 in my previous post, the IDE does not crash.  If I change it back, the IDE crashes.  In each case, the steps I go through are identical.

To give you some more detail, the steps I took to recreate this are exactly the same as in your tutorial with the only difference being that I added a column called Locked (when the IDE crashes) and LockedTst (when it doesn't crash) to the Customers table in the StrataFrame sample database before beginning Tutorial_Win_VB_2 (Adding a Business Object).  I am able to successfully complete this tutorial with no problems.  I skipped Tutorial_Win_VB_3 and resumed at the beginning of Tutorial_Win_VB_4 (Adding a Form) using the same project.  When I begin Tutorial_Win_VB_5 (Adding Controls & Binding Data) with the same project and get to Step 3, as soon as I drop the CustomersBO item on the CustomerMaintenance form, the IDE crashes.

This is why I based my assumption that the problem must be related to something in SF-- you should be able to reproduce it there as well.  Would you be willing to try adding a column called Locked to your Customers table and run through your tutorials as I did?

If you weren't able to reproduce it at your end I would be surprised. 

Thanks!

Can you supply a sample versus us going back and forth over the forum?  It would probably speed things up.  Thanks.

Yes, I have attached a zip file with the solution.  You'll see that it contains CustomersBO.  This is generated through the Business Object Mapper against the SF Sample Database Customers table with the additional column Locked as described in previous posts.  To reproduce the IDE crash, add a new SF Maintenance form.  After the form is added, drop the CustomersBO object on it.  If the IDE doesn't immediately crash, try clicking the CustomersBO1 that was added to the form.  The IDE should crash.  The way I found the reflection error that I posted earlier was by starting another instance of the VS IDE attaching to the VS IDE process containing the LockedTest solution.  If you click the Debug button when the VS IDE with LockedTest crashes, the IDE with the attached process will capture the exception detail.  Then you can hit Continue and the IDE that had LockedTest will finish crashing.  Thanks for looking at this and let me know if you have any questions.

Well, you learn something new every day   Locked is a reserved word used intrinsically within .NET.  The reason it fails is due to the compiler running in the background in VB.NET when the property is being reflected.  This is actually used as a design-time property to determine if the control has been "locked" from being changed, and thus the reason for the compiler dying.  So this is one instance when it may be better to use "LockedValue" or "IsLocked" as your property value.

Just FYI, had to typed it as a Boolean versus a String it probably would not have failed since it was expecting a Boolean data type.

In the designer of the BO you can change the field name to [Locked] and it will work just fine since the []'s separate it from the keyword in vb.

Actually, not in this case.  The brackets were already in place, and you are right that in most cases this will work, but not this one.  In this case, .NET is looking for the Locked property within the designer which is expected to be a Boolean.  His was typed as a String which caused the VS environment to crash.  Brackets made no difference in this case.

Duh. I forgot about actual properties of the control itself.





Just out of curiosity...why don't you allow us the ability to change the property name mapping? Seems to be a trivial thing to do...of course I know nothing about the designers and how you implement those.