TwinBasic

[vbrad]

No voting required surely? These things should be sorted by configuration.

I mean we all use tools that are newer and do things the 'new' way but we old VB6ers are used to our old IDE, the way we have been using it for 20 years now. It is hard to unlearn. However, I'd be more than happy to use CTRL+R as a replacement for "find and replace" whereas old VB6 requires it to be CTRL+H. Give me the option to configure it exactly how I'd like and I am sure we will all be happy.

Maybe I'm doing it wrong but I find that making new features configurable adds greatly to the time it takes to complete them.
If that's right then I'd prefer for there to be just one twinbasic way of doing things and I can easily live with that if it opens
my vb6 projects. That's the one thing I want.

[yereverluvinuncleber]

As another chap here said, some of us will be working with VB6 probably at the same time as TwinBasic, I have real reasons for doing so. It will make life much easier if TB, being the successor to VB6 acts like it. All the tools I create are configurable, it is easy to do so, perhaps we will let the designers tell us how easy it might be for VS Code.

[WaynePhillipsEA]

VS Code is extremely configurable in this regard. For example, if you want Ctrl+Y to do what VB6 does, it takes only a few seconds to set it up - details here

The Alt+Shift+Backspace combination isn't assigned to anything in VS Code by default, so it makes sense for us to simply assign that also to the Redo command in the twinBASIC extension. However, for the Ctrl+Y combination, we'll leave it at the more standard default of 'Redo', but you can easily change it as per the above instructions. We might offer an initial welcome/setup page when you first install the twinBASIC extension so that you can easily configure things like this.

[Niya]

Minor suggestion. I think having the IDE append a () after for any function call where the function has no parameters would help code readability. It feels really odd reading code where you see something like:-

v = GetValue

instead of:-

v = GetValue()

Imagine reading code like that 3 years later. It's not hard to envision that you might be wondering what the heck GetValue is. Is it a variable? A function? It needs to be unambiguous.

[Eduardo-]

I vote again for Ctrl+Y to do what almost every other Windows program does. We can vote more than once right? But seriously, I think it's easier to remap your brain once to a shortcut that works across all apps vs. having to remap it dynamically every time you task switch to another app.

In my case I don't have to remap because I almost never use redo, and when I need it, yes, I have to go to the menu because there is no shortcut for it in VB6 IDE, and I acknowledge it is a bit cumbersome not having a shortcut.
BTW, in my case I don't use Ctrl+Y in any other program for redo either.

Maybe customizable hotkey to action mapping (similar to what MZTools offers) is what's needed.

There are already customization options for shortcuts in the vscode IDE.
I wonder if the customization file can be saved (and restored after a new installation)

[WaynePhillipsEA]

@Niya... there is now a restart-compiler button for you in the twinBASIC extension panel (or press Shift+Escape).
https://marketplace.visualstudio.com...asic/changelog

[Niya]

@Niya... there is now a restart-compiler button for you in the twinBASIC extension panel (or press Shift+Escape).
https://marketplace.visualstudio.com...asic/changelog

Just tested it with the code I posted in post #256 and it works great and very fast too. Barely takes a second to reload.

[yereverluvinuncleber]

BTW, in my case I don't use Ctrl+Y in any other program for redo either.

In my head CTRL+Y is break, coming from a VMS background it is equivalent to CTRL+C. I could not use it for anything else it is too engrained in brain warped by old operating systems.

[VB6 Programming]

Niya has posted a twinBASIC Pure Win32 GUI Sample. It is a simple clock showing the power of twinBASIC even without its GUI tools.
Well worth a look.

https://www.vbforums.com/showthread....n32-GUI-Sample

[Niya]

Niya has posted a twinBASIC Pure Win32 GUI Sample. It is a simple clock showing the power of twinBASIC even without its GUI tools.
Well worth a look.

https://www.vbforums.com/showthread....n32-GUI-Sample

If you think that's impressive, wait till you see what I'm doing now. I've taken the code from that project and built a very rudimentary GUI foundation similar to what we see VB6 and WinForms in .Net. So far I've created a Form class with some basic properties and events working.

Here is some code where I'm testing the Form's position related properties:-

		dim f1 as new TBForm
		
		f1.Show
		
		debug.Print cstr(f1.Left)
		debug.Print cstr(f1.top)
		debug.Print cstr(f1.Width)
		debug.Print cstr(f1.Height)

All of this is implemented using pure Win32 with no dependencies.

[VB6 Programming]

Already hugely impressive even in this very early preview, twinBASIC at last offers VB6 developers the hope of a way forward.

As long-time VB6 supporter Niya says

Looks like you guys are getting your new VB6 after all. You guys have been waiting decades for this. Don't let this fail now.

Considering the potential importance of twinBASIC as a VB6 replacement, this thread really ought to be in the main VB6 forum, not hidden away under 'Other BASIC'.

[VB6 Programming]

