Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    CyrusNajmabadi
    @CyrusNajmabadi
    as well as: ah yes, this solution seems to at least actually solve taht use case.
    because you'd be surprised by how many language requests can't actually even give a case where they would be used, and how many requests ask for something that doesn't even adequately solve the case provided! :)
    Cory Smith
    @DualBrain
    @CyrusNajmabadi agreed. I'm having a hard time imagining what this might entail; one one hand I'm "why would this ever be needed" while on the other I'm "looks like there is something I might be missing here... some idea that I'm too thick headed to see".
    Mohammad Hamdy Ghanem
    @VBAndCs

    VB gives non-sense errors regarding ArressOf. See this sample:

    class Designer
        sub Designer_Loaded()
    
        End Sub
    
        Shared Sub Foo()
            AddHandler CurrentPage.Loaded, AddressOf Designer_Loaded ' Error 1
            AddHandler CurrentPage.Loaded, AddressOf Designer.Designer_Loaded ' Error 2
            AddHandler CurrentPage.Loaded, AddressOf CurrentPage.Designer_Loaded ' OK
        End Sub
    
    End class

    Error 1:

    annot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class.

    Error 2:

    Reference to a non-shared member requires an object reference.

    I think it is not right to treat the method address as if it is a method call and apply the same roles of shared and instance methods.
    A method address is just a name of a method that belongs to the class, and should be references to the class name (optional if within the class)
    method address should never be referenced to an object name defined of the class! This can't be right.
    Cory Smith
    @DualBrain
    This isnt the case... there are variable scoping rules in effect and the most likely outcome would be a runtime error. There is, however, things in place that would indicate that the target method should be marked as shared if it could be (warning) so if it were possible to write this code... the warning would have been ignored at this point... which would suggest that the dev intends on maybe accessing member variables.
    The two different errors is because you wrote two different ways... one that could find the method in the same class and the other that could have been written literally anywhere in the project.
    CyrusNajmabadi
    @CyrusNajmabadi
    @DualBrain hit it on the head
    Mohammad Hamdy Ghanem
    @VBAndCs
    As far i know, in iil, there is no instance methodes, but all methodes rseems like attached methods and recive an instance of the class to work on
    So, when i wtite addhandler object.event, addressof method
    I aleady supplied all info: the instance is object, and the method name is method
    If the call is in a shared sub, vb can easily know that i mean object.method beacuase i stated the object already in the event part
    I don't need to add the object unless i want to use a method from another object which will never happen!
    Mohammad Hamdy Ghanem
    @VBAndCs
    As it is against logic of event handling
    Or if the method is declared in another class , where i need to supply the class name
    In the last case, i cant imagine that the method is an instance method of the other class as it also defies the logic
    So, the only possible case is anotherclass.method where method is shared
    In short: vb nad c# in all cases must only allow method and otherclass.method
    Mohammad Hamdy Ghanem
    @VBAndCs
    The current behaviour defies logic.
    Adam Speight
    @AdamSpeight2008
    @CyrusNajmabadi @DualBrain I am just experimenting in my own fork.

    Also considering a Select Case Expression that lowers to Inline If Expression

    Return Select Case operand When condition0
                  Case clauseslist0 When condition1 := result0
                  Case clauseslist1                 := result1
                  Case Else When condition2            := result2
                  Case Else                         := result3
                  Else                                := result4
            End Select

    Example of the Lowering

    Dim temp =     If(condition0,
                If(clauseslist0.InContextOf(operand) AndAlso condition1, result0,     ' Case clauseslist0 When condition1
                If(clauseslist1.InContextOf(operand), result1,                         ' Case clauseslist1
                If(condition2, result2,                                             ' Case Else When condition2
                result3                                                             ' Case Else
                )
                )
                ),
                result4                                                             ' Else
                )
    Return temp
    Cory Smith
    @DualBrain
    To me, the above looks extremely messy and is code I'm not sure I would ever want to write... the main reason being that I'd have to spend too much time diagnosing/discovering what it was that I did when I returned to it later in order to maintain it. Additionally, I don't see any benefit of using := over return which removes the need of having the select nested within the return.
    Adam Speight
    @AdamSpeight2008
    The examples are just abstract hand-wavy overview of the Select Case structure, and its lowering.
    Making it a specific example would obscure the specific aspect of the lowing, within the noise of transformations for the actual checks. Why I am using := rather than return as is similar to existing syntax of named arguments. This indicate the partial result of this sub-expression, and not the return value of the function.
    Dim sign = $"{NameOf(value) is {
             ( Select Case value
                          Case Is > 0
                          := "Positive"
                          Case Is = 0
                          := "Zero"
                          Case Is < 0
                          := "Negative"
                          Case Else
                          := Throw New Exception("Should be impossible to get here in my analysis.")
                   End Select
                 ) }"
    Dim sign = $"{NameOf(value) is { If(value > 0, "Positive", If(value = 0, "Zero", If( value<0, "Negative", Throw New Exception("Should be impossible to get here in my analysis.") ))) }"
    Adam Speight
    @AdamSpeight2008
    Same could be said of switch expression and pattern matching in csharp.
    Cory Smith
    @DualBrain

    Although I see where you are going with this, I still feel that I'd prefer to write it "long hand" if for nothing more than clarity sake. Once we have too many symbols floating around, the intent of what the developer is trying to do (IMO) seems to get lost in the noise.

    Dim sign = "Positive"
    Select Case value
       Case > 0: sign="Positive"
       Case = 0: sign="Zero"
       Case < 0: sign="Negative" 
       Case Else: Throw New Exception("Should be impossible to get here in my analysis.")
     End Select

    or

    Dim sign="Zero"
    Select Case value
         Case > 0: sign = "Positive"
         Case < 0: sign = "Negative"
         Case Else ' Already determined
     End Select

    To me the second example (above) is easier to read making it easier to maintain. I also (based on looking at this very little) feel that it is easier to maintain/expand/adjust later. This, of course, could just be a case of me being used to doing it this way; so I'll have to admit that may be influencing my take on this.

    As for the := there does seem to be something that could create a bit of a parsing issue since a : already means something; I'm sure that could be dealt with... but it is something that would have to be considered.

    I suppose I just feel that having an "inline" Select Case is trying to force something into a position where there may be a better option. I recall from "ancient" history that there used to be something similar to:

    ON value GOTO 100, 200, 300

    There was also a "shorthand" version of IF

     IF X = 50 GOTO 100: GOTO 200

    So this begs the question of whether or not there could be a different syntax to accomplish this... such as:

    If {expression_list} Return {return_list}

    So it could be something like...

    If {value < 0, value = 0, value > 0} Return {"Negative", "Zero", "Positive"}
    
    If {value, Not value} Return {"True", "False"}

    The expression list and the return list would need to, of course, match in length other an compiler error would occur.

    I'm not saying that this is something that should be done... I just feel that forcing a Select Case into this doesn't feel like the way to go.

    Mohammad Hamdy Ghanem
    @VBAndCs
    Why doesn't late binding work with ecents?
    VisualElement.PreviewMouseLeftButtonDown
    I use VisualElement as object but still get error that PreviewMouseLeftButtonDown doesn't belong to it.
    The issue here is that I want to handle events of controls and canvas in wpf, but the common rout between them is FrameworkElement which doesn't contain ,any of the events I want to handle (despite Controls and Canvas have them all)
    So, it seems there is no way to write a generic code to handle both.
    The last fall back is to use late binding, but it doesn't work for events! Why?
    I made sure to turn off vb options but nothing changes.
    CyrusNajmabadi
    @CyrusNajmabadi
    what's an 'ecents'?
    Mohammad Hamdy Ghanem
    @VBAndCs
    events
    CyrusNajmabadi
    @CyrusNajmabadi
    ah
    Mohammad Hamdy Ghanem
    @VBAndCs
    :)
    CyrusNajmabadi
    @CyrusNajmabadi
    not sure. does the VB spec allow for late bound events?
    Mohammad Hamdy Ghanem
    @VBAndCs
    I have no idea
    CyrusNajmabadi
    @CyrusNajmabadi
    might be by design. i've never tried late bound events
    Mohammad Hamdy Ghanem
    @VBAndCs
    I solved the issue as it is related to MouseDoubleClick (in my code) and rest of events works fine with frameworkElement , so I used MouseLeftDown instead and checked for e.ClickCount
    But still strange not to have late binding with events in Addhandler statement
    John Moreno
    @jrmoreno1
    What does your addhandler code look like. You should be casting to the right type and then doing it
    Jeff Bowman
    @InteXX
    Weren't you working on a port of Microsoft.VisualBasic to .NET Standard? I've been looking here, but I haven't found anything yet. | @DualBrain
    Cory Smith
    @DualBrain
    @InteXX Yes... you can find it at https://github.com/DualBrain/Community.VisualBasic
    Jeff Bowman
    @InteXX
    Perfect, thank you very much. It looks pretty good... you obviously have done a lot of work on it. | @DualBrain
    Cory Smith
    @DualBrain
    @InteXX If you find anything that doesn't work (or is lacking), please let me know.
    pjbdigitalservices
    @pjbdigitalservices
    @DualBrain Thank you so much for everything you do to support the VB Community. I have been a long time reader of this thread but not contributed before. I code in VB every day. Mostly VB.Net but also VBA and VBScript. When I want to get stuff done - fast - I always turn to VB. It worries me that one day MS will pull the plug and many years of custom solutions will become obsolete but until then I am very happy in VB. I have looked at alternative languages - C++, Go, Python, Javascript, Typescript (which I like), C#, but none of them feel as nice as VB. Maybe it is just that I am (and always have been) a VB guy so some of their (language design) ideas feel a little strange.
    Cory Smith
    @DualBrain
    @pjbdigitalservices Thanks! As for any worries about the future of VB... I have great confidence that Microsoft isn't going to outright abandon VB; I also expect that improvements will still take place. On the other hand, even if such a thing were to occur... it being open-source using the MIT license, I'm not too worried. ๐Ÿ˜‰With that out of the way, the evidence is strong that Microsoft is truly continuing to support (and invest heavily) in VB; the reality is that they aren't going to do "everything" "everyone" wants, so many people are upset that what they want Microsoft to focus on (re: VB and other technologies) isn't what Microsoft feels they should focus on. For example, right now that major focus re: VB is on Windows Forms. A ton of work is taking place there and I can't stress enough how much effort it is actually taking to bring VB over to .NET 5+ related to WinForms given that VB has many "enhancements" that other languages simply do not have. What will take place next? Who knows. On another hand, several things have taken place over the past 12 months as they relate to .NET (core) and/or Roslyn to fix issues related to "just VB" and interop with other languages. The evidence is clear that the support and desire to further VB is there from those on the Microsoft side. Now that that has been said, it is also important to remember that there is a general shift in the developer world that requires that we all transition "or die". What I mean by this is that we have to take ownership of some of what it is we want... thus some of the work I've (and several others have) been doing. ๐Ÿ˜Š