TwinBasic

Quote:

---

Originally Posted by VB6 Programming

twinBASIC status update:

twinBASIC Update: April 16, 2023

Highlights include a steady dose of bug fixes and and a brief recap of twinBASIC's standing in slant.co's list of "best BASIC-like programming languages."

https://nolongerset.com/twinbasic-update-april-16-2023/

---

I found this interesting:-

Quote:

---

Amusingly, twinBASIC currently has more recommendations (25) than Visual Basic .NET (23), though I think it's safe to say that says more about the popularity of slant.co than the relative popularity between twinBASIC and VB.NET 😂.

---

TwinBASIC should surpass VB.Net in popularity in general I expect. Microsoft is done with VB.Net so it hasn't seen major updates in years now I believe.

When TwinBASIC gets support for lambda expressions, delegates, type inference, and first class multi-threading(No need to import things like CreateThread), I would confidently recommend it as a worthy stand-in for VB.Net. It's already pretty worthy with support for generics which allows you to do a lot of interesting things. Also, things like Async/Await and reflection would also be attractive to VB.Net programmers.

If you look at the list, it's not just more popular that VB.NET, it appears to be ranked above VB6. That brings up the question of what the list is really about. TB seems like it is a replacement for VB6, and will be an improvement on it. Lots, if not all, of the other offerings on that list are not so compatible with VB6 source code, and many are not at all compatible. At that point, what does BASIC-like really mean?

If all the list is showing are those that exhibit some syntactical similarities to BASIC, then Java would count as C-like, even though the resemblance is only superficial.

The list seems a bit contrived, to me. It seems like it is listing, apples and things that look like apples in some ways, like peaches (they're both tree fruits), strawberries (both fruits, and both red), and fire trucks (they're both red).

Hmmmm.....I see what you're saying but I also think you might be underestimating the importance of superficial resemblance to BASIC programmers. I mean just scroll back a few pages in this very thread and you'd find something akin to world war 3 and what was it about, the += operator being "un-BASIC-like". For some reason syntax is a huge deal in our community. We tend not to hesitate to classify something as a BASIC-like language when it shares even the most superficial syntax elements with traditional flavors of BASIC.

I guess the point I'm making is that it may seem contrived to you and I but the community at large seem to all know what it means for a language to be considered a form of BASIC.

Wasn't familiar with 'lamda expressions'... looked them up and it's like c/c++ #define but even less readable and even harder to follow, while being less powerful. This is a popular feature?

I'd rather have a direct equivalent of define.

And type inference? VB classic is bad enough with that with everything defaulting to variants... being strongly typed is one of the pluses of BASIC imo, we don't need to be making it even more weakly typed than implicitly typed variants.

Generics do look interesting; would like to see more real world examples of them in tB, don't entirely get it yet.

Quote:

---

Originally Posted by fafalone

Wasn't familiar with 'lamda expressions'... looked them up and it's like c/c++ #define but even less readable and even harder to follow, while being less powerful. This is a popular feature?

I'd rather have a direct equivalent of define.

---

Not sure how you came to the conclusion that a lambda is similar to a c/c++ define, IIRC define allows you to declare a macro that is expanded my the pre-processor. A lambda is more like an anonymous method, it is still a full method just one that is typically written inline. They are not the same as a Macro in C/C++.

Quote:

---

Originally Posted by fafalone

And type inference? VB classic is bad enough with that with everything defaulting to variants... being strongly typed is one of the pluses of BASIC imo, we don't need to be making it even more weakly typed than implicitly typed variants.

---

Type inference is strongly typed, it just that the compiler figures out the type from the original assignment. e.g. in the following code the variable x is strongly typed as an Integer, trying to assign a string results in a compiler error. That code is just as strongly typed as if I had declared x as being an integer explicitly.

Code:

---

option infer on
option strict on

Imports System
                               
Public Module Module1
        Public Sub Main()
                dim x = 100
                x = "test"
        End Sub
End Module

---

I'd add that type inference really comes in handy when you have monstrosities like this:-

Code:

---

Dim dict As Dictionary(Of String, Integer) = New Dictionary(Of String, Integer) From {{"John", 90}, {"Mary", 25}}

---

That code is redundant. Type inference allows you to reduce it to this:-

Code:

---

Dim dict = New Dictionary(Of String, Integer) From {{"John", 90}, {"Mary", 25}}

---

Type interference is one of those things I've come to rely on and I'm unwilling to live without. It makes for so much less typing, I even use it for simpler cases like what PD showed above.

I would also like to add that this I believe type inference in strongly typed languages like C# and VB.Net was inspired by the immense popularity of "duck typing" languages like Python and JavaScript. Type inference is a core part of how these languages work and contributes in part to their popularity. It allows you to eliminate unnecessary boilerplate without sacrificing readability.

Quote:

---

Originally Posted by fafalone

Wasn't familiar with 'lamda expressions'... looked them up and it's like c/c++ #define but even less readable and even harder to follow, while being less powerful. This is a popular feature?

---

No. Like PD says it's basically an anonymous method and this is a big deal and I mean huge. I could probably write a whole essay on the this alone. Lamdas unlock an entire universe of possibilities in a language.

Just to give you a glimpse. You have an array of data. To keep things simple, lets just use simple numbers:-

Code:

---

    Dim numbers(0 To 9) As Integer
   
    numbers(0) = 10
    numbers(1) = 15
    numbers(2) = 200
    numbers(3) = 50
    numbers(4) = 25
    numbers(5) = 90
    numbers(6) = 23
    numbers(7) = 78
    numbers(8) = 1000
    numbers(9) = 2000


---

You want to run different filters through that list. The old school way of doing it would look something like this in VB6:-

Code:

---

    Dim numbers(0 To 9) As Integer
   
    numbers(0) = 10
    numbers(1) = 15
    numbers(2) = 200
    numbers(3) = 50
    numbers(4) = 25
    numbers(5) = 90
    numbers(6) = 23
    numbers(7) = 78
    numbers(8) = 1000
    numbers(9) = 2000
   
    Dim I As Long
    Dim x As Long
    Dim temp() As String
   
    ReDim temp(0)
   
    x = 0
    For I = LBound(numbers) To UBound(numbers)
        If Not CBool(numbers(I) Mod 2) Then
            ReDim Preserve temp(x)
            temp(x) = CStr(numbers(I))
           
            x = x + 1
        End If
    Next
   
    Debug.Print "Even numbers: " & Join(temp, ", ")

    x = 0
    For I = LBound(numbers) To UBound(numbers)
        If Not CBool(numbers(I) Mod 5) Then
            ReDim Preserve temp(x)
            temp(x) = CStr(numbers(I))
           
            x = x + 1
        End If
    Next
   
    Debug.Print "Multiples of five: " & Join(temp, ", ")


    x = 0
    For I = LBound(numbers) To UBound(numbers)
        If numbers(I) > 100 Then
            ReDim Preserve temp(x)
            temp(x) = CStr(numbers(I))
           
            x = x + 1
        End If
    Next
   
    Debug.Print "Greater than 100: " & Join(temp, ", ")


    x = 0
    For I = LBound(numbers) To UBound(numbers)
        If numbers(I) > 100 And Not CBool(numbers(I) Mod 10) Then
            ReDim Preserve temp(x)
            temp(x) = CStr(numbers(I))
           
            x = x + 1
        End If
    Next
   
    Debug.Print "Multiple of 10 greater than 100: " & Join(temp, ", ")