If you think that's impressive, wait till you see what I'm doing now. I've taken the code from that project and built a very rudimentary GUI foundation similar to what we see VB6 and WinForms in .Net. So far I've created a Form class with some basic properties and events working.

All of this is implemented using pure Win32 with no dependencies.

I look forward to seeing this - and welcome to the dark side

[Niya]

Considering the potential importance of twinBASIC as a VB6 replacement, this thread really ought to be in the main VB6 forum, not hidden away under 'Other BASIC'.[/I]

Practically speaking I agree. I almost posted that TwinBASIC sample in the VB6 section but decided against it. TwinBASIC is technically it's own thing. Although it is 100% VB6 compatible right now, it does depart significantly from VB6 in it's extra offerings.

It's up to the moderators to decide what to do with these threads of course. Personally, I'd put them with the VB6 stuff until TwinBASIC gets powerful and popular enough to stand on it's own.

[Niya]

I look forward to seeing this

I'm gonna post the code to it when I finish it. Right now, I'm having trouble deciding how far to take it. I would like to implement at least one control like a Button but I might just end up stopping with just a Form class. I'm not sure where the finish line will be but when I reach it, I'll release the code for that.

and welcome to the dark side

I have a deep love for doing technical stuff like this which is what makes VB6/TwinBASIC interesting for me. You don't get to do stuff like this in VB.Net because it's all been done for you already which is good for productivity but not as fun as doing it yourself. However, it doesn't pay the bills. When I'm doing real work and I need serious productivity, I will stick with modern tools like .Net and Visual Studio 2019+. TwinBASIC would also fall in this category. Language wise, TwinBASIC strikes a cord almost perfectly between the power of VB.Net and the simplicity of VB6. And the Visual Studio Code IDE is comparable to modern versions of Visual Studio. I could really see myself using TwinBASIC for smaller workloads. Even at this early stage in it's development with all the bugs and glitches still unsolved, it feels a lot better than VB6 when writing code.

[VB6 Programming]

twinBASIC status update:

https://nolongerset.com/twinbasic-up...ugust-15-2021/

The current twinBASIC version is v0.10.4378

Highlights include IntelliSense improvements, a 12-month twinBASIC roadmap, and Niya's Win32 API GUI application written in twinBASIC.

[si_the_geek]

It's up to the moderators to decide what to do with these threads of course. Personally, I'd put them with the VB6 stuff until TwinBASIC gets powerful and popular enough to stand on it's own.

While TwinBasic is similar to VB6, it is different - so the VB6 forum is not right, and OtherBasic is the place.

If it becomes popular (as it looks like it might), we would certainly consider a specific forum for TwinBasic.

Considering the potential importance of twinBASIC as a VB6 replacement, this thread really ought to be in the main VB6 forum, not hidden away under 'Other BASIC'.

That wouldn't be right I'm afraid, but feel free to post a link to this thread (along with some text if you like) in your signature, so it will be seen when people view your posts in the VB6 forum.

[Niya]

While TwinBasic is similar to VB6, it is different - so the VB6 forum is not right, and OtherBasic is the place.

I thought as much.

twinBASIC status update:

https://nolongerset.com/twinbasic-up...ugust-15-2021/

The current twinBASIC version is v0.10.4378

Highlights include IntelliSense improvements, a 12-month twinBASIC roadmap, and Niya's Win32 API GUI application written in twinBASIC.

Oooo...Thanks for the mention. Appreciate it.

[Niya]

@WaynePhillipsEA

I just discovered something that could either be a breaking bug or perhaps it's nothing at all. Either way, I want to draw it to your attention.

Old school VB6 programmers know of this trick where you can pass VB6 COM object references to non-COM clients like the Win32 API. For example, if you have a Win32 or C++ API call that used callbacks, you could pass object references to the callback using this trick. The trick is to create an illegal reference to the COM object which is basically a raw pointer. You can then pass this to the API and when the API makes a callback call, you can dump that pointer back into a VB6 variable and use that variable as you would any object variable. The only catch is that COM would not be aware of this extra reference so if you allow this new variable to go out of scope without removing pointer, it could lead to disaster. I tried this trick in TwinBASIC and it works differently for a potential worrying reason. I'll post code so you can see exactly what I'm talking about:-

