Interface and objects

[wiss.dev]

Hi All,

i have 4 objects of diffrent types, which i need to show in a single data grid in an a quoting program, and perform some summary calculations to all 4 types.
so i created an interface, and implemented to all types.

to add a new oProduction to quote,

 Dim NewProduction As iTranLine = New oProduction
  Dim frm As New FrmProduction()
        frm.ShowDialog(Me)
        NewProduction = frm.PRD ' PRD is of type oProduction 
        frm = Nothing

        Me.TRAN.TranLines.Add(NewProduction) ' TranLines is a list of iTranLine

need to display the iTranLine for all types in one data grid, but still have access to oProduction and oInv other properties, and not sure how to achieve that without having to create 5 different collections, for all 4 types and 1 for iTranLine.

Help please ...

Public Interface iTranLine
    Property TranLineID As Integer
    Property TranLineSortOrder As Integer
    ReadOnly Property TranLineItemID As Integer
    ReadOnly Property TranLineItemCode As String
    ReadOnly Property TranLineItemDesc As String
    Property TranLineQty As Decimal
    Property TranLinePrice As Decimal


    ReadOnly Property TranLineType As enTranLineType

End Interface

' Type 1 :calss deinition

Public Class oProduction : Inherits oBOM
    Implements iTranLine
' Properties ...
end class

' Type 2

Public Class oInv
    Implements iTranLine

    Public Property ID As Integer
    Public Property Code As String
    Public Property Title As String
END CLASS

[jmcilhinney]

It's called "casting" dude. You can do it in various ways. E.g.

Public Interface ISomeInterface
 
    '...
 
End Interface
 
Public Class FirstClass
    Implements ISomeInterface
 
    '...
 
End Class
 
Public Class SecondClass
    Implements ISomeInterface
 
    '...
 
End Class

Dim things As New List(Of ISomeInterface) From {New FirstClass,
                                                New SecondClass,
                                                New FirstClass,
                                                New SecondClass,
                                                New FirstClass,
                                                New FirstClass,
                                                New SecondClass}
 
For Each thing In things
    If TypeOf thing Is FirstClass Then
        Dim obj = DirectCast(thing, FirstClass)
 
        'Use obj here.
    ElseIf TypeOf thing Is SecondClass Then
        Dim obj = DirectCast(thing, SecondClass)
 
        'Use obj here.
    End If
Next
 
For Each thing As ISomeInterface In things
    Dim firstObj = TryCast(thing, FirstClass)
 
    If firstObj IsNot Nothing Then
        'Use firstObj here.
    End If
 
    Dim secondObj = TryCast(thing, SecondClass)
 
    If secondObj IsNot Nothing Then
        'Use secondObj here.
    End If
Next
 
For Each thing In things.OfType(Of FirstClass)()
    'Use thing here.
Next
 
For Each thing In things.OfType(Of SecondClass)()
    'Use thing here.
Next

[wiss.dev]

Thanks @jmcilhinney
my approch didn't actually work, as i'm not able to edit oProduction type in iTranLine datagrid so i ended up having 2 grids
grid1.datasource = list(of iTranLine) ' which includes all 4 types
grid2.datasource= list(of oProduction) ' only shows production type
here i will have to sync any change between both collections

below code is executed on switching the view mode, how can i have two diffrent views withount maintaining 2 different data sources. thanks

  Select Case ViewMode
            Case enViewMode.General
                ViewMode = enViewMode.Production
                TabControlMain.SelectedTabPageIndex = 1
                TRAN.lstProduction.Clear()
                For Each iTL In Me.TRAN.TranLines.Where(Function(x) x.TranLineType = enTranLineType.Production)
                    Me.TRAN.lstProduction.Add(DirectCast(iTL, oProduction))
                Next
                GrdProduction.RefreshData()
            Case enViewMode.Production
                ViewMode = enViewMode.General
                ' Exclude Production Types 
                TRAN.TranLines = TRAN.TranLines.Where(Function(x) New enTranLineType() {enTranLineType.Inventory, enTranLineType.Ledger, enTranLineType.Text}.Contains(x.TranLineType))
                TRAN.TranLines.AddRange(TRAN.lstProduction)
        End Select

[Shaggy Hiker]

