Results 1 to 27 of 27

Thread: "conditional" dim type

  1. #1

    Thread Starter
    New Member
    Join Date
    Nov 2017
    Posts
    5

    "conditional" dim type

    Hello All.

    I have a procedure I call from 2 different areas in my app/

    The procedure does the same thing for both situations, but in one case must have one of its internal variables declared as type A and in the other case the same variable must be declared as type B.

    So, the following obviously does not work, I am aware that you can not do a Dim inside and if statement. This is where I need a solution. A non-declared variable would work, but i like it better for 'clean' & ease programming and intellisense.

    Code:
    Public Sub FillHistoryGrid(ByRef TempmyVar)
           If condition = true Then
               Dim myVar As New List(Of Type5)
           Else
               Dim myVar As New List(Of Type6)
           End If
    
           myVar = TempmyVar
    
          ...
    end sub
    Any ideas?

    Thanks for all your help!

  2. #2
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: "conditional" dim type

    There may not be any "ideal" solution to your problem but there may be things you can do. Those things would depend on the specifics of the situation though, and you haven't provided enough of those specifics. Please explain what you're actually trying to achieve, rather than how you're trying to achieve it. We can then recommend the best way(s) to achieve that aim, rather than trying to torture a solution to what might not even be the right problem. For instance, it may be that that simply writing a generic method is the best option, or overloading a method, or using a non-generic interface, or something else. Your explanation is simply too vague to really know. We need more specific details.

  3. #3
    Addicted Member Goggy's Avatar
    Join Date
    Oct 2017
    Posts
    196

    Re: "conditional" dim type

    Not sure if this helps you, but are you familiar with the concept of overloading?

    https://msdn.microsoft.com/en-us/library/ms973896.aspx
    Utterly useless, but always willing to help

    As a finishing touch god created the dutch

  4. #4
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    985

    Re: "conditional" dim type

    Sounds like you just need late binding

    never tried it in .NET but it would go something like this

    in a module just declare a variable

    'Public MyVar'

    then in an if statement you can something like

    'Set MyVar = New Object

    then after your finished

    Set MyVar = Nothing


    again i have never tried to do this in .Net but its something ive don in VBA which works...... so im sure someone will shout out if it doesnt work
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  5. #5
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: "conditional" dim type

    Quote Originally Posted by GBeats View Post
    Sounds like you just need late binding
    Late binding should be a last resort. It may be the best solution but there may be much better options, depending on the specifics of the situation.

  6. #6
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    985

    Re: "conditional" dim type

    Quote Originally Posted by jmcilhinney View Post
    Late binding should be a last resort. It may be the best solution but there may be much better options, depending on the specifics of the situation.
    i agree, there is alot of overhead doing this but for simple tasks ive never encountered a problem..... i wouldnt do this in a large tight loops for example but for something trivial like a button press its not going to cause a problem really...

    im sure jmc has a rebuttal
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  7. #7
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: "conditional" dim type

    The fact that you've never encountered a problem doing something is no reason to do it if there are better options.

  8. #8
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,458

    Re: "conditional" dim type

    I would avoid late binding if possible as you lose all type safety and errors are much harder to track down.

    Without further detail as to what is needed I think jmcilhinney's suggestion of a Generic Method is probably the best.

    Code:
        Public Sub FillHistoryGrid(Of T)(ByRef TempmyVar As List(Of T))
    
            Dim myVar As New List(Of T)
    
            myVar = TempmyVar
        End Sub
    although without knowing what the "condition" is in the original post I could be completely wrong here.

  9. #9
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    985

    Re: "conditional" dim type

    Quote Originally Posted by jmcilhinney View Post
    The fact that you've never encountered a problem doing something is no reason to do it if there are better options.
    i sense alot of hostility from you.....

    im merely giving an option that may work which the OP hasent yet received.... im just trying to help....

    if you have better ideas then great you know ill listen. no need to be so... 'in my face about it '
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  10. #10
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: "conditional" dim type

    Quote Originally Posted by GBeats View Post
    i sense alot of hostility from you.....

    im merely giving an option that may work which the OP hasent yet received.... im just trying to help....

    if you have better ideas then great you know ill listen. no need to be so... 'in my face about it '
    You're making the mistake of interpreting criticism of your idea as a personal attack. I'm just stating facts. As I stated clearly, late-binding might be the best solution but there's no way to tell based on the information provided. If it turns out to be the best option then I'll whole-heartedly endorse the idea but if the OP just goes ahead and uses late-binding without considering whether it's the best option then they do themselves a disservice. There are a number of tools available in VB.NET that don't exist in VB6 or VBA (interfaces, generics and maybe overloading), so late-binding is needed far less often.

  11. #11
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    985

    Re: "conditional" dim type

    Quote Originally Posted by jmcilhinney View Post
    You're making the mistake of interpreting criticism of your idea as a personal attack. I'm just stating facts. As I stated clearly, late-binding might be the best solution but there's no way to tell based on the information provided. If it turns out to be the best option then I'll whole-heartedly endorse the idea but if the OP just goes ahead and uses late-binding without considering whether it's the best option then they do themselves a disservice. There are a number of tools available in VB.NET that don't exist in VB6 or VBA (interfaces, generics and maybe overloading), so late-binding is needed far less often.
    well i apologize.

    i do see how an overloaded class would also help here, never tried it but setting up several known types within the class waiting to be initialized with a certain overloaded initializing function would prevent late binding would give a little overhead but an explicit variable to use.... i think the pros far out way the cons really thinking about it compared to late binding which i know is a nightmare to troubleshoot....

    Actually thinking about it, you could probably set up a class to include every type available and overload it. call it a managed late binding class
    not sure how that might work in terms of overhead but i think im going to try it.
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  12. #12
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    985

    Re: "conditional" dim type

    @OP

    ok i came up with something that may work...... its very basic and someone will elaborate i hope..

    Code:
    Public Class ManagedLateBinding
    
        'These structures could be put in a module so they are available to your code anywhere you need them
        Private Structure Type1
            Const TypeName As String = "Type1"
            Dim var1 As String
            Dim var2 As Integer
        End Structure
    
        Private Structure Type2
            Const TypeName As String = "Type2"
            Dim var1 As Boolean
            Dim var2 As Single
        End Structure
    
        Private StructureUsed As Integer
        Private Structure1 As Type1
        Private structure2 As Type2
    
        Public Sub New(str As String, int As Integer)
            'put code here to populate structure 1
            StructureUsed = 1
        End Sub
    
        Public Sub New(bool As Boolean, sin As Single)
            'put code here to populate structure 2
            StructureUsed = 2
        End Sub
    
    
        Private Function FindType() As Object
            Select Case StructureUsed
                Case 1
                    Return (Structure1)
                Case 2
                    Return (structure2)
                Case Else
                    Return (Nothing)
            End Select
        End Function
    
        ReadOnly Property ReturnData As Object
            Get
                Return FindType()
            End Get
        End Property
    
    End Class
    so this class you would initialize and set up the required fields with the datatypes required to populate a pregiven type/structure (or make a class instead of structure).

    this kind of methods means you need to know beforehand what objects/datatypes your using but you can setup functions to return various types of data based on the type used etc etc.... or dump the entire data into an object(just like late binding but, you can troubleshoot errors from the class data easily)

    im pretty sure this could get very complex but i think this could certainly work for u with a bit of tweaking.
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  13. #13
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,532

    Re: "conditional" dim type

    Meanwhile the OP has gone MIA... so we may never know what it is they needed...

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  14. #14
    Powered By Medtronic dbasnett's Avatar
    Join Date
    Dec 2007
    Location
    Jefferson City, MO
    Posts
    9,754

    Re: "conditional" dim type

    Quote Originally Posted by PlausiblyDamp View Post
    I would avoid late binding if possible as you lose all type safety and errors are much harder to track down.

    Without further detail as to what is needed I think jmcilhinney's suggestion of a Generic Method is probably the best.

    Code:
        Public Sub FillHistoryGrid(Of T)(ByRef TempmyVar As List(Of T))
    
            Dim myVar As New List(Of T)
    
            myVar = TempmyVar
        End Sub
    although without knowing what the "condition" is in the original post I could be completely wrong here.
    Generics would seem to be the way to go.
    My First Computer -- Documentation Link (RT?M) -- Using the Debugger -- Prime Number Sieve
    Counting Bits -- Subnet Calculator -- UI Guidelines -- >> SerialPort Answer <<

    "Those who use Application.DoEvents have no idea what it does and those who know what it does never use it." John Wein

  15. #15
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: "conditional" dim type

    I think PD's answer #8 is probably the right path.

    What JMC touched on is there's likely a different and better solution to this problem. But you've only asked a question about how to get a specific solution to work, so it's hard for us to decide what the "different and better solution" might be. (I do like trying to correct JMC when he is too harsh but in this case I really think he was being "firm", not "mean".

    It's kind of like if I asked you how to make a screwdriver hurt less when I hit things with it. The right answer isn't to suggest wrapping the handle with tape or something soft. The right answer is to ask, "Well... why are you hitting things with a screwdriver?" That might lead me to reveal I'm trying to drive nails, and then you can rightfully suggest I use a hammer.

    It doesn't really matter if the screwdriver's been working. A hammer is a better solution to the problem. Professionals should always be seeking the "best" solutions, lest their skillset stagnate.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  16. #16
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: "conditional" dim type

    I liked JMC's first answer, the best: We don't know enough to say what would work best, in this case.

    Generics are great.....unless they only work with types A and B, and somebody offers up type C.
    Overloads are great.....unless the situation is such that they aren't.
    Late binding is great....but only when necessary, cause it's ALWAYS slower (you may not notice, though), can hide bugs, and can be painful to debug.

    There's also a fourth option, at least, which is almost silly, but the OP left it open as a possibility: Take an extra argument, and use the one that is appropriate. That's bad....unless it is the best option. We simply don't know enough to say.....but we sure are happy to advise.
    My usual boring signature: Nothing

  17. #17

    Thread Starter
    New Member
    Join Date
    Nov 2017
    Posts
    5

    Re: "conditional" dim type

    Hello Everybody - sorry for the delay, but i only have occasionally time to work on this.

    Thanks everybody for their thoughts and ideas. I guess i have to provide a better example/explanation of what i am trying to do.

    I have/build a program which runs calculations/analysis against number sets. These sets can be with 2 different characteristics (hence the 2 structures).

    some of the calculations are exactly the same regardless of structure 1 or 2, therefore i am trying not to duplicate the coding and have 2 seperate Subs with the same code.

    this is where the Subs needs to be flexible as to which structure it is receiving. I have tried to not specify the type for the variable, but as i have some, i think they are called Lambda functions, those didn't like that too much and errored.

    below is a more detailed sample of what i am trying to do. i realy can't change anything other than the "FillGrid" or the button clicks as the structures are already used all over the app.


    Code:
    Public Structure myPair1
        Dim Number1 As Integer
        Dim Number2 As Integer
        Dim PairCount As Integer
        Private _Number_1 As Integer
        Private _Number_2 As Integer
        Private _p3 As Integer
     
        Sub New(Number_1 As Integer, Number_2 As Integer, p3 As Integer)
            ' TODO: Complete member initialization 
            If Number_1 < Number_2 Then
                _Number_1 = Number_1
                _Number_2 = Number_2
            Else
                _Number_1 = Number_2
                _Number_2 = Number_1
            End If
            _p3 = p3
            Number1 = _Number_1
            Number2 = _Number_2
            PairCount = _p3
        End Sub
    End Structure
    
    Public Structure myPair2
        Dim Number1 As Integer
        Dim Number2 As Integer
        Dim Number3 As Integer
        Dim PairCount As Integer
        Private _Number_1 As Integer
        Private _Number_2 As Integer
        Private _Number_3 As Integer
        Private _p3 As Integer
     
        Sub New(Number_1 As Integer, Number_2 As Integer, p3 As Integer)
            ' TODO: Complete member initialization 
            If Number_1 < Number_2 Then
                _Number_1 = Number_1
                _Number_2 = Number_2
            Else
                _Number_1 = Number_2
                _Number_2 = Number_1
            End If
            _p3 = p3
            Number1 = _Number_1
            Number2 = _Number_2
            Number3 = _Number_3
            PairCount = _p3
        End Sub
    End Structure
    
    
        Private Sub btn_1_Click(sender As System.Object, e As System.EventArgs) Handles btn_1.Click
            dim myPairs1 as new List(of myPair1)
            myPair1.Number1 = 1
            myPair1....
    
            FillGrid(myPairs1)
        End Sub
    
        Private Sub btn_2_Click(sender As System.Object, e As System.EventArgs) Handles btn_2.Click
            dim myPairs2 as new List(of myPair2)
            myPair2.Number1 = 1
            myPair2....
    
            FillGrid(myPairs2)
        End Sub
    
    Public Sub FillGrid(ByRef TempmyPairs)
            Dim myCash5Pairs
            If Form1.AllGames.Item(myGame).NumbersToPick = 5 Then
                myPairs = New List(Of myPair1)
            Else
                myPairs = New List(Of myPair2)
            End If
            myPairs = TempmyPairs
    
            ' ''' 
    
            ' sort the list so that we can hilghlight best and worst
            myPairs.Sort(Function(p1, p2) p1.PairCount.CompareTo(p2.PairCount))
    
            .....
    end sub

  18. #18
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: "conditional" dim type

    Those are pretty large for structures, so you might consider making them classes.

    You COULD use inheritance for this. It looks like myPair1 is a subset of myPair2, so you could have myPair2 inherit from myPair1. You'd then just pass in an argument of type myPair1, because any child can be implicitly cast to its base. In other words, if the argument was type myPair1, you could freely pass in an object of type myPair2, because myPair1 is a base of myPair2, so you don't even need to do any conversion.

    Internally, if you had that inheritance relationship, then you could make a List(of myPair1), which could hold either myPair1 or myPair2. You can also use GetType to figure out which type you actually have, and if it is a myPair2, you could cast it to the proper type to get access to the members specific to myPair2. Alternatively, you could add a member to myPair1 that would just return True or False, or an integer, or something, to indicate whether it was a myPair1 or myPair2. That may be faster than the reflection that GetType would require....but quite likely not.

    Another advantage of inheritance is that myPair2 would only need those members that are unique to that type. It would inherit the members from myPair1 that are either Protected or Public....well, it would really inherit ALL the members, but would only have access to those that are Protected or Public.
    My usual boring signature: Nothing

  19. #19
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    985

    Re: "conditional" dim type

    for me the only thing i see is one structure is using an extra set of variables, and since your already using these structures throughout i would simply make another structure just like you have but use arrays instead.

    It seems like in mypair1 your assigning the lowest value to number1 and the other value goes to nummber 2, but in mypair2 the number 3 is just number 3 no matter what the other values are? and you seem to be just repeating values?

    Code:
    Dim Number1 As Integer
        Dim Number2 As Integer
        Dim Number3 As Integer
        Dim PairCount As Integer
        Private _Number_1 As Integer
        Private _Number_2 As Integer
        Private _Number_3 As Integer
        Private _p3 As Integer
    seem very redundant....

    the logic seems all the same and i would actually just replace both structures and replace them with another one that uses arrays and if needbe write some functions to return the values that you need from the current code you have......

    if that is to much work then i would just write a third structure based on the other 2..

    in any case this is how i may do it, have a look and see if this would work.
    Code:
    Public Structure myPair3
        Dim Numbers() As Integer
        Dim PairCount As Integer
        Dim PairIndex as Integer
        
        Sub New(PairIndex AS Integer, Number_1 As Integer, Number_2 As Integer, p3 As Integer, Optional Number_3 As Integer) 'Or use a Param Array here instead and count the entries
    
            if pairindex = 1 then
                 redim Numbers(1)
                 If number_1 > Number_2 then
                       Numbers(0) = Number_1
                       Numbers(1) = Number_2
                  Else
                       etc etc....
                  End If
           End Sub
    End Structure
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  20. #20
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: "conditional" dim type

    I still don't get it. (And GBeats is confused by the same thing!)

    Let's look at:
    Code:
    Public Structure myPair2
        Dim Number1 As Integer
        Dim Number2 As Integer
        Dim Number3 As Integer
        Dim PairCount As Integer
        Private _Number_1 As Integer
        Private _Number_2 As Integer
        Private _Number_3 As Integer
        Private _p3 As Integer
     
        Sub New(Number_1 As Integer, Number_2 As Integer, p3 As Integer)
            ' TODO: Complete member initialization 
            If Number_1 < Number_2 Then
                _Number_1 = Number_1
                _Number_2 = Number_2
            Else
                _Number_1 = Number_2
                _Number_2 = Number_1
            End If
            _p3 = p3
            Number1 = _Number_1
            Number2 = _Number_2
            Number3 = _Number_3
            PairCount = _p3
        End Sub
    End Structure
    The only thing different in this structure from myPair1 is the Number3 field and _Number_3 field. neither of these are actually set. The constructor is identical to myPair1 so when you get to this line:
    Code:
    Number3 = _Number_3
    That's not doing anything but setting a variable that's already 0 to be 0. Maybe this is some kind of error so let me step aside from it and illustrate how I'd handle what I think you might have.

    My guess is you have data types with Number1, Number2, ..., NumberN. I'm not quite sure what PairCount is. If I had to design this type, here's what I would've done:
    Code:
    Public Class NumberSet
        
        Public Property Numbers() As Integer
        Public Property PairCount As Integer
    
        Public Sub New(ByVal numbers As IEnumerable, ByVal pairCount As Integer)
            Me.Numbers = numbers.ToArray()
            Array.Sort(Me.Numbers)
            Me.PairCount = pairCount
        End Sub
    
    End Class
    Now FillGrid would look something like this:
    Code:
    Public Sub FillGrid(ByRef inputPairs As IEnumerable(Of NumberSet))
        
        ' Instead of ''' you should've showed us what you do here.
    
        inputPairs = inputPairs.OrderBy(Function(p) p.PairCount)
    End Sub
    If the only difference between the two structures is "the number of integers", an array represents that concept perfectly.

    I'm still suspicious if you weren't hiding most of your code I could come up with a much better solution. I'm still guessing at 80% of what you're trying to do. My guess is the hangup is FillGrid wants to create DataRow objects for a DataGridView, and you're not sure how to facilitate different numbers of field per structure. How warm am I?
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  21. #21

    Thread Starter
    New Member
    Join Date
    Nov 2017
    Posts
    5

    Re: "conditional" dim type

    thanks for your replies.

    GBeats :
    interesting thought with the array , but:
    - these structures are used all over the app and a variable using such a structure might be filled, tossed around, etc throughout and then being used in several functions down the road. the sample i created is strongly simplified.
    - since i have some sorting, finding, and comparing calls against variable with those structures i found it easier to a structure architecture as i have indicated above. it allowed for certain actions which i was not able to do otherwise.

    Shaggy Hiker:
    - as mentioned to GBeats i really don't want to change the structures, as i would have to re-invent the wheel throughout the program.
    - i used to have those as classes, because it gave me greater architect abilities. but i found that classes are limited in certain areas (i don't remember which problem i ran into back than), but structures worked better in my case. When i had to change it to structures i had to go through the entire app and adjusted coding - it was a pain!

  22. #22

    Thread Starter
    New Member
    Join Date
    Nov 2017
    Posts
    5

    Re: "conditional" dim type

    Sitten Spynne :

    Yes, you are correct: i am "hiding" most of my code. although hiding is not entirely the correct word. i am just not able to post all of the some 8000 lines of code here.

    And yes, the structures are much more complex then posted here and there are more similar structure than that one. my sample was a sample and a proof of concept.

    as i mentioned these structures and the variable using them are used and "molded" throughout the entire app.

    as in my other reply, i come back to saying before i change the architecture of the structure i rather have FillGrid twice.

    since all the responses focus on changing the structures, i guess that's what i will have to do.



    again, thanks everybody for your suggestions!

  23. #23

    Thread Starter
    New Member
    Join Date
    Nov 2017
    Posts
    5

    Re: "conditional" dim type

    Quote Originally Posted by Goggy View Post
    Not sure if this helps you, but are you familiar with the concept of overloading?

    https://msdn.microsoft.com/en-us/library/ms973896.aspx
    Goggy :

    Thanks for your reply.

    I had not worked with overloading - i'll look into it.

    upon 1st reads it seams it may be the answer - i have to find out how that exactly works and how to build this.

  24. #24
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: "conditional" dim type

    While I agree that changing something throughout an app can be a difficult trigger to pull, sometimes it is the right one.
    My usual boring signature: Nothing

  25. #25
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: "conditional" dim type

    I understand but I'm not really sure I can really give a good answer while in the dark. I get that sometimes it's not possible/feasible/legal to post it all. This is a frustrating way our hands get tied.

    The thing is, when it comes to architecture we tend to think in patterns and abstractions to a degree that a lot of people can't stomach. That's why when I saw your structures, the only thing I could see is "an array of Integer", it's a substitute for "a lot of fields".

    The problem as you have it is making me think about how I think when I'm in a less strongly typed language like JavaScript. In modern languages, designers are experimenting with the idea of types having a "shape" defined by their members. If two types have the same or similar "shapes", they're interchangeable in these languages. The more functional ones prefer using "tuples" instead of types for this, and this concept has bled into C#.

    When a language has those concepts, you can write code that does different things based on the "shape" of its input. "Number of members" is one of the things that can distinguish the "shape" of an object. So in C# it's possible to take a variety of Tuples and do different things based on their shape. VB does not have such sophisticated support for ValueTuple so it can't talk about the "shape" of types.

    That's why I suggested changing the Structures to have an array of Integer rather than several Integer properties. In pre-2017 C# and all flavors of VB, that is the only way we can express the "shape" that says "I have a variable number of Integer values."
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  26. #26
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: "conditional" dim type

    I know I'm a little late to this party but I find it strange no one suggested using interfaces for this. Interfaces would solve this more elegantly. While you can shoehorn generics and inheritance to fit this, these solutions suffer from their weaknesses. Inheritance doesn't allow you to mix and match features in an elegant way:-
    vbnet Code:
    1. '
    2.     Public Class BaseType
    3.         Property NumberType1 As Integer
    4.         Property NumberType2 As Integer
    5.     End Class
    6.  
    7.     Public Class TypeA
    8.         Inherits BaseType
    9.  
    10.         Property NumberType3 As Integer
    11.         Property NumberType4 As Integer
    12.  
    13.     End Class
    14.  
    15.     Public Class TypeB
    16.         Inherits BaseType
    17.  
    18.         Property NumberType5 As Integer
    19.         Property NumberType6 As Integer
    20.  
    21.     End Class
    22.  
    23.     Public Class TypeC
    24.         Inherits BaseType
    25.  
    26.         Property NumberType7 As Integer
    27.         Property NumberType8 As Integer
    28.         Property NumberType9 As Integer
    29.     End Class
    30.  
    31.     Public Class TypeAB
    32.         Inherits BaseType
    33.  
    34.         Property NumberType3 As Integer
    35.         Property NumberType4 As Integer
    36.         Property NumberType5 As Integer
    37.         Property NumberType6 As Integer
    38.  
    39.     End Class
    40.  
    41.     Public Class TypeAC
    42.         Inherits BaseType
    43.  
    44.         Property NumberType3 As Integer
    45.         Property NumberType4 As Integer
    46.  
    47.         Property NumberType7 As Integer
    48.         Property NumberType8 As Integer
    49.         Property NumberType9 As Integer
    50.  
    51.  
    52.     End Class

    Pay particular attention to TypeAB and TypeAC. We wanted a combination two different combinations of the types previously defined. The problem is that these combo types are two different types, and we would have to write extra code for these extra types. But we shouldn't have to do that since semantically they are a combination of previous types. We should be able to let the TypeA code handle the TypeA part of TypeAB and the TypeB code handle the TypeB part of TypeAB. The same logic should apply to TypeAC.
    vbnet Code:
    1. '
    2.     Public Class MyProcessingMethods
    3.         Public Shared Sub Process(ByVal type As BaseType)
    4.  
    5.             DoWork(type.NumberType1)
    6.             DoWork(type.NumberType2)
    7.  
    8.             If TypeOf type Is TypeA Then
    9.                 With DirectCast(type, TypeA)
    10.                     DoWork(.NumberType3)
    11.                     DoWork(.NumberType4)
    12.                 End With
    13.             End If
    14.  
    15.             If TypeOf type Is TypeB Then
    16.                 With DirectCast(type, TypeB)
    17.                     DoWork(.NumberType5)
    18.                     DoWork(.NumberType6)
    19.                 End With
    20.             End If
    21.  
    22.             If TypeOf type Is TypeC Then
    23.                 With DirectCast(type, TypeC)
    24.                     DoWork(.NumberType7)
    25.                     DoWork(.NumberType8)
    26.                     DoWork(.NumberType9)
    27.                 End With
    28.             End If
    29.  
    30.             If TypeOf type Is TypeAB Then
    31.                 With DirectCast(type, TypeAB)
    32.                     DoWork(.NumberType3)
    33.                     DoWork(.NumberType4)
    34.                     DoWork(.NumberType5)
    35.                     DoWork(.NumberType6)
    36.                 End With
    37.             End If
    38.  
    39.             If TypeOf type Is TypeAC Then
    40.                 '.......You get the point
    41.             End If
    42.  
    43.  
    44.         End Sub
    45.  
    46.         Private Shared Sub DoWork(ByVal v As Integer)
    47.  
    48.         End Sub
    49.     End Class

    The problem with the above is that we are repeating code when we don't have to. We are writing code to handle TypeA three times, once for TypeA, once for TypeAB and once for TypeAC. We should only have to do this once. Now you could reduce this by having TypeAB inherit from TypeA instead of the base type and do something similar for TypeAC but you're still going to be repeating code. For TypeAB, you'd still be repeating for the TypeB portion of TypeAB.

    Interfaces solves this quite nicely:-
    vbnet Code:
    1. '
    2. Public Interface ICommon
    3.     Property NumberType1 As Integer
    4.     Property NumberType2 As Integer
    5. End Interface
    6.  
    7. Public Interface ISetA
    8.     Property NumberType3 As Integer
    9.     Property NumberType4 As Integer
    10. End Interface
    11.  
    12. Public Interface ISetB
    13.     Property NumberType5 As Integer
    14.     Property NumberType6 As Integer
    15. End Interface
    16.  
    17.  
    18. Public Interface ISetC
    19.     Property NumberType7 As Integer
    20.     Property NumberType8 As Integer
    21.     Property NumberType9 As Integer
    22. End Interface

    Now you can mix and match as you please. You could combine A and B or A and C or A, B and C but you only have to write code for 3 interfaces. Don't matter how many combinations you create, you only have to test for 3 interfaces:-
    vbnet Code:
    1. '
    2. Public Class MyProcessingMethods
    3.     Public Shared Sub Process(ByVal type As ICommon)
    4.  
    5.         DoWork(type.NumberType1)
    6.         DoWork(type.NumberType2)
    7.  
    8.         If TypeOf type Is ISetA Then
    9.             With DirectCast(type, ISetA)
    10.                 DoWork(.NumberType3)
    11.                 DoWork(.NumberType4)
    12.             End With
    13.         End If
    14.  
    15.  
    16.         If TypeOf type Is ISetB Then
    17.             With DirectCast(type, ISetB)
    18.                 DoWork(.NumberType5)
    19.                 DoWork(.NumberType6)
    20.             End With
    21.         End If
    22.  
    23.         If TypeOf type Is ISetC Then
    24.             With DirectCast(type, ISetC)
    25.                 DoWork(.NumberType7)
    26.                 DoWork(.NumberType8)
    27.                 DoWork(.NumberType9)
    28.             End With
    29.         End If
    30.     End Sub
    31.  
    32.     Private Shared Sub DoWork(ByVal v As Integer)
    33.  
    34.     End Sub
    35. End Class

    In the future OP, you should think about interfaces when you come up against a problem like this. It will save you a lot of headaches.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  27. #27
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    Re: "conditional" dim type

    Yeah, interfaces can solve a whole lot of issues. I don't think they get enough coverage.
    My usual boring signature: Nothing

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