Module MainModule
    Public Declare Sub CopyMemory Lib "Kernel32" Alias "RtlMoveMemory"	(ByVal dest As LongPtr, ByVal src As LongPtr, ByVal count As Long)
    
    Private g_cls As New Class1
    
    ' This project type is set to 'Standard EXE' in the Settings file, so you need a Main() subroutine to run when the EXE is started.
    Public Sub Main()
        
        g_cls.ShowMsg
        
        'Creates an illegal reference and let it go out of scope
        DoIllegalRef
        
        'This is not supposed to work. This would crash in VB6 and for good reason.
        'We created an illegal reference and allowed it to go out of scope which means COM
        'should have decreased the reference count and since we only have a single
        'legal reference, that would have made the reference count zero which means COM
        'should have destroyed this object. However in TwinBASIC as of v0.10.4380, this object
        'is still alive. This could mean that either TwinBASIC is smart enough to know that it was
        'an illegal reference and didn't decrease the reference count. Or it could mean there is a serious
        'bug in the TwinBASIC compiler.
        g_cls.ShowMsg
    
        
    End Sub
	
    Private Sub DoIllegalRef()
        
        'Variable to hold illegal reference to the Class1 instance in the g_cls
        'module level variable
        Dim ref As Class1
        
        'Creates an illegal reference to a Class1 object 
        'Because it was created this way, COM should not be aware of it and should not increment the
        'reference count
        CopyMemory VarPtr(ref), VarPtr(g_cls), 4
        
        ref.ShowMsg
        
        'In VB6 COM would decrease the refrence count of 
        'the Class1 object since the ref variable is about to go out of scope. 
    End Sub
    
    
End Module


Public Class Class1
    Public Sub ShowMsg()
        MsgBox ("Boo")
    End Sub
End Class

I describe the worrying behavior in the comments.

[WaynePhillipsEA]

@WaynePhillipsEA

I just discovered something that could either be a breaking bug or perhaps it's nothing at all. Either way, I want to draw it to your attention.

Old school VB6 programmers know of this trick where you can pass VB6 COM object references to non-COM clients like the Win32 API. For example, if you have a Win32 or C++ API call that used callbacks, you could pass object references to the callback using this trick. The trick is to create an illegal reference to the COM object which is basically a raw pointer. You can then pass this to the API and when the API makes a callback call, you can dump that pointer back into a VB6 variable and use that variable as you would any object variable. The only catch is that COM would not be aware of this extra reference so if you allow this new variable to go out of scope without removing pointer, it could lead to disaster. I tried this trick in TwinBASIC and it works differently for a potential worrying reason. I'll post code so you can see exactly what I'm talking about:-

Module MainModule
    Public Declare Sub CopyMemory Lib "Kernel32" Alias "RtlMoveMemory"	(ByVal dest As LongPtr, ByVal src As LongPtr, ByVal count As Long)
    
    Private g_cls As New Class1
    
    ' This project type is set to 'Standard EXE' in the Settings file, so you need a Main() subroutine to run when the EXE is started.
    Public Sub Main()
        
        g_cls.ShowMsg
        
        'Creates an illegal reference and let it go out of scope
        DoIllegalRef
        
        'This is not supposed to work. This would crash in VB6 and for good reason.
        'We created an illegal reference and allowed it to go out of scope which means COM
        'should have decreased the reference count and since we only have a single
        'legal reference, that would have made the reference count zero which means COM
        'should have destroyed this object. However in TwinBASIC as of v0.10.4380, this object
        'is still alive. This could mean that either TwinBASIC is smart enough to know that it was
        'an illegal reference and didn't decrease the reference count. Or it could mean there is a serious
        'bug in the TwinBASIC compiler.
        g_cls.ShowMsg
    
        
    End Sub
	
    Private Sub DoIllegalRef()
        
        'Variable to hold illegal reference to the Class1 instance in the g_cls
        'module level variable
        Dim ref As Class1
        
        'Creates an illegal reference to a Class1 object 
        'Because it was created this way, COM should not be aware of it and should not increment the
        'reference count
        CopyMemory VarPtr(ref), VarPtr(g_cls), 4
        
        ref.ShowMsg
        
        'In VB6 COM would decrease the refrence count of 
        'the Class1 object since the ref variable is about to go out of scope. 
    End Sub
    
    
End Module


Public Class Class1
    Public Sub ShowMsg()
        MsgBox ("Boo")
    End Sub
End Class

I describe the worrying behavior in the comments.

The reference count is reaching zero at the correct point, and the object is being destroyed also. However, the memory allocation routines we use are different to VB6, and so the memory block might still be valid for the extra call to work... or it might not... as you're still playing with fire. Once the memory block gets reused/reissued, which depends on factors such as time and memory pressure, you will almost certainly get a crash.

BTW, if you add a Class_Terminate Sub to the class, you'll see the object get destroyed at the correct point:

Public Sub Class_Terminate()
   MsgBox "Destroyed!"
End Sub

[Niya]

The reference count is reaching zero at the correct point, and the object is being destroyed also. However, the memory allocation routines we use are different to VB6, and so the memory block might still be valid for the extra call to work... or it might not... as you're still playing with fire. Once the memory block gets reused/reissued, which depends on factors such as time and memory pressure, you will almost certainly get a crash.

BTW, if you add a Class_Terminate Sub to the class, you'll see the object get destroyed at the correct point:

Public Sub Class_Terminate()
   MsgBox "Destroyed!"
End Sub

Well that's very good news. I was concerned that TwinBASIC had some kind of bug in it's COM ABI.