---

The problem with that is that is too much redundancy. We should not need to write that loop repeatedly. With higher order functions this redundancy could be massively reduced quite easily. In VB.Net you could start by defining a filtering delegate like this:-

Code:

---

Public Delegate Function WhereClause(Of T)(ByVal item As T) As Boolean

---

That might look intimidating but it's really not. It's basically a strongly typed function pointer for a generic function that takes 1 parameter of any type.

From there you can define a generic filtering function like this:-

Code:

---

    Public Function Filter(Of T)(ByVal items As T(), ByVal filterFunc As WhereClause(Of T)) As T()
        Dim filteredItems As New List(Of T)

        For Each item In items
            If filterFunc.Invoke(item) Then
                filteredItems.Add(item)
            End If
        Next

        Return filteredItems.ToArray
    End Function


---

The above function takes an array of items and executes the delegate on each item which evaluates them to return True or False. The ones that evaluate to True is saved to a List which in then returned at the end of the function as an array.

With those in place, the original program could be reduced to just this:-

Code:

---

        Dim numbers = {10, 15, 200, 50, 25, 90, 23, 78, 1000, 2000}

        Debug.WriteLine("Even numbers: " & String.Join(", ", Filter(numbers, Function(item) Not CBool(item Mod 2))))
        Debug.WriteLine("Multiples of five: " & String.Join(", ", Filter(numbers, Function(item) Not CBool(item Mod 5))))
        Debug.WriteLine("Greater than 100: " & String.Join(", ", Filter(numbers, Function(item) item > 100)))
        Debug.WriteLine("Multiple of 10 greater than 100: " & String.Join(", ", Filter(numbers, Function(item) item > 100 AndAlso Not CBool(item Mod 10))))


---

The key to this is the lambda expression within the calls to Filter:-

Code:

---

Filter(numbers, Function(item) Not CBool(item Mod 2))

---

The lambda expression is highlighted in red. The Filter function will use that lambda expression to evaluate each item and if it evaluates to True, the item is included in the filtered list.

This example only scratches the surface of what can be done with lambdas, generics etc. Entire programming paradigms are built on these simple features, way too much to go into in a single post.

You could do it more clearly and with the same or fewer lines by having a Filter function which chooses which op to apply based on an enum value (for clarity, or just raw numbers).

ApplyFilter(in(), out(), type)

For lbound to ubound
select case type
case even
filter into out()
etc

Some of these things seem like complexity just for the sake of complexity.

...and that's not what I could consider strongly typed for type inference. It introduces needless issues; we *already* have widespread problems in VB6 codebases because VB6 does that to consts... i.e. Const foo = 100 will be inferred as an Integer, and when foo >= &H8000, that's a negative signed integer, which is usually unexpected and often results in bugs when it's coerced into larger types. tB added a compiler warning for just this specific issue. Now you want more of this? To the point you can't live without it? No, weakening typing further in a way that's prone to bugs is the last thing I'd want to see.

Quote:

---

Originally Posted by fafalone

You could do it more clearly and with the same or fewer lines by having a Filter function which chooses which op to apply based on an enum value (for clarity, or just raw numbers).

ApplyFilter(in(), out(), type)

For lbound to ubound
select case type
case even
filter into out()
etc

Some of these things seem like complexity just for the sake of complexity.

---

That is still very problematic. Now you would be marrying the predicate to the loop. These are separate concerns and should not be coupled together. The loop should have no knowledge of predicates because that's not it's concern. In a large application with filters all over the place you end up with a monstrosity of a Select Case statement for every type of filter used in the entire application, many of which may only be used in a single place. Separating the predicate from the loop allows you to apply the predicate only where it actually means something, which is at the call site. This keeps the Filter function itself lean and flexible. The callsite itself remains lean because you don't have to write the entire loop there, you just call the Filter function and pass it the predicate as a lambda.

Quote:

---

Originally Posted by fafalone

...and that's not what I could consider strongly typed for type inference. It introduces needless issues; we *already* have widespread problems in VB6 codebases because VB6 does that to consts... i.e. Const foo = 100 will be inferred as an Integer, and when foo >= &H8000, that's a negative signed integer, which is usually unexpected and often results in bugs when it's coerced into larger types. tB added a compiler warning for just this specific issue. Now you want more of this? To the point you can't live without it? No, weakening typing further in a way that's prone to bugs is the last thing I'd want to see.

---

I'm not convinced by this argument. Hammers aren't illegal just because some people might misuse it and hurt themselves. If people are making these kinds of errors the onus is on them to use the language properly.

I would also add that because this behavior is not consistent in VB6 it leads to these kinds of problems. It uses type inference for constants but defaults to Variants for non-constants, of course that will confuse people.

Also note that type inference could be added to TwinBASIC without breaking backward-compatibility. We could actually toggle it in VB.Net with Option Infer On/Off. It's on by default project wide. TwinBASIC could also add Option Infer for people that may want to opt-in to it.

In C# you can opt-in on a line by line basis by declaring variables with the var keyword.

Code:

---

var i = 100;

---

The above declares i using type inference. You could opt to not use it if you wanted:-

Code:

---

int i = 100;

---

Quote:

---

Originally Posted by fafalone

You could do it more clearly and with the same or fewer lines by having a Filter function which chooses which op to apply based on an enum value (for clarity, or just raw numbers).

ApplyFilter(in(), out(), type)

For lbound to ubound
select case type
case even
filter into out()
etc

---

That would require the enum and matching ApplyFilter function to have every single filter used by your application predefined, every time you need a new filter you have to modify the existing enum and the ApplyFilter function; that assumes this is even possible - what if the ApplyFilter function is in a precompiled library? Lambdas give you an easy way of providing these inline methods, and when coupled with Generics and delegates, give you a lot more flexibility than your suggestion of a single (potentially massive) select case approach could achieve.

For dynamically interpreted stuff, the VBScript-interpreter works decently enough (as a VB6-companion):

Code:

---

Private Sub Form_Load()
  Dim Arr: Arr = Array(10, 15, 200, 50, 25, 90, 23, 78, 1000, 2000)
 
  Debug.Print "Even numbers: "; Join(Filter(Arr, "Item Mod 2 = 0"), ",")
  Debug.Print "Multiples of five: "; Join(Filter(Arr, "Item Mod 5 = 0"), ",")
  Debug.Print "Greater than 100: "; Join(Filter(Arr, "Item > 100"), ",")
  Debug.Print "Multiple of 10 greater than 100: "; Join(Filter(Arr, "Item > 100 AND Item Mod 10=0"), ",")
End Sub

