Printable View
Maybe I'm doing it wrong but I find that making new features configurable adds greatly to the time it takes to complete them.Quote:
Originally Posted by yereverluvinuncleber
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.
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.
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.
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:-
instead of:-Code: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.Code:v = GetValue()
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.Quote:
Originally Posted by jpbro
BTW, in my case I don't use Ctrl+Y in any other program for redo either.
There are already customization options for shortcuts in the vscode IDE.Quote:
Originally Posted by jpbro
I wonder if the customization file can be saved (and restored after a new installation)
@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.Quote:
Originally Posted by WaynePhillipsEA
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.Quote:
Originally Posted by Eduardo-
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.Quote:
Originally Posted by VB6 Programming
Here is some code where I'm testing the Form's position related properties:-
All of this is implemented using pure Win32 with no dependencies.Code: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)
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 :D:D:D saysQuote:
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'.
I look forward to seeing this - and welcome to the dark side :wave: ;)Quote:
Originally Posted by Niya
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.Quote:
Originally Posted by VB6 Programming
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.
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.Quote:
Originally Posted by VB6 Programming
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.Quote:
Originally Posted by 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.
While TwinBasic is similar to VB6, it is different - so the VB6 forum is not right, and OtherBasic is the place.Quote:
Originally Posted by Niya
If it becomes popular (as it looks like it might), we would certainly consider a specific forum for TwinBasic.
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.Quote:
Originally Posted by VB6 Programming
I thought as much.Quote:
Originally Posted by si_the_geek
Oooo...Thanks for the mention. Appreciate it. :thumb:Quote:
Originally Posted by VB6 Programming
@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:-
I describe the worrying behavior in the comments.Code: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
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.Quote:
Originally Posted by Niya
BTW, if you add a Class_Terminate Sub to the class, you'll see the object get destroyed at the correct point:
Code: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.Quote:
Originally Posted by WaynePhillipsEA
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:-
You can use it like this:-Code: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
This method works in VB6 so I expect it would be acceptable in TwinBASIC as well.Code:Dim myObject As New Class1
Dim clonedRef As Class1
Set clonedRef = PtrToObject(ObjPtr(myObject))
Early integration of twinBasic with a VB.NET form designer from VB6Namespaces.
https://www.youtube.com/watch?v=xchMTBjf96I
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?Quote:
Originally Posted by TTn
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! ThanksQuote:
Originally Posted by WaynePhillipsEA
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.Quote:
Originally Posted by TTn
Right, that's what I thought but wasn't sure with the interop from my end.Quote:
Originally Posted by WaynePhillipsEA
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.Quote:
Originally Posted by TTn
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.Quote:
Originally Posted by WaynePhillipsEA
Here's a teeny tiny very minor suggestion. A better way to do this:-
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 &h0000FFFFCode:public function LOWORD(byval value as long) as integer
return value and clng("&hffff")
End Function
This exact function in VB.Net would look like this:-
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.Code:Public Function LOWORD(ByVal value As Integer) As Short
Return value And &HFFFFI
End Function
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, &:Quote:
Originally Posted by Niya
&HFFFF&
Ah. Sweet. That never occurred to me to try that. I feel dumb for that :(Quote:
Originally Posted by 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:-
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.Code: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
Good work on generics by the way. It works fantastic otherwise.
I just ran into a problem caused by the old world of VB6 clashing head first into the new world of TwinBASIC:-
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.Code: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
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 :mad:. By making it optionally explicit, you can solve problems like what I described above and maintain backward compatibility with VB6 at the same time.
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.Quote:
Originally Posted by Niya
We can't make Set optional since in classic VB it is valid to do things likeQuote:
Originally Posted by Niya
where the semantics are different toCode: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.Code:Set MyVariant = MyObject
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.
In VB6 we usually directly use vbaObjSetAddref export from msvbvm60 to hydrate weakrefs (raw ObjPtr pointers) like thisQuote:
Originally Posted by Niya
. . . which automagically takes care of the refcount staying correct.Code: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
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>
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)Quote:
Originally Posted by wqweto
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.Quote:
Originally Posted by WaynePhillipsEA
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.Quote:
Originally Posted by WaynePhillipsEA
IsObject is not the only issue. This solution also requires that you use Variants internally:-Quote:
Originally Posted by WaynePhillipsEA
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.Code: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
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:Quote:
Originally Posted by wqweto
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.Code:Private Class OtherClass(Of T)
Private g_myField As T
Public Sub SomeMethod(ByVal value As T)
AutoSet g_myField = value
End Sub
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)