Also, in case anyone who stumbles across this wonders if there is a way to make use of this trick and not get burned, there is. I don't know how other people deal with it but I came up with a way of dealing with it by essentially tricking TwinBASIC/VB6 into updating the object's reference count:-

	Private Function PtrToObject(ByVal ptr As Long) As Object
		'This function allows us to create a COM object from just a pointer
		'and makes sure that COM knows about it
		'****************************************************************
		Dim illegalObj As Object
		Dim legalObj As Object
		Dim zero As Long
		
		'Create an illegal reference from the pointer
		'passed into this procedure. This wouldn't increase the reference count
		'which is bad.
		CopyMemory VarPtr(illegalObj), VarPtr(ptr), 4
		
		'This assignment increases the reference count of the object
		Set legalObj = illegalObj
		
		'Zero our illegal reference so TwinBASIC doesn't try
		'to decrement the reference count when this function returns
		CopyMemory VarPtr(illegalObj), VarPtr(zero), 4
		
		'Return the legal reference
		return legalObj
	End Function

You can use it like this:-

    Dim myObject As New Class1
    
    Dim clonedRef As Class1
    
    Set clonedRef = PtrToObject(ObjPtr(myObject))

This method works in VB6 so I expect it would be acceptable in TwinBASIC as well.

[TTn]

Early integration of twinBasic with a VB.NET form designer from VB6Namespaces.

I would like the "Set" keyword to be allowed in tB. Otherwise code that is copy/pasted will run into issues in larger snippets with lots of object setting.

[WaynePhillipsEA]

Early integration of twinBasic with a VB.NET form designer from VB6Namespaces.

I would like the "Set" keyword to be allowed in tB. Otherwise code that is copy/pasted will run into issues in larger snippets with lots of object setting.

Looks good @TTn! The 'Set' keyword is fully implemented. What issue are you having with it?

[TTn]

Looks good @TTn! The 'Set' keyword is fully implemented. What issue are you having with it?

Looks fine now! Thanks. I was getting squiggles underneath, as if Set was not allowed. I thought the interop might have been causing tB to ignore them as objects being set, since as copied/pasted VBCtl is not VB as it is in tB. VB6 appends "Ctl" to whatever name being used. Everything is good in the latest test though! Thanks

[WaynePhillipsEA]

Looks fine now! Thanks. I was getting squiggles underneath, as if Set was not allowed. I thought the interop might have been causing tB to ignore them as objects being set, since as copied/pasted VBCtl is not VB as it is in tB. VB6 appends "Ctl" to whatever name being used. Everything is good in the latest test though! Thanks

Ah ok. Sometimes the squiggles can be on the wrong keyword, but that doesn't happen very often now. If you see that again, hover over it and see what the error message is as it will likely be an issue with the adjacent symbol rather than the Set keyword itself.

[TTn]

Ah ok. Sometimes the squiggles can be on the wrong keyword, but that doesn't happen very often now. If you see that again, hover over it and see what the error message is as it will likely be an issue with the adjacent symbol rather than the Set keyword itself.

Right, that's what I thought but wasn't sure with the interop from my end.
Update: I was in the main module when that happened, inside of a class under the MainModule. I thought we could have more than one module per file? No problem really, I just didn't see any restrictions until I saw the suggestion to place the class in another file. The designed file now works in tB.

I was able to save the designed form file into tB, and use the created form with a button event responding.
If there was an easier way to save the class designer code directly into tb that would be great. Some kind of intercommunication if possible to create a new file in vs code. I did that manually with the clipboard, then had to replace all "VBCtl" with "VB". No squiggles!

[WaynePhillipsEA]

Right, that's what I thought but wasn't sure with the interop from my end.
Update: I was in the main module when that happened, inside of a class under the MainModule. I thought we could have more than one module per file? No problem really, I just didn't see any restrictions until I saw the suggestion to place the class in another file. The designed file now works in tB.

I was able to save the designed form file into tB, and use the created form with a button event responding.
If there was an easier way to save the class designer code directly into tb that would be great. Some kind of intercommunication if possible to create a new file in vs code. I did that manually with the clipboard, then had to replace all "VBCtl" with "VB". No squiggles!

Yes, you can have more than one component per twin file, that's no problem. The quick-fix suggestion is there because in the first releases of tB we only allowed a single .twin file, so devs were naturally stuffing many, many components into a single file and they wanted a quick way to split them up once we started allowing multiple .twin files. You can safely ignore that suggestion, and tB wont mind at all.

With regards to saving the generated designer code into tB; it seems what you really want is an extensibility API, like you have in VBA. A simple extensibility API would be easy to implement, but the main problem would be that after making a change to a file in the tB virtual filesystem, the compiler will automatically kick in and 'reset' the debug session, including all running code and all global variables because it doesn't yet support Edit & Continue. Until Edit & Continue is supported, we could potentially offer a feature in the extensibility API to turn off the compiler so that it simply doesn't notice the changes to the files that you've made, until your designer exits. Needs a little more thought, but should be achievable.