Why weren't you able to edit the oProduction type in the IWhatever datagrid? You should be able to edit anything that is part of the interface (and is editable, of course, which rules out some ReadOnly properties). You could also determine whether or not the IWhatever was actually type oProduction and cast it, but that leaves something of a question: What do you do if the edit happens on an item in the grid that is NOT type oProduction. It seems to me that the grid should be showing those things common to anything that implements the interface. If the editing mechanism for the item is not also part of the interface, then you run into the problem that the user won't know whether they are looking at an oProduction, oInv, or oMyGod. They will blithely attempt to edit, thinking that they should be able to, so you need to allow them to edit regardless of the type. If they really can only edit items of type oProduction, then putting those into the grid along with types they can't edit, will just confuse the user. If editing is possible on all of them, then isn't that part of the interface for the objects?

[wiss.dev]

Why weren't you able to edit the oProduction type in the IWhatever datagrid?

oProduction have many other properties which arent required for other types and not implemented by the interface. i might add all production properties to interface, cant think of any better way

[jmcilhinney]

I didn't realise that you meant that you wanted to be able to edit the other properties in the grid. That's not possible. You can only edit in the grid what the grid has a column for and, if you use data-binding, then the grid only has a column for each property of the type of objects that you bound. If you bound a list of an interface then it's only the properties of that interface for which the grid will create columns. If you want something else then you'll need more manual intervention and, while I'm not 100% certain, may need to abandon data-binding altogether.

[Shaggy Hiker]

I'd say that you should rethink the design if you want to edit the other properties of any of the objects in the grid. Aside from what JMC stated, the design principle seems flawed. The user can't be expected to know which type they are looking at in the group. They may be able to SEE which type they are looking at, so you might think that they should know what they are editing, but that's expecting a bit much of the user. Set your expectations lower and you won't be disappointed.


One option would be that you could either have a tab control, or just a panel, along with the DGV. When the user selects a row, then the appropriate objects for the specific type are populated on the other control. If you use a tab control, then you'd take the focus to the tab for that type of object, but a panel would be better than a tab control. If you use a panel, I'd create one for each type, with the controls necessary for editing an instance of that type. Then I'd set the .Top property of each of the panels to something big, such that they are off the screen (or something sufficiently negative that they are off the top of the screen). To show any panel, you'd only have to change the .Top property for the panel such that it is moved to where you want it.

Basically, I'd want the grid to only do things common to all object types, and use the panel for anything specific to any one type. However, if some of the types need nothing more than what is in the grid, I think it would still probably look best to do ALL editing for ALL types in the panel, rather than allowing some editing in the grid and other editing in the panel.

[jmcilhinney]

If you use a panel, I'd create one for each type, with the controls necessary for editing an instance of that type. Then I'd set the .Top property of each of the panels to something big, such that they are off the screen (or something sufficiently negative that they are off the top of the screen). To show any panel, you'd only have to change the .Top property for the panel such that it is moved to where you want it.

I'd suggest that it would be more logical to leave the Location of each Panel unchanged and simply call BringToFront on the one you want the user to see. That would move it to the top of the z-order and thus it would cover all the other Panels. Alternatively, you can set Visible to False for all but the one you want the user to see.

[Shaggy Hiker]

Both would be good, and it probably makes no difference. That bit about swapping panels around came from working with WinCE on PDAs. In that environment, moving the panels was much easier than any alternative, and was necessary. The design surface was as big as you could make it, but the resulting display was 320x240, which was the size for PDA screens back then. By making the form much larger than that, I could have several panels on the development screen at one time during design work. When the application ran, it swapped them into the view area, as needed.

On a modern system, there would be no advantage to having a form that is much larger than the screen. It may not even be possible, so any such mechanism for swapping the panels in and out would likely work just fine. The performance would probably be identical, or nearly so, and the performance would be excellent in all cases, so I would say: Do what makes most sense for you.

[wiss.dev]

that's exactly how i did it, i have dedicated forms for editing each type, when user double clicks the row the corresponding from pops up.
as for the additional properties, i ended up displaying interface properties for all types on the main tab, and production object on another tab as i need to display nested complex types and lists abd much more columns
i also added a button to switch the view mode which in turn sync any data changes to main source

Thanks for your help guys