Function Filter(Arr, Expr As String)
  Dim i As Long, j As Long, SC
 
  Filter = Array(): ReDim Res(UBound(Arr))
  Set SC = CreateObject("ScriptControl")
      SC.Language = "VBScript": SC.AddCode "Public Item"
 
  For i = 0 To UBound(Arr)
    SC.CodeObject.Item = Arr(i)
    If SC.Eval(Expr) Then Res(j) = Arr(i): j = j + 1
  Next
  If j Then ReDim Preserve Res(j - 1): Filter = Res
End Function

---

Olaf

Quote:

---

Originally Posted by Niya

I'd add that type inference really comes in handy when you have monstrosities like this:-

Code:

---

Dim dict As Dictionary(Of String, Integer) = New Dictionary(Of String, Integer) From {{"John", 90}, {"Mary", 25}}

---

---

The above code really scares me.

Quote:

---

Originally Posted by Niya

That code is redundant. Type inference allows you to reduce it to this:-

Code:

---

Dim dict = New Dictionary(Of String, Integer) From {{"John", 90}, {"Mary", 25}}

---

---

Yes, apparently the above code is a lot better.

Generics always give me a headache when translating some C# and VB.NET code into VB6. Here's my translation of generics in VB6:

Code:

---

    Dim AL As cArrayListEx
    Set AL = New_ArrayListEx(vbString, vbLong)

    AL.Add "John", 90
    AL.Add "Mary", 25

---

Olaf always laughed at me for being able to copy other people's source code. In fact, when I use RC6, I often need to do a lot of repackaging of RC6 classes to meet my needs.

For me, the ideal generics would look like this:

Code:

---

    Dim AL = New List(vbString, vbLong)
    AL.Add "John", 90, "Mary", 25

---

Quote:

---

Originally Posted by SearchingDataOnly

For me, the ideal generics would look like this:

Code:

---

    Dim AL = New List(vbString, vbLong)
    AL.Add "John", 90, "Mary", 25

---

---

Why vbLong and vbString? Why not just Long and String instead?

Also how would your syntax allow you to specify both the generic type and any parameters the constructor takes?

Quote:

---

Originally Posted by PlausiblyDamp

Why vbLong and vbString? Why not just Long and String instead?

---

vbString and vbLong are used for VB6 compatibility. That is, vbString and vbLong are variables (or constants), not types.

Quote:

---

Originally Posted by PlausiblyDamp

Also how would your syntax allow you to specify both the generic type and any parameters the constructor takes?

---

The question you pointed out is very reasonable. Maybe I should write like this:

Code:

---

    Dim AL = New_List(vbString, vbLong)

---

Also, the constructor I envision looks like this:

cArrayListEx

Code:

---