[TTn]

Yes, you can have more than one component per twin file, that's no problem. The quick-fix suggestion is there because in the first releases of tB we only allowed a single .twin file, so devs were naturally stuffing many, many components into a single file and they wanted a quick way to split them up once we started allowing multiple .twin files. You can safely ignore that suggestion, and tB wont mind at all.

With regards to saving the generated designer code into tB; it seems what you really want is an extensibility API, like you have in VBA. A simple extensibility API would be easy to implement, but the main problem would be that after making a change to a file in the tB virtual filesystem, the compiler will automatically kick in and 'reset' the debug session, including all running code and all global variables because it doesn't yet support Edit & Continue. Until Edit & Continue is supported, we could potentially offer a feature in the extensibility API to turn off the compiler so that it simply doesn't notice the changes to the files that you've made, until your designer exits. Needs a little more thought, but should be achievable.

That makes sense, it would have to be a simpler implementation at first. It could be worth thinking about later. I will help by exposing some events from the designer and I'll make an option to save to the clipboard for quickly transferring the designer code over to tB. It can still save a lot of time designing the initial form starting point. I still have to do a lot of testing to make sure all of the properties save/open correctly.

[Niya]

Here's a teeny tiny very minor suggestion. A better way to do this:-

	public function LOWORD(byval value as long) as integer
		return value and clng("&hffff")
	End Function

CLng is there to prevent TwinBASIC from sign extending the 2 byte Integer form of &hFFFF to a 4 byte Integer of value &hFFFFFFFF when we actually want &h0000FFFF

This exact function in VB.Net would look like this:-

    Public Function LOWORD(ByVal value As Integer) As Short
        Return value And &HFFFFI
    End Function

VB.Net allows you to specify the data type of that hex value with a suffix, which in this case is the letter I. This means it's not going to sign extend a 2 byte Integer to a 4 byte integer, since it starts with a 4 byte Integer.

Again, this is just a minor suggestion and not something I would consider an immediate concern. I just think using CLng on a String on like that for this is a bit wild. It just reeks of a kind of dirtiness that is a bit uncomfortable.

[WaynePhillipsEA]

Here's a teeny tiny very minor suggestion. A better way to do this:-

	public function LOWORD(byval value as long) as integer
		return value and clng("&hffff")
	End Function

CLng is there to prevent TwinBASIC from sign extending the 2 byte Integer form of &hFFFF to a 4 byte Integer of value &hFFFFFFFF when we actually want &h0000FFFF

This exact function in VB.Net would look like this:-

    Public Function LOWORD(ByVal value As Integer) As Short
        Return value And &HFFFFI
    End Function

VB.Net allows you to specify the data type of that hex value with a suffix, which in this case is the letter I. This means it's not going to sign extend a 2 byte Integer to a 4 byte integer, since it starts with a 4 byte Integer.

Again, this is just a minor suggestion and not something I would consider an immediate concern. I just think using CLng on a String on like that for this is a bit wild. It just reeks of a kind of dirtiness that is a bit uncomfortable.

Ney Niya, you can do the same in tB (and VB6), by appending the Long suffix character, &:
&HFFFF&

[Niya]

Ney Niya, you can do the same in tB (and VB6), by appending the Long suffix character, &:
&HFFFF&

Ah. Sweet. That never occurred to me to try that. I feel dumb for that

[Niya]

Found some more problems with the intellisense. It doesn't seem to work when writing code inside a generic class. The colour coding for identifiers, keyworsd etc also gets a bit screwed up sometimes. Example:-

Private Class List(Of T)
	
	Private Const INITIAL_SIZE As Long = 10
	Private g_items() As T
	Private g_count As long
	
	Public Sub new()
		Init(INITIAL_SIZE)
	End Sub

	Public Sub new(capacity As Long)
		Init(capacity)
	End Sub
	
	Public Sub Add(ByVal item As T)
		g_items(g_count) = item
		
		g_count += 1
		
		Me.ResizeArrayIfNeeded()
	End Sub
	
	Public Sub RemoveItem(ByVal index As Long)
		Dim i As Long
		Dim x As Long
		Dim newArray() As T
		
		ReDim newArray(0 To (Me.SizeOfArray - 1))
		
		For i = 0 To Me.Count - 1
			If i = index Then Continue For
			
			newArray(x) = g_items(i)
			x += 1
		Next
		
		g_count -= 1
		
		'TODO: Find out of TwinBASIC actually copies the array element by element
		'or simply replaces array references like VB.Net does. If it does a full copy
		'then we will need to optimize this. No sense in having to traverse the array
		'twice for a remove operation
		g_items = newArray
	End Sub
	
	Public Property Get Count() As Long
		Return g_count
	End Property
	
	Public Property Get Items(ByVal index As Long) As T
		Return g_items(index)
	End Property
	
	Private Function SizeOfArray() As Long
		Return UBound(g_items) - LBound(g_items) + 1
	End Function
	
	Private Sub ResizeArrayIfNeeded()
		Dim sz As Long = Me.SizeOfArray()
		
		If g_count = sz Then ReDim Preserve g_items(0 To (sz * 2) - 1)
	End Sub
	
	Private Sub Init(ByVal capacity As Long)
		ReDim g_items(0 To capacity - 1)
	End Sub
	
	
