Results 1 to 10 of 10

Thread: Interface and objects

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2009
    Location
    sydney
    Posts
    263

    Talking Interface and objects

    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,
    Code:
     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 ...

    Code:
    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
    Code:
    Public Class oProduction : Inherits oBOM
        Implements iTranLine
    ' Properties ...
    end class
    ' Type 2
    Code:
    Public Class oInv
        Implements iTranLine
    
        Public Property ID As Integer
        Public Property Code As String
        Public Property Title As String
    END CLASS

  2. #2
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    107,648

    Re: Interface and objects

    It's called "casting" dude. You can do it in various ways. E.g.
    vb.net Code:
    1. Public Interface ISomeInterface
    2.  
    3.     '...
    4.  
    5. End Interface
    6.  
    7. Public Class FirstClass
    8.     Implements ISomeInterface
    9.  
    10.     '...
    11.  
    12. End Class
    13.  
    14. Public Class SecondClass
    15.     Implements ISomeInterface
    16.  
    17.     '...
    18.  
    19. End Class
    vb.net Code:
    1. Dim things As New List(Of ISomeInterface) From {New FirstClass,
    2.                                                 New SecondClass,
    3.                                                 New FirstClass,
    4.                                                 New SecondClass,
    5.                                                 New FirstClass,
    6.                                                 New FirstClass,
    7.                                                 New SecondClass}
    8.  
    9. For Each thing In things
    10.     If TypeOf thing Is FirstClass Then
    11.         Dim obj = DirectCast(thing, FirstClass)
    12.  
    13.         'Use obj here.
    14.     ElseIf TypeOf thing Is SecondClass Then
    15.         Dim obj = DirectCast(thing, SecondClass)
    16.  
    17.         'Use obj here.
    18.     End If
    19. Next
    20.  
    21. For Each thing As ISomeInterface In things
    22.     Dim firstObj = TryCast(thing, FirstClass)
    23.  
    24.     If firstObj IsNot Nothing Then
    25.         'Use firstObj here.
    26.     End If
    27.  
    28.     Dim secondObj = TryCast(thing, SecondClass)
    29.  
    30.     If secondObj IsNot Nothing Then
    31.         'Use secondObj here.
    32.     End If
    33. Next
    34.  
    35. For Each thing In things.OfType(Of FirstClass)()
    36.     'Use thing here.
    37. Next
    38.  
    39. For Each thing In things.OfType(Of SecondClass)()
    40.     'Use thing here.
    41. Next

  3. #3

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2009
    Location
    sydney
    Posts
    263

    Re: Interface and objects

    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
    Code:
      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

  4. #4
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    36,583

    Re: Interface and objects

    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?
    My usual boring signature: Nothing

  5. #5

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2009
    Location
    sydney
    Posts
    263

    Re: Interface and objects

    Quote Originally Posted by Shaggy Hiker View Post
    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
    Last edited by wiss.dev; Jan 9th, 2017 at 06:58 PM.

  6. #6
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    107,648

    Re: Interface and objects

    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.

  7. #7
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    36,583

    Re: Interface and objects

    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.
    My usual boring signature: Nothing

  8. #8
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    107,648

    Re: Interface and objects

    Quote Originally Posted by Shaggy Hiker View Post
    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.

  9. #9
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    36,583

    Re: Interface and objects

    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.
    My usual boring signature: Nothing

  10. #10

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2009
    Location
    sydney
    Posts
    263

    Re: Interface and objects

    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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width