Friend Sub Constructor(vType As VbVarType, vTagType As VbVarType, ParamArray P() As Variant

End Sub

---

Quote:

---

Originally Posted by SearchingDataOnly

vbString and vbLong are used for VB6 compatibility. That is, vbString and vbLong are variables (or constants), not types.

---

That would mean you could only use types that had a constant defined rather than any type, how would you deal with custom classes etc. in your approach?

Quote:

---

Originally Posted by SearchingDataOnly

The question you pointed out is very reasonable. Maybe I should write like this:

Code:

---

    Dim AL = New_List(vbString, vbLong)

---

Also, the constructor I envision looks like this:

cArrayListEx

Code:

---

Friend Sub Constructor(vType As VbVarType, vTagType As VbVarType, ParamArray P() As Variant

End Sub

---

---

IMHO that would confuse the actual parameters with the type parameters though. Just looking at your suggested Constructor again... Would you expect the constructor to use the vType and vTagType parameters or would this be done by the compiler / runtime? I suspect I am not quite understanding the approach your Constructor is taking.

Quote:

---

Originally Posted by PlausiblyDamp

That would mean you could only use types that had a constant defined rather than any type, how would you deal with custom classes etc. in your approach?

---

Yes, it's a lot of trouble and I don't have a good solution at the moment. My initial thoughts are this:
All custom types (can only be classes, not UDT/Structure) are registered in my system as strings, for example:

"Of____MyClass1" represents class MyClass1
"Of____MyClass2" represents class MyClass2

But in practice, My transpiler interpret MyClass1 and MyClass2 as Object types

Quote:

---

Originally Posted by PlausiblyDamp

IMHO that would confuse the actual parameters with the type parameters though.

---

Yes, but the addition of type parameters complicates things.

Quote:

---

Originally Posted by PlausiblyDamp

Just looking at your suggested Constructor again... Would you expect the constructor to use the vType and vTagType parameters or would this be done by the compiler / runtime? I suspect I am not quite understanding the approach your Constructor is taking.

---

This constructor function of mine is not really a constructor, my transpiler automatically generates a New_List function based on the Constructor function.

Quote:

---

Originally Posted by Schmidt

For dynamically interpreted stuff, the VBScript-interpreter works decently enough (as a VB6-companion):

Code:

---

Private Sub Form_Load()
  Dim Arr: Arr = Array(10, 15, 200, 50, 25, 90, 23, 78, 1000, 2000)
 
  Debug.Print "Even numbers: "; Join(Filter(Arr, "Item Mod 2 = 0"), ",")
  Debug.Print "Multiples of five: "; Join(Filter(Arr, "Item Mod 5 = 0"), ",")
  Debug.Print "Greater than 100: "; Join(Filter(Arr, "Item > 100"), ",")
  Debug.Print "Multiple of 10 greater than 100: "; Join(Filter(Arr, "Item > 100 AND Item Mod 10=0"), ",")
End Sub

Function Filter(Arr, Expr As String)
  Dim i As Long, j As Long, SC
 
  Filter = Array(): ReDim Res(UBound(Arr))
  Set SC = CreateObject("ScriptControl")
      SC.Language = "VBScript": SC.AddCode "Public Item"
 
  For i = 0 To UBound(Arr)
    SC.CodeObject.Item = Arr(i)
    If SC.Eval(Expr) Then Res(j) = Arr(i): j = j + 1
  Next
  If j Then ReDim Preserve Res(j - 1): Filter = Res
End Function

---

Olaf

---

Yes, VB6 and VBScript are an excellent pair. But because Microsoft abandoned VB6, the development of VBScript was also at a standstill, otherwise VBScript could have developed into a scripting language as powerful as JavaScript and Python.

Maybe Wayne will find time to develop a TwinScript

Quote:

---

Originally Posted by SearchingDataOnly

Yes, it's a lot of trouble and I don't have a good solution at the moment. My initial thoughts are this:
All custom types (can only be classes, not UDT/Structure) are registered in my system as strings, for example:

"Of____MyClass1" represents class MyClass1
"Of____MyClass2" represents class MyClass2

---

If you are happy with a very limited version of generics that only works with built-in types I suppose using predefined constants might work, I am not seeing how your syntax of making the types mangled strings that look like parameters to a constructor, but aren't really part of the constructor would be any clearer then the VB.Net syntax.

At least the VB.Net syntax obviously separates out the types from the constructor parameters, think of the potential confusion if you have overloaded constructors - your approach would require these type parameters to be present on every overload.

Quote:

---

Originally Posted by SearchingDataOnly

Yes, but the addition of type parameters complicates things.

---

I prefer the C# syntax anyway, but I don't find the VB.Net syntax overly confusing or complicated to use - I would find it more confusing to see a constructor take 5 parameters but apparently only 2 of them are actual parameters and the other 3 are types parameters, but at a glance it just looks like 5 parameters.....

Also if you had code like your example

Code:

---

Friend Sub Constructor(vType As VbVarType, vTagType As VbVarType, ParamArray P() As Variant

End Sub

---

How could you declare parameter types (such as P() as Variant) to use one of the generic types, e.g. in VB.Net I can do

Code:

---

Public Class Test(Of T)

    Dim _val As T
    Public Sub New(input As T)
        _val = input
    End Sub

    Public Function Dummy() As T
        Return _val
    End Function
End Class

---

I can create an instance of this and use it like

Code:

---

        Dim t1 = New Test(Of Integer)(100)
        Dim x = t1.Dummy()

---

How could I declare the type e.g. integer and define a parameter of this type generically using your syntax?

Quote:

---

Originally Posted by Schmidt

For dynamically interpreted stuff, the VBScript-interpreter works decently enough (as a VB6-companion):

Code:

---

Private Sub Form_Load()
  Dim Arr: Arr = Array(10, 15, 200, 50, 25, 90, 23, 78, 1000, 2000)
 
  Debug.Print "Even numbers: "; Join(Filter(Arr, "Item Mod 2 = 0"), ",")
  Debug.Print "Multiples of five: "; Join(Filter(Arr, "Item Mod 5 = 0"), ",")
  Debug.Print "Greater than 100: "; Join(Filter(Arr, "Item > 100"), ",")
  Debug.Print "Multiple of 10 greater than 100: "; Join(Filter(Arr, "Item > 100 AND Item Mod 10=0"), ",")
End Sub

Function Filter(Arr, Expr As String)
  Dim i As Long, j As Long, SC
 
  Filter = Array(): ReDim Res(UBound(Arr))
  Set SC = CreateObject("ScriptControl")
      SC.Language = "VBScript": SC.AddCode "Public Item"
 
  For i = 0 To UBound(Arr)
    SC.CodeObject.Item = Arr(i)
    If SC.Eval(Expr) Then Res(j) = Arr(i): j = j + 1
  Next
  If j Then ReDim Preserve Res(j - 1): Filter = Res
End Function

---

Olaf

---

I hadn't even considered something like that, I am still surprised at exactly what can be done with VB6.

I am not sure if I would be happy to lose the type-safety and instellisense support lambdas provide (that also includes the JIT being to optimise them etc) to use embedded strings etc. to try and achieve the same result.

Quote:

---

Originally Posted by SearchingDataOnly

otherwise VBScript could have developed into a scripting language as powerful as JavaScript and Python.
Maybe Wayne will find time to develop a TwinScript

---

Good idea. Let us hope.

Quote:

---

Originally Posted by Schmidt

For dynamically interpreted stuff, the VBScript-interpreter works decently enough (as a VB6-companion):

Code:

---

Private Sub Form_Load()
  Dim Arr: Arr = Array(10, 15, 200, 50, 25, 90, 23, 78, 1000, 2000)
 
  Debug.Print "Even numbers: "; Join(Filter(Arr, "Item Mod 2 = 0"), ",")
  Debug.Print "Multiples of five: "; Join(Filter(Arr, "Item Mod 5 = 0"), ",")
  Debug.Print "Greater than 100: "; Join(Filter(Arr, "Item > 100"), ",")
  Debug.Print "Multiple of 10 greater than 100: "; Join(Filter(Arr, "Item > 100 AND Item Mod 10=0"), ",")
End Sub

Function Filter(Arr, Expr As String)
  Dim i As Long, j As Long, SC
 
  Filter = Array(): ReDim Res(UBound(Arr))
  Set SC = CreateObject("ScriptControl")
      SC.Language = "VBScript": SC.AddCode "Public Item"
 
  For i = 0 To UBound(Arr)
    SC.CodeObject.Item = Arr(i)
    If SC.Eval(Expr) Then Res(j) = Arr(i): j = j + 1
  Next
  If j Then ReDim Preserve Res(j - 1): Filter = Res
End Function

---

Olaf

---

This is actually pretty clever and it's as close as you can get to using lambdas in VB6.

Quote:

---

Originally Posted by PlausiblyDamp

I hadn't even considered something like that, I am still surprised at exactly what can be done with VB6.

I am not sure if I would be happy to lose the type-safety and instellisense support lambdas provide (that also includes the JIT being to optimise them etc) to use embedded strings etc. to try and achieve the same result.

---

True. I also wonder if it could receive object references from the host so you could do things like this:-

Code:

---

        Dim points = {New Point(10, 100), New Point(23.6, 70), New Point(30, 90)}

        Dim filteredPoints = Filter(points, Function(p) p.X > 10)

---

Quote:

---

Originally Posted by SearchingDataOnly

Maybe Wayne will find time to develop a TwinScript

---

There's no need for that. For one thing, TwinBASIC will be able to access VBScript same as VB6. A better option would be to simply expose the compiler through a class in TwinBASIC itself. In .Net we have access to the compilers from code itself. I'll do a .Net example of Olaf's code in a follow up post to show how this looks.

I thought TB already supports lamdas (and generics) though not sure what exactly is the syntax for calling these. Probably the same as in VB.Net so someone more knowledgable might help here.

cheers,
</wqw>

It supports generics but not lambdas.

---

Quote:

---

I'm not convinced by this argument. Hammers aren't illegal just because some people might misuse it and hurt themselves. If people are making these kinds of errors the onus is on them to use the language properly.

---

You're talking to the guy who requested the 'override entry point' and 'run in kernel mode' options tB now supports, and wants inline asm and pointer aliases, so this is hardly about shying away from letting people shoot themselves in the foot. But it has to be a net improvement on the language. Creating easy bugs and raising the learning curve because someone is too lazy to type theirs vars but isn't satisfied with variants... it's not worth the tradeoff.

Quote:

---

Originally Posted by fafalone

It supports generics but not lambdas.
too lazy to type theirs vars but isn't satisfied with variants... it's not worth the tradeoff.

---

Two completely different things, variants are nothing to do with not wanting to type variable types out in full.

Code:

---

' Explicit strongly typed name as string
Dim name as string = "Guest"
name = 1  'would be a compiler error

'With option infer on, this is an implicit strongly typed
Dim name = "Guest"
name = 1 'would still be a compiler error

'with variant as a default type
Dim name = "Guest"
name = 1  'no error at compile time.

---

The variant usage is a very different behaviour to implicit typing.

Implicit typing is really useful when the variable type is a complex, and there is obvious redundancy in the declaration - Niya gave a good example of this back in post #1446 https://www.vbforums.com/showthread....=1#post5602140

Quote:

---

Originally Posted by Niya

... I also wonder if it could receive object references from the host so you could do things like this:-

Code:

---

        Dim points = {New Point(10, 100), New Point(23.6, 70), New Point(30, 90)}

        Dim filteredPoints = Filter(points, Function(p) p.X > 10)

---

---

Sure, it's not *that* much more effort, to make the little Filter-Function accept Objects as well -
using a Class, named cPoint:

Code:

---

Option Explicit

Public x As Double, y As Double

---

And the Form-Code again:

Code:

---

Option Explicit

Private Declare Function VariantCopy Lib "oleaut32" (Dst, Src) As Long

Private Sub Form_Load()
  Dim Arr: Arr = Array(10, 15, 200, 50, 25, 90, 23, 78, 1000, 2000)
  Debug.Print "Even numbers: "; Join(Filter(Arr, "Item Mod 2 = 0"), ",")
  Debug.Print "Multiples of five: "; Join(Filter(Arr, "Item Mod 5 = 0"), ",")
  Debug.Print "Greater than 100: "; Join(Filter(Arr, "Item > 100"), ",")
  Debug.Print "Multiple of 10 greater than 100: "; Join(Filter(Arr, "Item > 100 AND Item Mod 10=0"), ",")
 
  Arr = Array(NewP(10, 100), NewP(23.6, 70), NewP(30, 90))
  Dim P, Res: Res = Filter(Arr, "Item.x > 10")
  For Each P In Res: Debug.Print P.x, P.y: Next
End Sub

Function Filter(Arr, Expr As String)
  Dim i As Long, j As Long, SC
 
  Filter = Array(): ReDim Res(UBound(Arr))
  Set SC = CreateObject("ScriptControl")
      SC.Language = "VBScript"
      SC.AddCode "Function Chk(ByVal Item): Chk=CBool(" & Expr & "):End Function"
 
  For i = 0 To UBound(Arr)
    If SC.CodeObject.Chk(Arr(i)) Then VariantCopy Res(j), Arr(i): j = j + 1
  Next
  If j Then ReDim Preserve Res(j - 1): Filter = Res
End Function

Function NewP(ByVal x#, ByVal y#) As cPoint
  Set NewP = New cPoint: NewP.x = x: NewP.y = y
End Function

---

Olaf

Quote:

---

Originally Posted by PlausiblyDamp

Two completely different things, variants are nothing to do with not wanting to type variable types out in full.

Code:

---

' Explicit strongly typed name as string
Dim name as string = "Guest"
name = 1  'would be a compiler error

'With option infer on, this is an implicit strongly typed
Dim name = "Guest"
name = 1 'would still be a compiler error

'with variant as a default type
Dim name = "Guest"
name = 1  'no error at compile time.

---

The variant usage is a very different behaviour to implicit typing.

Implicit typing is really useful when the variable type is a complex, and there is obvious redundancy in the declaration - Niya gave a good example of this back in post #1446 https://www.vbforums.com/showthread....=1#post5602140

---

Niya's example still have all the problems of multiple types it could match, and nothing he or you have said rebuts this being about not wanting to write out types.

And they're not entirely different things, implicit variants *are* type inference... Not only variant itself, but VT_I4 or VT_BSTR etc.

Quote:

---

Originally Posted by fafalone

Niya's example still have all the problems of multiple types it could match

---

Absolutely not, in Niya's example he is assigning one possible type and that type is Dictionary(Of String, Integer) there is no ambiguity whatsoever in that code. If you can explain what other types it could possibly be then I am prepared to stand corrected.

Quote:

---

Originally Posted by fafalone

, and nothing he or you have said rebuts this being about not wanting to write out types.

---

not wanting to do something is not the same as being too lazy, there are times when the inferred syntax is shorter and easier to read - those are the times to use it.

Quote:

---

Originally Posted by fafalone

And they're not entirely different things, implicit variants *are* type inference... Not only variant itself, but VT_I4 or VT_BSTR etc.

---

From a language type safety point of view the fact a Variant can change its type is completely different to the strongly typed variable in the example I gave. The fact a variant may be a VT_I4 or VT_BSTR internally makes no difference to the type safety of the language itself. In the example I gave I could assign a string, and then an integer to the same variable without the compiler picking this up as an error.

Inferred typing is all about strongly, statically typed variables - Variants effectively allow their type to change, these are completely different from each other when you consider the behaviour of the types at the language level, irrespective of the internal formats.

I think fafalone is having trouble relating to our feelings on type inference. Perhaps he might better understand us if we used a similar situation but one with which he has more familiarity.

I've seen VB6 programmers do this:-

Code:

---

Dim myLong&

---

Instead of:-

Code:

---

Dim myLong As Long

---

Olaf himself often declares Variant variables in his code like this:-

Code:

---

Dim myVar

---

Instead of:-

Code:

---

Dim myVar As Variant

---

No one would accuse people doing these things of being lazy. They prefer doing things this way and it can even be argued that it's better since it's more terse yes still readable.

Type inference allows us an additional shorthand in VB.Net. We can opt to do this:-

Code:

---

Dim p As Point = New Point(100, 200)

---

Or this:-

Code:

---

Dim p = New Point(100, 200)

---

It's shorter while having exactly the same amount of information, no different to any other shorthand.

Having function that returns PersonInfo object:

VB.NET Code:

public class PersonInfo
  public property Id as Guid
  public property Name as String
  public property Age as String
  public property Login as String
  public property Password as String
  public property ...
end class
 
public function GetPerson(id as Guid) as PersonInfo
  ...
end function

and code that uses it:

VB.NET Code:

Dim user = mng.GetPerson(id)

The variable user will be of type PersonInfo. But we refactor the code and want to return another object - PersonPublicInfo which contains only the public visible information without the private (and more sensitive) login and password:

VB.NET Code:

public class PersonPublicInfo
  public property Id as Guid
  public property Name as String
  public property Age as String
end class

Change the signature of the function and add another function that gets the sensitive info:

VB.NET Code:

public function GetPerson(id as Guid) as PersonPublicInfo
  ...
end function
 
public function GetPersonLoginDetails(id as Guid) as PersonInfo
  ...
end function

The call to get the info is still the same:

VB.NET Code:

Dim user = mng.GetPerson(id)

The result is that user variable will now infer the type that is returned by GetPerson and with the refactoring of GetPerson function now it is PersonPublicInfo.

Such type of refactoring is very common in larger projects where the returned type is changed with requirements change. With explicit types the refactoring will be:

from

VB.NET Code:

Dim user As PersonInfo = mng.GetPerson(id)

to

VB.NET Code:

Dim user As PersonPublicInfo = mng.GetPerson(id)

Which increases refactor time and introduces compilation errors that are slowing down the development.

If we use Variant for the user, then we loose the type checks and introduce runtime errors if the code is using properties from the old object (PersonInfo) that don't exist in the new object (PersonPublicInfo).

Think of large scale applications with hundreds of projects where refactoring of single project may affect multiple other projects that reference the changed one and everywhere is used the explicit type... Well, for single VB6 project it may not be an issue :-)

Wayne had better get a new beta version out soon, this thread is going off into the weeds.

Quote:

---

Originally Posted by Shaggy Hiker

Wayne had better get a new beta version out soon, this thread is going off into the weeds.

---

It doesn't matter, occasionally growing weeds does not affect the beauty of the yard.

We occasionally talk about topics that are not related to tB (but seem to be related), but we will soon stop.

Quote:

---

Originally Posted by PlausiblyDamp

If you are happy with a very limited version of generics that only works with built-in types I suppose using predefined constants might work, I am not seeing how your syntax of making the types mangled strings that look like parameters to a constructor, but aren't really part of the constructor would be any clearer then the VB.Net syntax.

At least the VB.Net syntax obviously separates out the types from the constructor parameters, think of the potential confusion if you have overloaded constructors - your approach would require these type parameters to be present on every overload.


I prefer the C# syntax anyway, but I don't find the VB.Net syntax overly confusing or complicated to use - I would find it more confusing to see a constructor take 5 parameters but apparently only 2 of them are actual parameters and the other 3 are types parameters, but at a glance it just looks like 5 parameters.....

Also if you had code like your example

Code:

---

Friend Sub Constructor(vType As VbVarType, vTagType As VbVarType, ParamArray P() As Variant

End Sub

---

How could you declare parameter types (such as P() as Variant) to use one of the generic types, e.g. in VB.Net I can do

Code:

---

Public Class Test(Of T)

    Dim _val As T
    Public Sub New(input As T)
        _val = input
    End Sub

    Public Function Dummy() As T
        Return _val
    End Function
End Class

---

I can create an instance of this and use it like

Code:

---

        Dim t1 = New Test(Of Integer)(100)
        Dim x = t1.Dummy()

---

How could I declare the type e.g. integer and define a parameter of this type generically using your syntax?

---

In the following code, if you add a string to an ArrayList of type vbLong, the system will report an error.

Code:

---

Dim AL As cArrayList
Set AL = New_c.ArrayList(vbLong)

AL.Add 100
AL.Add "Hello"

---

Code:

---

Dim AL As cArrayList
Set AL = New_c.ArrayList(vbLong, "Hello")

---

That is, error handling is controlled internally by the person writing the ArrayList class, not by the compiler.

Quote:

---

Originally Posted by SearchingDataOnly

In the following code, if you add a string to an ArrayList of type vbLong, the system will report an error.

Code:

---

Dim AL As cArrayList
Set AL = New_c.ArrayList(vbLong)

AL.Add 100
AL.Add "Hello"

---

Code:

---

Dim AL As cArrayList
Set AL = New_c.ArrayList(vbLong, "Hello")

---

That is, error handling is controlled internally by the person writing the ArrayList class, not by the compiler.

---

Ahh, that makes sense. I still prefer the compiler support for generics but I can see the potential use for the example you gave, it is a definite step in the right direction compared to VB6's existing collection objects.

Quote:

---

Originally Posted by PlausiblyDamp

Absolutely not, in Niya's example he is assigning one possible type and that type is Dictionary(Of String, Integer) there is no ambiguity whatsoever in that code. If you can explain what other types it could possibly be then I am prepared to stand corrected.

not wanting to do something is not the same as being too lazy, there are times when the inferred syntax is shorter and easier to read - those are the times to use it.



From a language type safety point of view the fact a Variant can change its type is completely different to the strongly typed variable in the example I gave. The fact a variant may be a VT_I4 or VT_BSTR internally makes no difference to the type safety of the language itself. In the example I gave I could assign a string, and then an integer to the same variable without the compiler picking this up as an error.

Inferred typing is all about strongly, statically typed variables - Variants effectively allow their type to change, these are completely different from each other when you consider the behaviour of the types at the language level, irrespective of the internal formats.

---

Well I assumed you were talking about something else, because you're right, there's nothing else it could be: That's not type inference. There's nothing to infer, it's explicitly typed.

And you've entirely missed the point with what I was saying about Variants.

Quote:

---

Originally Posted by Niya

I think fafalone is having trouble relating to our feelings on type inference. Perhaps he might better understand us if we used a similar situation but one with which he has more familiarity.

I've seen VB6 programmers do this:-

Code:

---

Dim myLong&

---

Instead of:-

Code:

---

Dim myLong As Long

---

Olaf himself often declares Variant variables in his code like this:-

Code:

---

Dim myVar

---

Instead of:-

Code:

---

Dim myVar As Variant

---

No one would accuse people doing these things of being lazy. They prefer doing things this way and it can even be argued that it's better since it's more terse yes still readable.

Type inference allows us an additional shorthand in VB.Net. We can opt to do this:-

Code:

---

Dim p As Point = New Point(100, 200)

---

Or this:-

Code:

---

Dim p = New Point(100, 200)

---

It's shorter while having exactly the same amount of information, no different to any other shorthand.

---

When it has the same information, yes, it's more of a style preference than being lazy. But when you're *not* talking about pure style differences, because you're introducing ambiguity, that's different.

Quote:

---

Originally Posted by fafalone

When it has the same information, yes, it's more of a style preference than being lazy. But when you're *not* talking about pure style differences, because you're introducing ambiguity, that's different.

---

Well that's the thing, there is no ambiguity with type inference. When we see something like:-

Code:

---

Dim x = 100

---

We know exactly what type x is because we how the VB.Net compiler behaves. It defaults to a 32 bit Integer. It's no different than a VB6 programmer reading this:-

Code:

---

Dim x

---

And knowing that's a Variant. I don't see how it's ambiguous.

I could even argue that in VB6 Dim x is more ambiguous because of Def[type] A-Z statements but no one complains about that.

I sometimes use type inference when I can't remember what type something returns. Yes, you certainly could call that lazy, but more accurate would be efficient: Hovering over the variable tells me the type, so either I look it up online, or look it up by letting the IDE tell me.

Quote:

---

Originally Posted by Shaggy Hiker

I sometimes use type inference when I can't remember what type something returns.

---

Yea I do that too. In addition, I also do it for cases where I know the return has a ridiculously long name like NetworkInformation. I'm also big on self documenting code so I tend to use ridiculously long names for my types too.

Quote:

---

Originally Posted by Niya

Well that's the thing, there is no ambiguity with type inference. When we see something like:-

Code:

---

Dim x = 100

---

We know exactly what type x is because we how the VB.Net compiler behaves. It defaults to a 32 bit Integer. It's no different than a VB6 programmer reading this:-

Code:

---

Dim x

---

And knowing that's a Variant. I don't see how it's ambiguous.

I could even argue that in VB6 Dim x is more ambiguous because of Def[type] A-Z statements but no one complains about that.

---

So then the behavior of VB.NET is different? Const x = 100 in VB6 type inference rules would make that an Integer (VB6 Integer, 16bit signed). And you know what I meant by ambiguous, that it's not readily apparent and you have to dig into a complex rule set, *just like with VB6 Variant typing or consts*, which have resulted in untold hours running down hard to trace bugs, *because of the ambiguity*, and how unneccessarily easy it makes it for people, especially the beginners and people just trying to make quick tools for their actual work, BASIC is popular with.

Quote:

---

Originally Posted by Niya

I'm also big on self documenting code so I tend to use ridiculously long names for my types too.

---

Dear god, a prayer for any poor soul who has to maintain the code of their predecessor who thought "self documenting code" was a real thing.

Attachment 187436

Quote:

---

Originally Posted by fafalone

Dear god, a prayer for any poor soul who has to maintain the code of their predecessor who thought "self documenting code" was a real thing.

---

It is a real thing. Here's some actual code from a small utility application used by a couple clients:-

Code:

---

Imports System.Globalization
Imports System.Windows.Markup

Public Class ItemDisplayLayoutsToBooleanConverter
    Inherits MarkupExtension
    Implements IValueConverter

    Public Sub New()

    End Sub

    Public Sub New(ByVal curOption As ItemDisplayLayouts)
        Me.CurrentOption = curOption
    End Sub

    Public Property CurrentOption As ItemDisplayLayouts

    Public Function Convert(value As Object, targetType As Type, parameter As Object, culture As CultureInfo) As Object Implements IValueConverter.Convert

        If TypeOf value Is ItemDisplayLayouts Then
            Dim dataSourceValue As ItemDisplayLayouts = DirectCast(value, ItemDisplayLayouts)

            If dataSourceValue = Me.CurrentOption Then
                Return True
            End If
        End If

        Return False

    End Function

    Public Function ConvertBack(value As Object, targetType As Type, parameter As Object, culture As CultureInfo) As Object Implements IValueConverter.ConvertBack

        If TypeOf value Is Boolean Then
            Dim b As Boolean = DirectCast(value, Boolean)

            If b Then Return Me.CurrentOption

        End If

        Return Binding.DoNothing
    End Function

    Public Overrides Function ProvideValue(serviceProvider As IServiceProvider) As Object
        Return Me
    End Function
End Class



---

There's no way I could read that code 15 years from now and not understand what it does and that's partly because I wasn't being stingy about naming things. I like nice long descriptive names.

Quote:

---

Originally Posted by fafalone

So then the behavior of VB.NET is different? Const x = 100 in VB6 type inference rules would make that an Integer (VB6 Integer, 16bit signed). And you know what I meant by ambiguous, that it's not readily apparent and you have to dig into a complex rule set, *just like with VB6 Variant typing or consts*, which have resulted in untold hours running down hard to trace bugs, *because of the ambiguity*, and how unneccessarily easy it makes it for people, especially the beginners and people just trying to make quick tools for their actual work, BASIC is popular with.

---

I think we view what's ambiguous in entirely different ways. As far as I'm concerned the rules in both VB6 and VB.Net are unambiguous. What I see as ambiguous is more like undefined behavior.

For example C/C++ is notorious for this. Reading outside the bounds of an array in C in undefined. It could crash your application, format your hard drive or do nothing at all. There is no defined behavior for this operation therefore it is ambiguous. A famous example would be the fast inverse square root function in the Quake source code. It's a C function that relies on a bunch of undefined behaviors. It worked at the time, but there is no telling how a modern C compiler would execute that code.

BASIC on the other hand was designed with very clearly defined behaviors. You read outside the bounds of an array in BASIC, it crashes with a specific error. There is no ambiguity there. When you do something like Dim x in VB6, the behavior is defined. In the absence of something like DefInt A-Z that would be a Variant. That is not ambiguous to me.

I think where we truly differ is that I believe the programmer should be held fully responsible for learning the language he is using, where as you seem to believe it is acceptable if he does not. Now don't me wrong. I don't know every single tiny thing about all the rules of VB.Net but when I make errors because I didn't understand a specific behavior, I blame myself, not Microsoft because chances are whatever I misused had clearly defined behavior that was documented.

Quote:

---

Originally Posted by Niya

It is a real thing. Here's some actual code from a small utility application used by a couple clients:-

Code:

---

Imports System.Globalization
Imports System.Windows.Markup

Public Class ItemDisplayLayoutsToBooleanConverter
    Inherits MarkupExtension
    Implements IValueConverter

    Public Sub New()

    End Sub

    Public Sub New(ByVal curOption As ItemDisplayLayouts)
        Me.CurrentOption = curOption
    End Sub

    Public Property CurrentOption As ItemDisplayLayouts

    Public Function Convert(value As Object, targetType As Type, parameter As Object, culture As CultureInfo) As Object Implements IValueConverter.Convert

        If TypeOf value Is ItemDisplayLayouts Then
            Dim dataSourceValue As ItemDisplayLayouts = DirectCast(value, ItemDisplayLayouts)

            If dataSourceValue = Me.CurrentOption Then
                Return True
            End If
        End If

        Return False

    End Function

    Public Function ConvertBack(value As Object, targetType As Type, parameter As Object, culture As CultureInfo) As Object Implements IValueConverter.ConvertBack

        If TypeOf value Is Boolean Then
            Dim b As Boolean = DirectCast(value, Boolean)

            If b Then Return Me.CurrentOption

        End If

        Return Binding.DoNothing
    End Function

    Public Overrides Function ProvideValue(serviceProvider As IServiceProvider) As Object
        Return Me
    End Function
End Class



---

There's no way I could read that code 15 years from now and not understand what it does and that's partly because I wasn't being stingy about naming things. I like nice long descriptive names.

---

:lol:

🤣

You seriously think clearly named variables are a substitute for documentation??
https://www.vbforums.com/images/ieimages/2023/04/18.png


https://www.vbforums.com/images/ieimages/2023/04/4.jpg

Obviously not but it helps.

Quote:

---

Originally Posted by fafalone

So then the behavior of VB.NET is different? Const x = 100 in VB6 type inference rules would make that an Integer (VB6 Integer, 16bit signed). And you know what I meant by ambiguous, that it's not readily apparent and you have to dig into a complex rule set, *just like with VB6 Variant typing or consts*, which have resulted in untold hours running down hard to trace bugs, *because of the ambiguity*, and how unneccessarily easy it makes it for people, especially the beginners and people just trying to make quick tools for their actual work, BASIC is popular with.

---

I think that .NET is different in this regard, though I'm way too rusty with VB6 to be certain. Actually, it isn't .NET, either, it's VS. If you have Option Infer ON, then you can write something like this:

Dim X = 100

then hover over the X (assuming you can 'hover' over a single character), and you will see the type. No digging into rules is needed, as the IDE will tell you what type the variable will be.

Of course, if you wrote out the type, then in either language it is clear what the type will be, but if you aren't sure what the type will be, then you have to look it up, which you can do either online or by letting the IDE tell you. For example, if you have this:

Dim X = SomeFunctionWhoesReturnTypeYouDontKnow()

then hovering over the X will tell you what the type returned from the function is. Clearly, that has nothing to do with the language, just with the IDE, but it IS convenient.

Quote:

---

Originally Posted by Niya

I think where we truly differ is that I believe the programmer should be held fully responsible for learning the language he is using

---

It never held me back.

Hi, dear Wayne
I'm a newbie to learn twinbasic this month. I tried to open my vb6 project directly in beta297, the import log and error report shows more than 1300 rows of errors(include a lot of repeat items). The main errors as followings,
1)in my main form
twinBASIC (IDE BETA 297) compilation error report:
{ERROR} ../Sources/Form/fMain.frm.twin [5,7]: Unexpected end of line
{ERROR} ../Sources/Form/fMain.frm.twin [6,5]: Syntax error. No handler for this symbol
2)In my main module
{ERROR} ../Sources/Module/mMain.bas [5,21]: Unrecognized datatype symbol 'fMain'
{ERROR} ../Sources/Module/mMain.bas [87,9]: Expression is neither used nor assigned
3)In my classes
{ERROR} ../Sources/Class/c2DChart.cls [1095,3]: Unrecognized member 'SetData' on type '_Clipboard' [non-extensible object]
{ERROR} ../Sources/Class/cMPFS_Function.cls [4143,40]: Invalid use of datatype hint
......
Maybe many errors are quite stupied,but so far I don't know what is a fast way to master the special grammar and bugfix skill about twinbasic, any documant or guide resources I can download from your site? Need your kind comment and suggestion. Thanks .

John

Clipboard.SetData (and GetData) aren't implemented yet; but I'd consider it a bug that it's giving an 'unrecognized member' error instead of an 'unimplemented' warning.

For the others, likely going to need more information about what's causing them... the more information you can provide the better the chances Wayne is able to address it quickly. The *best* way to report a bug is to recreate it in a minimal example; a new project with just enough code to reproduce the bug with as little extraneous code as possible. Of course sometimes that's not possible; next best would be to post the project or send it privately to Wayne. When that's not possible either, at least post the offending lines and any definitions (UDTs, APIs, etc) they rely on.

twinBASIC status update:

twinBASIC Update: April 23, 2023

Highlights include a status update from Wayne Phillips, extended discussion of twinBASIC on two web forums, and updates to fafalone's ucExplorer control.


https://nolongerset.com/twinbasic-update-april-23-2023/

TB import error is because the imported form name and the control name on the form cannot be in Chinese. If there is a Chinese Variables name, the import error will occur.

Hope to add support for more Unicode source codes and controlsIt would be better if all the controls could be set to be transparent, so that they could continue the background image of the previous layer.It can also be copied.

Quote:

---

Originally Posted by Shaggy Hiker

If you look at the list, it's not just more popular that VB.NET, it appears to be ranked above VB6. That brings up the question of what the list is really about. TB seems like it is a replacement for VB6, and will be an improvement on it. Lots, if not all, of the other offerings on that list are not so compatible with VB6 source code, and many are not at all compatible. At that point, what does BASIC-like really mean?

If all the list is showing are those that exhibit some syntactical similarities to BASIC, then Java would count as C-like, even though the resemblance is only superficial.

The list seems a bit contrived, to me. It seems like it is listing, apples and things that look like apples in some ways, like peaches (they're both tree fruits), strawberries (both fruits, and both red), and fire trucks (they're both red).

---

I hope to list this topic in the basic section. This is a commercial work, and a little advertising fee is allowed. Only for VB6, the life span is extended by 50 years.

I feel very sad that some other software like basic has been moved to other language forum categories. Basic is a very good language, and I hope more people can continue it.

VBForums>Other Languages>Other BASIC

I don't think he belongs to the basic language anymore. In fact, it is 100% compatible with VB6. He should put it in the real visual basic section, section, channel

Because put it in other columns, real Vb6 enthusiasts, it can be said that 99% of people can not see these messages, there are updates or such a good tool.

Unless a VB7 () visual basic 6 plus column is added and placed in the first section of the home page of the forum.

The tB native controls and source window all support Unicode.

Definitely need more developers from around the world to sort out bugs with the wonky VB6 Unicode implementation though. You might want to post a source file so Wayne can take a look at it; it's not necessarily easy to create examples with all the exact issues of VB6 without an actual Chinese installation/OS.

With control transparency, I think there's some limits in that for compatibility purposes, they have to be based on the same underlying Windows controls, so support for transparency is limited. The form itself can be transparent (including alpha blended with opacity from 0-100 setting), unlike VB6, at least.

Agreeing with xiaoyiao, the handling of transparency is essential to be rid of the old, non-layered, entirely separate, square-control MS paradigm. Once you've used a graphical framework that handles transparency naturally, ie. transparency is the delineation of the control's border - then you realise the power of what you can create graphically. Multi-layered, natural looking, graphical controls. It is a release.

New 'graphical' controls, with a property switch allowing click-through to underlying opaque controls. This is probably my one desire from TB over all others. You may not fully appreciate it but is a game changer for VB and would make TB a tool like no other. 64bit, graphical, transparency-handling with a compositing IDE with BASIC as its language. It would be a tool for everyone, from noobs/starters to professionals.

Quote:

---

Originally Posted by yereverluvinuncleber

Agreeing with xiaoyiao, the handling of transparency is essential to be rid of the old, non-layered, entirely separate, square-control MS paradigm. Once you've used a graphical framework that handles transparency naturally, ie. transparency is the delineation of the control's border - then you realise the power of what you can create graphically. Multi-layered, natural looking, graphical controls. It is a release.

---

This is the approach MS took with WPF. All WPF controls are built from scratch with no foundation whatsoever on Windows controls so they have none of their limits. They can be subjected to all manner of graphical and geometric transformations to create just about any kind of UI you can imagine.

Quote:

---

Originally Posted by Niya

This is the approach MS took with WPF. All WPF controls are built from scratch with no foundation whatsoever on Windows controls so they have none of their limits. They can be subjected to all manner of graphical and geometric transformations to create just about any kind of UI you can imagine.

---

Yes, agreed and understood - and in that context, that is what I have really always wanted from VB6, with Olaf's work it is at least partly achievable. Hoping that TB will have that capability built-in and integrated via IDE and capability - at least some time in the near future. The benefits of a control without limits can only be appreciated once you have started building with them. Freedom and flexibility.

Olaf's widgets in RichClient are also based on Windows controls I believe as they have window handles. A new UI framework needs to be completely independent if you wish them to be free of the limits of Windows controls. WPF controls for example have no window handles and GDI cannot be used to render on their surfaces.

I think TwinBASIC users could look forward to such a framework because Wayne has made it clear that he intends to make TwinBASIC cross platform. One of the things it will need to achieve this is a platform independent UI framework.

Quote:

---

Originally Posted by yereverluvinuncleber

...what I have really always wanted from VB6, with Olaf's work it is at least partly achievable...

---

That's not true - the RC5/6 Form+Widget-engine supports Alpha-Rendering fully at each nesting-level.

All you have to do, to adapt this engine to your specific needs,
is to add about 5 lines of self-written User-Code into the Widgets native HitTest-Event.

@Niya
The Widgets themselves work fully windowless (only TopLevel-Forms have a hWnd - no way around it on a Win-OS)-
the "siting-system" is based on normal COM-classes (normal COM-ABI with a VTable) -
and the only "other dependency" for it to work multi-platform, is the cairo-lib.

Olaf