End Class

While writing that code, the intellisense was completely asleep. For example Me. wasn't giving me the list of class methods already written like it usually does in a non-generic class.

Good work on generics by the way. It works fantastic otherwise.

[Niya]

I just ran into a problem caused by the old world of VB6 clashing head first into the new world of TwinBASIC:-

Module MainModule

    ' This project type is set to 'Standard EXE' in the Settings file, so you need a Main() subroutine to run when the EXE is started.
    Public Sub Main()
        
        Dim oc1 As OtherClass(Of String) = New OtherClass(Of String)
        Dim oc2 As OtherClass(Of Long) = New OtherClass(Of Long)
        Dim oc3 As OtherClass(Of Person) = New OtherClass(Of Person)
        
        oc1.SomeMethod("KL")
        oc2.SomeMethod(34)
        
        'This fails at runtime because the generic class
        'cannot handle non-Object types internally
        oc3.SomeMethod(New Person("John"))
        
        
    End Sub
    
End Module

Private Class OtherClass(Of T)
    
    Private g_myField As T
    
    Public Sub SomeMethod(ByVal value As T)
        
        'This will fail if T is ever an Object type
        'TwinBASIC, like VB6 requires that object assignment be done
        'with the Set keyword. I've tried a number of approaches but
        'found no way to coerce a 1 size fits all way of doing this.
        g_myfield = value
    End Sub
    
End Class
    
Private Class Person
    Public PersonName As String
    
    Public Sub New(ByVal n As String)
        Me.PersonName = n
    End Sub
    
End Class

The above code reproduces a problem with generics with it's relationship to TwinBASIC/VB6's class system. It seems a generic class cannot be authored to work with both object and non-object types if the internals of the class performs any kind of assignment of the type. TwinBASIC requires that assignment of Object types to variables be done with the Set keyword and non-Object assignments be done with an implicit or explicit Let. What this means is that a generic class can either work with Objects or non-Object. I've tried a number things to discover a workaround including involving Variants but nothing works. The only work around is to have two versions of the class, one for Objects and one for non-Objects.

If I may be so bold to make a tiny suggestion. Make the Set keyword optionally explicit like Let when object assignment is being performed. After using VB.Net for a number of years I can say with 100% certainty that there is zero benefit to demanding explicit use of a Set keyword or anything like it for object assignment. We are perfectly fine assigning objects using normal assignment syntax. It was never needed and whatever degenerate at Microsoft thought this was a good idea needs some jail time for this crime . By making it optionally explicit, you can solve problems like what I described above and maintain backward compatibility with VB6 at the same time.

[WaynePhillipsEA]

Found some more problems with the intellisense. It doesn't seem to work when writing code inside a generic class. The colour coding for identifiers, keyworsd etc also gets a bit screwed up sometimes. Example:-

Private Class List(Of T)
	
	Private Const INITIAL_SIZE As Long = 10
	Private g_items() As T
	Private g_count As long
	
	Public Sub new()
		Init(INITIAL_SIZE)
	End Sub

	Public Sub new(capacity As Long)
		Init(capacity)
	End Sub
	
	Public Sub Add(ByVal item As T)
		g_items(g_count) = item
		
		g_count += 1
		
		Me.ResizeArrayIfNeeded()
	End Sub
	
	Public Sub RemoveItem(ByVal index As Long)
		Dim i As Long
		Dim x As Long
		Dim newArray() As T
		
		ReDim newArray(0 To (Me.SizeOfArray - 1))
		
		For i = 0 To Me.Count - 1
			If i = index Then Continue For
			
			newArray(x) = g_items(i)
			x += 1
		Next
		
		g_count -= 1
		
		'TODO: Find out of TwinBASIC actually copies the array element by element
		'or simply replaces array references like VB.Net does. If it does a full copy
		'then we will need to optimize this. No sense in having to traverse the array
		'twice for a remove operation
		g_items = newArray
	End Sub
	
	Public Property Get Count() As Long
		Return g_count
	End Property
	
	Public Property Get Items(ByVal index As Long) As T
		Return g_items(index)
	End Property
	
	Private Function SizeOfArray() As Long
		Return UBound(g_items) - LBound(g_items) + 1
	End Function
	
	Private Sub ResizeArrayIfNeeded()
		Dim sz As Long = Me.SizeOfArray()
		
		If g_count = sz Then ReDim Preserve g_items(0 To (sz * 2) - 1)
	End Sub
	
	Private Sub Init(ByVal capacity As Long)
		ReDim g_items(0 To capacity - 1)
	End Sub
	
	
End Class

