That is stored on a per machine basis as part of the solution.  This is just .NET.

Error encountered:
A project with an Output Type of Class Library cannot be started directly.
In order to debug this project, add an executable project to this solution which references the library project.  Set the executable project as the startup project.

Solution: 
For some reason StrataFlix.Base was set as the startup project.  I changed it to StrataFlix (first project in the list) and everything worked after that.

Now, I will start digging into the custom BBS examples.

It does.  I have downloaded the sample app and the newest posting of the framework.  I have 1.6.6, but it is not the most recent beta version.  As soon as I can get these things installed and built, I will review the sample app.  Hopefully, this will provide what I am looking for.

Thanks!
Bill

You will want to take Dustin's advice on this one.  This will give you what you are trying to accomplish.

Ok, what about using custum business binding sources to expose the children BOs themselves as properties on the parent BO? This is the same way we do reporting, and there is an example of how to set this up within the new StrataFlix sample that Trent just posted: http://forum.strataframe.net/Topic18186-17-1.aspx

Take a look at the Movie Profile Report under the StrataFlix.Reporting project.  The Movies BO has Images, Cast, and Items as children all declared as public properties. Notice that you are talking to the business binding source for each child BO rather than the BO itself. You aren't pulling in the individual fields into the parent BO (i.e. the solution I suggested earlier), but are instead exposing the children BOs themselves.

For a grandchild record, you would just go one level deeper and expose the grandchild BBS as a public property on the child BO.

Does that sound more like what you are looking for?

Bill,



OK, so the BBS needs to have a strong typed property to work...didn't know that.



However, you might want to consider a ListView instead, since the data is readonly. In this case, you don't need strong typed properties, just columns in the underlying data table (they must be aliased in SQL though). You might have set up the population setting via code, but it works...I'm using heavily in a custom search form I use. In my case, I'm allowing the user to search on not just the base table, but also on values in a parent table and/or other FK tables. E.g. in your case, this would allow the user to search on unit description to retrieve a work order. I build the list view based on columns in the data table. You just need to alias all the columns in SQL. I don't think you can set this up via the designer, as it will only show you the strongly typed properties.



Of course, if you need to pump out reports, then you may be back to a grid....which means either adding the custom properties to the appropriate BO or creating a special BO based on a view. You may find that the custom properties are the way to go, as they might have other uses. If you use them, you'd just need to add these columns to your fill methods, then access the extra columns in you properties. There are lots of good posts on this out there.



Hope that helps!

Dustin,

Much appreciated response!  I do not want to "complicate" things by adding custom properties to the first BO which reflect the already existing properties of the second and third BO.  I think that I may be trying to do something with business objects that they were not intended to do.  In other words, I cannot "query" (derive a table from) the business objects...I need to go back to the source DB for that.

Bill

Sorry.  My communication skills do lack.  Getting what is in my brain onto paper has always been difficult.  I apologize in advance if I sound like I am repeating myself.

The grid is going to be read-only.  The user just wants to view the data (and I may whip out a report or two from the grid).  I am trying to get fields from three tables into one table-like presentation to the user.  Since the three BOs already exist, I was hoping to utilize some functionality there.  Since relations exist, couldn't I somehow derive a table from the three BOs and throw that into the grid?

Just exploring.

One more approach on top of Trent's suggestion is to bring everything into the Work Orders BO. Greg's already hit on this, the only additional thing you would need to do is create public properties and custom bindable property descriptors so that the BBS will recognize those new fields. 

As Trent said, however, doing it this way (pulling everything into a single BO) would only work if the data is meant to be read only. If you want to be able to update the data through the grid, you will need to use Trent's suggestion of the  updateable view.

If the grid is read only, and you do want to handle it all via the work orders BO, then your original response to Greg is most of the way there.  Once the custom fields are pulled in via your custom query (just like you described in your original reply to Greg), you will need to expose them via public properties on the work order BO:

And then provide custom property descriptors on the work order BO to access those custom fields:

Actually this isn't far off.  There are a couple of things that you may want to consider.  First, I more than likely would not be trying to put all 3 tables inside of one grid unless they are all one-to-one relationships.  Otherwise this would get really messy.  In this case though, you would just want to create an updatable view which pulls this back and would then allow a record set to be updated going back the other way. 

What you are trying to accomplish is not outside of the scope of the framework and can be done, but the reason that you have received some of the comments suggesting other mechanisms is because a grid gets really messy when trying to cram all of this into one locale.  If this were read-only then it wouldn't be as big of a deal.  But in any case, just create an updatable view, then all of your BOs, custom properties, etc. will all work.  You can then create a new Custom BBS through the templates which will just side step the need to drop on a separate BBS on the form (same approach that is used for reporting).

Note: When creating updatable views, you must still specify a primary key field.  To do this, open up the BO Mapper, right-click the BO in question, then open the advanced section.  Then override the PK field and specify a PK so that the updates will work properly.