Can you hide the first band in a wingrid? Or can I promote a child band to the parent band? I am trying to create drill-down type functionality, and I am trying to reuse the same grid. If I could just Hide the parent band, it would suffice, but upon hiding, all child bands disappear. Even if I hide the grid row.
Hiding a row will also hide its child rows. Hiding a band will also hide all the rows in that band. Because of this, you cannot hide the parent band without effectively hiding all rows in the grid.
What it sounds like you want to do is re-bind your grid to the path that represents the set of child rows you want to show. While I don't have code I can test, I'll explain how to do this in principle.
Consider the Northwind database, in particular the Orders table and the Order Details table. Bring these into a .NET DataSet, with a relation called "Orders_OrderDetails" to connect them by their OrderID. Set your grid's DataSource to this DataSet, and its DataMember to "Orders", which provides you with a hierarchical view of orders and order details.
Now assume that you want to re-bind your grid to show only the order details for a particular order. This requires two things. First, ensure that the order whose details you want to show is the "current" item in the .NET BindingManager; you can do this in WinGrid by either activating that row or any of its children. Next, set the DataMember of your grid to "Orders.Orders_OrderDetails" - the name of the parent table followed by the relation name. Your grid should now show only those order details corresponding to that individual order.
This approach is usually used when you're showing two grids on the same form, one for orders and one for order details. Clicking rows in the "orders" grid (which changes the "current' item in the BindingManager) changes the data displayed in the "order details" grid, without needing to further change that grid's DataMember.
I hope this helps you get the result you're after.
This sounds like what I need, and I am going to give it a try. What is the datamember name if I am not using a dataset with tables and relationships? I am actually binding to a bindinglist of an interface. The interface has a collection, which binds to the second band. It is the second band that I want to be the "Order Detail".
As far as hiding the band, I got really close by looping the columns of the first band, setting each one to hidden. I was able to turn off connectors, indention, spacing, and all of the other things normally seen. The only problem is that it left a white space where the first band would have painted, which I tried many, many things and could not prevent.
twinfrey said:What is the datamember name if I am not using a dataset with tables and relationships? I am actually binding to a bindinglist of an interface. The interface has a collection, which binds to the second band. It is the second band that I want to be the "Order Detail".
To extend my previous example, say you have an Order class and an OrderDetail class. The Order class includes a BindingList<OrderDetail> property called OrderDetails, and you set the DataSource of your grid to a BindingList<Order> object (leaving DataMember blank). To show a particular OrderDetail in this scenario, you'd set the DataMember of your grid to "OrderDetails".
Yes - just not expected by me. I lean against setting the appearance in code, as it often creates unexpected behavior. If you attempt to trace the generated code, the chosen naming convention is not intuitive and setting object properties can become misleading. Also, developers may use the designer only to find later that their settings are ignored, or duplicated. Depending on timing, adverse affects may occur. Certainly, I do configure at runtime, but I try to use the designer first - which funny enough, is the exact opposite of my web experience.
As alternative, I refactored my user controls as follows. I added a base user control with a grid property, to which I wired all of my grid events and actions. In the derived user controls, I actually draw the grid and its respective ultradatasource. During initialization, I wire the derived class's grid to the base control. This allows me to implement multiple data source shapes, using common funcitonality from the base. The trick of course is that all of the common functionality must consider that bands, columns, etc may or may not exist at runtime. But, with a flexible base, I was able to share the base code with minimal changes. I spent much, much more time trying to make a single data source work than I did in this refactor.
Thanks for all of your help.
Ah, I see what you mean now.
This behavior is expected. When you bind the grid to a new data source, it compares the existing bands and columns to the bands and columns that it would need to create. Any existing bands and columns that wouldn't exist under the new data source are discarded, along with their appearances. Bands and columns that didn't previously exist are created, with default appearances. Any bands and columns that are held in common by both data sources remain, and thus retain their appearances.
Because of this, when you bind the grid to a null data source, all the existing bands and columns are discarded.
The easiest way to deal with this is to style your grid in code, ideally in the InitializeLayout event. If you're comfortable with navigating the Windows Forms Designer Generated Code section, you can likely copy some of this code and put it (with some modifications) into your InitializeLayout event handler to duplicate your styling. You'll need to use conditional statements to ensure that the bands and columns you want to style actually exist before you try to set their properties.
When I set the datamember, the grid loses all of its appearance settings. For instance, the row shading, and the column header visiblity all resets as if it were not set in the designer. If I create a container shape, using the exact same data structure, I am able to easily switch the datamember between null and the child collection. With null, the grid looks correct. When set to a child collection, all appearance sets to default settings.
GridPlan.SetDataBinding(null, null) This also resets the appearance.
I'm not sure what you mean. The parent band and child band should each have their own set of columns.
That's interesting. It works for the most part. However, it appears to bind the child collection to the parent band's column collection, so only matching columns display. Am I missing something here? If this is the case, then it is no different than having set the datasource equal to the child collection of the record that I desire. This is not 100% what I want, but I can make it work.