While writing that code, the intellisense was completely asleep. For example Me. wasn't giving me the list of class methods already written like it usually does in a non-generic class.

Good work on generics by the way. It works fantastic otherwise.

Glad you like it Niya. Intellisense / semantic highlighting being missing for generics is a known issue. We had to turn off those bits for the preview as there were too many unresolved issues at the time. We shall revisit that soon, since as you rightly point out generics themselves are working pretty well, but without the intellisense and semantic highlighting they are difficult to work with.

[WaynePhillipsEA]

I just ran into a problem caused by the old world of VB6 clashing head first into the new world of TwinBASIC:-

Module MainModule

    ' This project type is set to 'Standard EXE' in the Settings file, so you need a Main() subroutine to run when the EXE is started.
    Public Sub Main()
        
        Dim oc1 As OtherClass(Of String) = New OtherClass(Of String)
        Dim oc2 As OtherClass(Of Long) = New OtherClass(Of Long)
        Dim oc3 As OtherClass(Of Person) = New OtherClass(Of Person)
        
        oc1.SomeMethod("KL")
        oc2.SomeMethod(34)
        
        'This fails at runtime because the generic class
        'cannot handle non-Object types internally
        oc3.SomeMethod(New Person("John"))
        
        
    End Sub
    
End Module

Private Class OtherClass(Of T)
    
    Private g_myField As T
    
    Public Sub SomeMethod(ByVal value As T)
        
        'This will fail if T is ever an Object type
        'TwinBASIC, like VB6 requires that object assignment be done
        'with the Set keyword. I've tried a number of approaches but
        'found no way to coerce a 1 size fits all way of doing this.
        g_myfield = value
    End Sub
    
End Class
    
Private Class Person
    Public PersonName As String
    
    Public Sub New(ByVal n As String)
        Me.PersonName = n
    End Sub
    
End Class

The above code reproduces a problem with generics with it's relationship to TwinBASIC/VB6's class system. It seems a generic class cannot be authored to work with both object and non-object types if the internals of the class performs any kind of assignment of the type. TwinBASIC requires that assignment of Object types to variables be done with the Set keyword and non-Object assignments be done with an implicit or explicit Let. What this means is that a generic class can either work with Objects or non-Object. I've tried a number things to discover a workaround including involving Variants but nothing works. The only work around is to have two versions of the class, one for Objects and one for non-Objects.

If I may be so bold to make a tiny suggestion. Make the Set keyword optionally implicit like Let when object assignment is being performed. After using VB.Net for a number of years I can say with 100% certainty that there is zero benefit to demanding explicit use of the Set keyword for object assignment. It was never needed and I hope they fired whatever degenerate at Microsoft thought this was a good idea. By making it optionally implicit, you can solve problems like what I described above and maintain backward compatibility with VB6 at the same time.

We can't make Set optional since in classic VB it is valid to do things like

MyVariant = MyObject

where the semantics are different to

Set MyVariant = MyObject

. In the first version, the default member of MyObject is evaluated (DISPID_VALUE), and in the second version it is not. One of the reasons they were able to remove the Set keyword requirement in VB.NET is because they don't support default member evaluation in VB.NET like classic VB does.

In your example, you could check for IsObject(value) and then use Set assignment, otherwise defer to Let-assignment. However, I could see this being a common issue in generics, and so it might be worth thinking of an alternative solution, such as introducing another keyword instead of Set that will decide to do either Set-assignment or Let-assignment based on the RHS type. That would be a compile time decision and so offer slightly better performance than branching on IsObject() at runtime.

[wqweto]

Well that's very good news. I was concerned that TwinBASIC had some kind of bug in it's COM ABI.

Also, in case anyone who stumbles across this wonders if there is a way to make use of this trick and not get burned, there is. I don't know how other people deal with it but I came up with a way of dealing with it by essentially tricking TwinBASIC/VB6 into updating the object's reference count:-

	Private Function PtrToObject(ByVal ptr As Long) As Object
		'This function allows us to create a COM object from just a pointer
		'and makes sure that COM knows about it
		'****************************************************************
		Dim illegalObj As Object
		Dim legalObj As Object
		Dim zero As Long
		
		'Create an illegal reference from the pointer
		'passed into this procedure. This wouldn't increase the reference count
		'which is bad.
		CopyMemory VarPtr(illegalObj), VarPtr(ptr), 4
		
		'This assignment increases the reference count of the object
		Set legalObj = illegalObj
		
		'Zero our illegal reference so TwinBASIC doesn't try
		'to decrement the reference count when this function returns
		CopyMemory VarPtr(illegalObj), VarPtr(zero), 4
		
		'Return the legal reference
		return legalObj
	End Function

You can use it like this:-

    Dim myObject As New Class1
    
    Dim clonedRef As Class1
    
    Set clonedRef = PtrToObject(ObjPtr(myObject))

This method works in VB6 so I expect it would be acceptable in TwinBASIC as well.

In VB6 we usually directly use vbaObjSetAddref export from msvbvm60 to hydrate weakrefs (raw ObjPtr pointers) like this

Private Declare Function vbaObjSetAddref Lib "msvbvm60" Alias "__vbaObjSetAddref" (oDest As Any, ByVal lSrcPtr As Long) As Long

Public Function PtrToObject(ByVal ptr As Long) As Object
    Call vbaObjSetAddref(PtrToObject, ptr)
End Function

. . . which automagically takes care of the refcount staying correct.

Implementing this as an intrinsic function on LongPtr data-type in TB would be most welcome of course but it's probably very low on the nice-to-have features currently.

Baking it into the language with Set obj = ptr where ptr is of LongPtr data-type would be awesome.

cheers,
</wqw>

[WaynePhillipsEA]

In VB6 we usually directly use vbaObjSetAddref export from msvbvm60 to hydrate weakrefs (raw ObjPtr pointers) like this

Private Declare Function vbaObjSetAddref Lib "msvbvm60" Alias "__vbaObjSetAddref" (oDest As Any, ByVal lSrcPtr As Long) As Long

Public Function PtrToObject(ByVal ptr As Long) As Object
    Call vbaObjSetAddref(PtrToObject, ptr)
End Function

. . . which automagically takes care of the refcount staying correct.

cheers,
</wqw>

That reminds me that we will need to redirect DLL calls into msvbvm60 to our own implementations so that we can support them when we switch on 64-bit support (as well as remove the reliance on msvbvm60)

[Niya]

We can't make Set optional since in classic VB it is valid to do things like

MyVariant = MyObject

where the semantics are different to

Set MyVariant = MyObject

. In the first version, the default member of MyObject is evaluated (DISPID_VALUE), and in the second version it is not. One of the reasons they were able to remove the Set keyword requirement in VB.NET is because they don't support default member evaluation in VB.NET like classic VB does.

Damn. That's too bad. Even in the old days when I used VB6 primarily, I hated the Set statement with a passion. It was always a source of confusion and disarray. You had this constant mental burden of remembering to use Set when assigning objects. It always drove me absolutely bonkers, especially when I forget to use it. This was one of the things I was hoping would disappear in TwinBASIC.

In your example, you could check for IsObject(value) and then use Set assignment, otherwise defer to Let-assignment.

I was looking for something like that. I tried all kinds of shenanigans with TypeOf. I completely forgot that VB6 had an IsObject function. Come to think of it, as I'm writing this post, I just realized I could have also solved this using TypeName, which I did remember exist since I use it all the time, even in VB.Net. I could have called TypeName on all the primitive types/built in types and if there was no match, it would mean the type is an Object. Sort of an ad-hoc way of doing IsObject. That didn't occur to me till just now.

However, I could see this being a common issue in generics, and so it might be worth thinking of an alternative solution, such as introducing another keyword instead of Set that will decide to do either Set-assignment or Let-assignment based on the RHS type. That would be a compile time decision and so offer slightly better performance than branching on IsObject() at runtime.

IsObject is not the only issue. This solution also requires that you use Variants internally:-

Private Class OtherClass(Of T)
    
    'The TwinBASIC compiler complains if this is of type T
    Private g_myField As variant
    
    Public Sub SomeMethod(ByVal value As T)
            
        if isobject(value) then 
            set g_myfield=value
        else
            g_myfield=value                                   
        End If
        
    End Sub

It's a little dirty but it's definitely worth it for a powerful feature like generics. I have every confidence you will find ways to clean it up eventually. Keep doing your good work.

[wqweto]

Is it possible to declare Private g_myField As T instead of Variant?

Assigning to this member variable would be problematic though as it would need a "compile-time IsObject" for parameter type or even (better) an IsObject(T) construct to test the data-type of the typename (or whatever the T parameter to the generic is called in TB:-)).

cheers,
</wqw>

[WaynePhillipsEA]

Is it possible to declare Private g_myField As T instead of Variant?

Assigning to this member variable would be problematic though as it would need a "compile-time IsObject" for parameter type or even (better) an IsObject(T) construct to test the data-type of the typename (or whatever the T parameter to the generic is called in TB:-)).

cheers,
</wqw>

Eventually I would like to see something akin to if-constexpr support as seen in C++ so that the compiler is required to deduce whether a block is needing to be compiled. But for this my proposal is a simpler solution:

Private Class OtherClass(Of T)
    
    Private g_myField As T
    
    Public Sub SomeMethod(ByVal value As T)
        AutoSet g_myField = value
    End Sub

I don't particularly like the 'AutoSet' name, but you get the idea. The keyword would be implemented much like how Dim initializers already work in tB: if either the LHS variable or the RHS expression is an explicit object type, then AutoSet causes a set-assignment, otherwise let-assignment is used.

[Krool]

My proposal would be LetOrSet statement.
Thus the statement tells already whats going on. Either a Let or Set statement. (Though Let is optional and seldom used)