TwinBasic

[wqweto]

> I resorted to Bing's Copilot to discover that Scripting.Dictionary does NOT have a default method/property. But VB6 thinks it does.

Why don't you decompile the typelib to source IDL and check yourself? Start OleView.exe, choose File->View TypeLib, select C:\Windows\SysWOW64\scrrun.dll. In the source IDL find IDictionary interface declaration and search for DISPID = 0 i.e. this signifies default prop/method.

Here is the relevant snippet:

    [
      odl,
      uuid(42C642C1-97E1-11CF-978F-00A02463E06F),
      helpstring("Scripting.Dictionary Interface"),
      helpcontext(0x00214b22),
      hidden,
      dual,
      oleautomation
    ]
    interface IDictionary : IDispatch {
        [id(00000000), propputref, helpstring("Set or get the item for a given key"), helpcontext(0x00214b3a)]
        HRESULT Item(
                        [in] VARIANT* Key, 
                        [in] VARIANT* pRetItem);
        [id(00000000), propput, helpstring("Set or get the item for a given key"), helpcontext(0x00214b3a)]
        HRESULT Item(
                        [in] VARIANT* Key, 
                        [in] VARIANT* pRetItem);
        [id(00000000), propget, helpstring("Set or get the item for a given key"), helpcontext(0x00214b3a)]
        HRESULT Item(
                        [in] VARIANT* Key, 
                        [out, retval] VARIANT* pRetItem);
        [id(0x00000001), helpstring("Add a new key and item to the dictionary."), helpcontext(0x00214b3c)]
        HRESULT Add(
                        [in] VARIANT* Key, 
                        [in] VARIANT* Item);
...

Yes, Item property is the default property. Lets look in VBx in Object Browser pane:



Do you see the blue dot? This is the marker for default property and it's on Item property.

Now let's test TB some of the later BETAs (e.g. 546)

Class Form1

    Sub New()
    End Sub
    
    Private Sub Form_Load()
        Dim dict As Object
        Set dict = CreateObject("Scripting.Dictionary")
        
        dict("aaa") = 42
        Debug.Print dict("aaa")
    End Sub
    
    Private Sub Form_Click()
        Dim dict As Dictionary
        Set dict = New Dictionary
        
        dict("aaa") = 42
        Debug.Print dict("aaa")
    End Sub
    
End Class

Both events work as expected.

> Some guidance will be appreciated on how to approach this from people with background who are active on Discord.

You can approach this very easy -- just make a simple project with 10-20 lines of code which demostrates the problem, i.e. which clearly shows there is no default property on Dictionary in VBx or TB.

With TB this is even easier -- it's enough to come up with a snippet which works differently in VBx vs TB because the target of TB is to be 100% compatible with VBx which means bug for bug compatible, even wart for wart.

cheers,
</wqw>

[Antix]

@fafalone - thanks for your reply, and I hear you. I do avoid Discord until I am absolutely certain I have a issue. Wayne has enough on his plate . . .

[Antix]

@wqweto - thanks for the trouble you took to reply. I learned more than three things from it. The fourth thing is to poke at the problem to narrow it down.
What I discovered shed more light on the actual problem and I should have picked up on it earlier. GCUser99 reported on GitHub that there was an issue related to Default Property in a Collection because I experienced a similar issue. But this was related to Dictionary.

So I did what you suggested and stripped the code. Bottom line is that Dictionary (and Collection) does not behave when it is embedded in a UDT. That is where my issue arose. The code works in VBA and VB6, but not in tB.

For clarity, I have included my code sample below. In this form, it fails at the indicated line. If you swap over the commented lines to take the declaration out of the UDT, it works as default and as specified method.

Class Form1

    Private Type TIniIO
      IniData        As Scripting.Dictionary   ' Object
      IniSection     As Scripting.Dictionary   ' Object
    End Type
    Private this     As TIniIO

    ' Private IniData        As Scripting.Dictionary   ' Object
    ' Private IniSection     As Scripting.Dictionary   ' Object
    
    Sub New()
      Dim alldata     As String
      Dim record()    As String
      Dim setting()   As String
      Dim i           As Long
      Dim sz          As Long

      Set this.IniData = CreateObject("Scripting.Dictionary")
'      Set IniData = CreateObject("Scripting.Dictionary")

      alldata = "[Configuration]" & vbCrLf & "Filename = ABC"

      record = Split(alldata, vbCrLf)
      For i = LBound(record) To UBound(record)
        If (InStr(record(i), "[") > 0) And (InStr(record(i), "]") > 0) Then
          SetSection Trim(Replace(Replace(record(i), "[", ""), "]", ""))
        ElseIf InStr(record(i), "=") > 0 Then
          ReDim setting(2) As String
          sz = InStr(record(i), "=")
          setting(LBound(setting)) = Trim(Mid(record(i), 1, sz - 1))
          setting(UBound(setting)) = Trim(Mid(record(i), sz + 1))
          If this.IniSection Is Nothing Then SetSection "default"
'          If IniSection Is Nothing Then SetSection "default"
          this.IniSection.Add Trim(setting(LBound(setting))), Trim(setting(UBound(setting)))
'          IniSection.Add Trim(setting(LBound(setting))), Trim(setting(UBound(setting)))
        End If
      Next
    End Sub
  
    Public Sub SetSection(ByVal isection As String)
      If Not this.IniData.Exists(isection) Then
        Set this.IniSection = CreateObject("Scripting.Dictionary")
        this.IniData.Add isection, this.IniSection
      End If
      Set this.IniSection = this.IniData(isection)           ' <== this fails at runtime (Default property)
      Set this.IniSection = this.IniData.Item(isection)      ' this succeeds
    End Sub
    ' Public Sub SetSection(ByVal isection As String)
    '   If Not IniData.Exists(isection) Then
    '     Set IniSection = CreateObject("Scripting.Dictionary")
    '     IniData.Add isection, IniSection
    '   End If
    '   Set IniSection = IniData(isection)
    ' End Sub
    
    Private Sub Form_Click()
      Dim i As Long
      Dim j As Long
      Dim s As String
      Dim a() As Variant
      Dim b() As Variant
      s = ""
      a = this.IniData.Keys
      For i = 0 To this.IniData.Count - 1
        If Len(s) > 0 Then s = s & vbCrLf
        s = s & "[" & a(i) & "]"
        Set this.IniSection = this.IniData.Items(i)
        b = this.IniSection.Keys
        For j = 0 To this.IniSection.Count - 1
          If Len(s) > 0 Then s = s & vbCrLf
          s = s & b(j) & " = " & Replace(this.IniSection.Items(j), vbTab, vbCrLf & Space(Len(b(j)) + Len(" = ")))
        Next
      Next
      ' a = IniData.Keys
      ' For i = 0 To IniData.Count - 1
      '   If Len(s) > 0 Then s = s & vbCrLf
      '   s = s & "[" & a(i) & "]"
      '   Set IniSection = IniData.Items(i)
      '   b = IniSection.Keys
      '   For j = 0 To IniSection.Count - 1
      '     If Len(s) > 0 Then s = s & vbCrLf
      '     s = s & b(j) & " = " & Replace(IniSection.Items(j), vbTab, vbCrLf & Space(Len(b(j)) + Len(" = ")))
      '   Next
      ' Next
      Debug.Print s
            
    End Sub
    
End Class

[wqweto]

This looks promising. Could be an edge case with refs inside UDTs.

Can you trim it further? Just the UDT declaration and 1-3 lines which don’t work as expected in TB i.e. which require using explicit Item property getter.

[Antix]

This looks promising. Could be an edge case with refs inside UDTs.

Can you trim it further? Just the UDT declaration and 1-3 lines which don’t work as expected in TB i.e. which require using explicit Item property getter.

Class Form1

    Private Type TIniIO
      udtData        As Scripting.Dictionary   ' Object
      udtSection     As Scripting.Dictionary   ' Object
    End Type
    Private this     As TIniIO
        
    Sub New()
      Set this.udtData = CreateObject("Scripting.Dictionary")
      this.udtData.Add "Level00", CreateObject("Scripting.Dictionary")
      Set this.udtSection = this.udtData("Level00")           ' <== this fails at runtime (Default property)
      Set this.udtSection = this.udtData.Item("Level00")      ' this succeeds
      this.udtSection.Add "Level01", "ABC"

      Debug.Print "Case 00:" & this.udtData("Level00")("Level01")           ' this fails at runtime  
      Debug.Print "Case 01:" & this.udtData("Level00").Item("Level01")      ' this fails at runtime
      Debug.Print "Case 02:" & this.udtData.Item("Level00")("Level01")      ' this succeeds
      Debug.Print "Case 03:" & this.udtData.Item("Level00").Item("Level01") ' this succeeds
                        
    End Sub

End Class

Executing '[Form1].Show()'...
Case 02:ABC
Case 03:ABC
[DEBUGGER] Waiting for remaining forms to close...
(time taken: 7.0498795s)

I trimmed this down to identify only those situations that failed. I ran the code from the IDE and used Ignore-Resume Next option. Surprisingly, it is the outer level that does not recognise the Default Method (Case 00 & Case 01).
I tested with many other variations - Global declaration: iniData As Scripting.Dictionary and iniData As Object and a local declaration lclData As Object. I all of these, my test cases succeeded.
I did the extra tests because GCuser99 on Discord uncovered a similar failure that he reported on GitHub #1724 and I hoped to include his evidence here. But, using Strings as the final object did not fail using code similar to his. So I think his circumstance will need its own investigation.
But, both he and I experienced this (or similar) issue when iniData (Dictionary) is declared as a Collection.

[AAraya]

Instead of VisualBasic for Applications or its equivalent TwinBasic for Applications, just use TwinBasic 4 Application

The four uses of TB:

1. VB6 replacement
2. VBScript replacement
3. VBA replacement
4. and the fourth being... hmmm a successor to VB.NET... just grabbing things from the air, JSCRIPT alternative, I don't know.

or plain and simple: a TwinBasic 64 Application, it sounds almost the same and it has 'four' in the name.

My MAIN reason for looking into twinBasic as a replacement for VB6 is to continue development and support for my company's VB6 products. Sadly, none of them can be imported successfully into twinBasic. I am able to import only small utilities.

I'm sure that Wayne is hard at work on new features but for my use case, this is not a viable VB6 replacement until it can handle my large, complex apps. I think that more focus needs to be spent on that, if you want to draw more to twinBasic. I know I would seriously consider switching over 100% right now, if my apps worked in tB.

[wqweto]

Class Form1

    Private Type TIniIO
      udtData        As Scripting.Dictionary   ' Object
      udtSection     As Scripting.Dictionary   ' Object
    End Type
    Private this     As TIniIO
        
    Sub New()
      Set this.udtData = CreateObject("Scripting.Dictionary")
      this.udtData.Add "Level00", CreateObject("Scripting.Dictionary")
      Set this.udtSection = this.udtData("Level00")           ' <== this fails at runtime (Default property)
      Set this.udtSection = this.udtData.Item("Level00")      ' this succeeds
      this.udtSection.Add "Level01", "ABC"

      Debug.Print "Case 00:" & this.udtData("Level00")("Level01")           ' this fails at runtime  
      Debug.Print "Case 01:" & this.udtData("Level00").Item("Level01")      ' this fails at runtime
      Debug.Print "Case 02:" & this.udtData.Item("Level00")("Level01")      ' this succeeds
      Debug.Print "Case 03:" & this.udtData.Item("Level00").Item("Level01") ' this succeeds
                        
    End Sub

End Class

Executing '[Form1].Show()'...
Case 02:ABC
Case 03:ABC
[DEBUGGER] Waiting for remaining forms to close...
(time taken: 7.0498795s)

I trimmed this down to identify only those situations that failed. I ran the code from the IDE and used Ignore-Resume Next option. Surprisingly, it is the outer level that does not recognise the Default Method (Case 00 & Case 01).
I tested with many other variations - Global declaration: iniData As Scripting.Dictionary and iniData As Object and a local declaration lclData As Object. I all of these, my test cases succeeded.
I did the extra tests because GCuser99 on Discord uncovered a similar failure that he reported on GitHub #1724 and I hoped to include his evidence here. But, using Strings as the final object did not fail using code similar to his. So I think his circumstance will need its own investigation.
But, both he and I experienced this (or similar) issue when iniData (Dictionary) is declared as a Collection.

I just copy/pasted your code in an empty Std-EXE project and this fails at runtime lines never fail here. Both 32 and 64-bit targets, both when traced with F8 and run w/ F5 in the IDE.

How can I reproduce this failure at run-time? By "at run-time" do you mean when compiled to EXE?

I want to report this on Discord but I cannot report non-failing test case. Would like to strip it to 2-3 lines too.

cheers,
</wqw>

[WaynePhillipsEA]

I just copy/pasted your code in an empty Std-EXE project and this fails at runtime lines never fail here. Both 32 and 64-bit targets, both when traced with F8 and run w/ F5 in the IDE.

How can I reproduce this failure at run-time? By "at run-time" do you mean when compiled to EXE?

I want to report this on Discord but I cannot report non-failing test case. Would like to strip it to 2-3 lines too.

cheers,
</wqw>

Looks like a recent regression. Works in BETA 555, not working in 556.

[WaynePhillipsEA]

Fixed in BETA 565. Thanks.

[WaynePhillipsEA]

My MAIN reason for looking into twinBasic as a replacement for VB6 is to continue development and support for my company's VB6 products. Sadly, none of them can be imported successfully into twinBasic. I am able to import only small utilities.

I'm sure that Wayne is hard at work on new features but for my use case, this is not a viable VB6 replacement until it can handle my large, complex apps. I think that more focus needs to be spent on that, if you want to draw more to twinBasic. I know I would seriously consider switching over 100% right now, if my apps worked in tB.

twinBASIC can handle large complex apps, but it can't handle *all* large complex apps yet. Given its BETA state, one should expect that.

If you want to assist, then do please open bug reports for the issues that you find. That way you can be sure they will get attention.

[wqweto]

Looks like a recent regression. Works in BETA 555, not working in 556.

Oops, my bad testing w/ BETA 546 and can't repro. Glad you sorted it out anyway.

cheers,
</wqw>

[AAraya]

twinBASIC can handle large complex apps, but it can't handle *all* large complex apps yet. Given its BETA state, one should expect that.

If you want to assist, then do please open bug reports for the issues that you find. That way you can be sure they will get attention.

Hi Wayne,

I'm sure it can handle some, maybe even most? But I can only speak of my experiences and I'm 0 for 3 with importing my large apps. I don't mean this as a sleight of your incredible, herculean efforts to pull off what no one thought someone would. I'm just providing candid feedback as to what my main issue is so that as you're developing the roadmap forward, you consider not only new features but also continue to whittle away at backward compatibility issues.

I already submitted an app that has issues several weeks ago - the easiest one to strip down to a basic state which reproduces the problem. Once that gets resolved I'll see if the fix helps with my other larger apps. As you know, preparing an app to send over to your team takes time. I'm in the middle of development right now so making the time for that is not on my priority list at the moment.

[fafalone]

Lots of compatibility fixes just this week. A bug with a commonly used typelib-substitute DispCallFunc method was fixed, which was blocking dozens of apps I had tried to run that all work now. The mouse events ByVal/ByRef incompatibility was fixed. Array default methods a few comments up. And work on missing control features finally made some progress, with CommandButton .Default and .Cancel.

MDI forms were recently added, checking off one of the last handful of major missing pieces.

As much as I love new features I'm glad to see some major work on VB6 compat too, definitely been too long for full compatibility to feel so close but just out of reach. It is tough to get the balance right though; personally I think it was absolutely the right choice to mix working on compatibility and new features; if all tB did was 'less than VB', there might have been a lot less interest for a major part of the development time. Definitely was the new features that got me interested; probably wouldn't have paid much attention until it started getting them.

[yereverluvinuncleber]

You should never expect any code to function when using an Alpha/beta product. It is shocking to hear of anyone making urges for it to "work better" at this stage. It implies a misunderstanding of the development stage that TB64 is in. You wouldn't expect to drive a car where the brakes weren't fully implemented, largely untested and might fail, same with TB64.

When TB64 hits production I expect that it will operate with most tests and lots of real-world code but you can bet there will still be edge cases and missing fundamental functionality that hasn't been taken into account. That is my expectation anyway. The good thing is that TB64 has phenomenal support and these issues will be fixed, just not NOW.

If you do try your code now and it fails the test, then that is GOOD thing to occur. A test fail is a good event to happen during development. It discloses a bug so that it can now be raised and fixed. AArya, alter your understanding of this stage, your perception of the product and lower your expectations and post accordingly.

[fafalone]

I don't think it's unreasonable to think of development substages like early/mid/late alpha and beta... once you get to late beta, it's not at all unreasonable to see something as nearing completion to the point the remaining missing features and issues are minor; and that's hardly an unusable state.

It's like you were instead building a car factory. It might not be able to make every kind of car yet, but why wouldn't you use it for the cars it can make, if the bugs and missing features are minor enough or non-existent?

tB is in late beta; it's close enough to production ready it's useful for a lot of things beyond just experimenting and testing.

[Chenzen]

I REALLY love this project, its sooo awesome :-) The only drawback for me is the design of the IDE, i much prefer something like Rad basic(just for the design, everything else is better on tB) it looks like a web application i find it odd.

This project with radbasic design would be fire.

[WaynePhillipsEA]

I REALLY love this project, its sooo awesome :-) The only drawback for me is the design of the IDE, i much prefer something like Rad basic(just for the design, everything else is better on tB) it looks like a web application i find it odd.

This project with radbasic design would be fire.

Thanks for your feedback. FYI, twinBASIC IDE *is* a web-stack based application (uses JS+HTML on WebView2). It's designed this way so that the IDE will run very easily on any platform... Linux/Mac/Android as soon as the associated compilers are ready. As such, the IDE will be familiar, appearing exactly the same on each platform.

[Chenzen]

Thanks for your feedback. FYI, twinBASIC IDE *is* a web-stack based application (uses JS+HTML on WebView2). It's designed this way so that the IDE will run very easily on any platform... Linux/Mac/Android as soon as the associated compilers are ready. As such, the IDE will be familiar, appearing exactly the same on each platform.

Oh i see ! Clever choice indeed :-) The syntax color highlight is perfect, Couldnt use VB6 ide anymore because my eyes can't stand white screen but thanks to you i can code in vb6 again ! Thanks and continue the great work you are amazing.

[Thierry69]

Just made a small app.
I imported 3 of my OCX (not the included one) :
- a frame
- a Textbox
- a Button

I droped a frame, with 2 textbox & 1 button

the frame is a container, and the Tab key (and Shift Tab) is not doig navigation within my own frame

[SearchingDataOnly]

Wayne took all the work off and showed amazing development efficiency.

But there's just so much work that needs to be done to go from beta to maturity in a programming language that includes IDE and Runtime. I think it's a huge regret that Wayne missed the collaboration with Olaf. IMO, if Wayne and Olaf cooperate, there will be a "1 + 1 > 3" effect, that is, the development progress will be 3 times that of the current.

[OptionBase1]

Wayne took all the work off and showed amazing development efficiency.

But there's just so much work that needs to be done to go from beta to maturity in a programming language that includes IDE and Runtime. I think it's a huge regret that Wayne missed the collaboration with Olaf. IMO, if Wayne and Olaf cooperate, there will be a "1 + 1 > 3" effect, that is, the development progress will be 3 times that of the current.

Maybe 1 + 0 > 4

[AAraya]

You should never expect any code to function when using an Alpha/beta product. It is shocking to hear of anyone making urges for it to "work better" at this stage. It implies a misunderstanding of the development stage that TB64 is in. You wouldn't expect to drive a car where the brakes weren't fully implemented, largely untested and might fail, same with TB64.

When TB64 hits production I expect that it will operate with most tests and lots of real-world code but you can bet there will still be edge cases and missing fundamental functionality that hasn't been taken into account. That is my expectation anyway. The good thing is that TB64 has phenomenal support and these issues will be fixed, just not NOW.

If you do try your code now and it fails the test, then that is GOOD thing to occur. A test fail is a good event to happen during development. It discloses a bug so that it can now be raised and fixed. AArya, alter your understanding of this stage, your perception of the product and lower your expectations and post accordingly.

I'm sure I was not clear in my post. Let me clarify.

1. I think what Wayne has achieved with tB is incredible. He's proven that it is possible to create a successor to VB6!
2. The amount of progress he's made with minimal assistance is unfathomable and to be commended

The point of my post was driven by my watching the daily release notes to see what was being worked on and looking at the development roadmap - I didn't see much emphasis on backward compatibility in terms of making sure that most/ALL current VB6 programs can be imported and run. This is the MAIN thing that would stop me from switching over from VB6. It's a very real issue for me as none of my large apps can be imported at this time. I imagine that the issue would be a barrier to adoption for others as well. I felt it important to chime in and let Wayne know that. Not in a complaining way but in a provide feedback way.

I don't have an expectation that all the issues should be ironed out in BETA.

[fafalone]

Wayne took all the work off and showed amazing development efficiency.

But there's just so much work that needs to be done to go from beta to maturity in a programming language that includes IDE and Runtime. I think it's a huge regret that Wayne missed the collaboration with Olaf. IMO, if Wayne and Olaf cooperate, there will be a "1 + 1 > 3" effect, that is, the development progress will be 3 times that of the current.

With Olaf's views about what the future of VB6 should be I'm not too disappointed; he doesn't seem like he would be willing to drop the whole RC6 and no native, VB-compatible UI things.

---
The lack of a true Win32 UI for the IDE was quite an adjustment, but especially with the new revamped post-423 IDE I've largely gotten comfortable with it as a daily driver; the modern editor amenities help a great deal with that. But @Chenzen, it's nowhere near as sophisticated as tB but you do know VB6 does have some color options, right? A few years back I changed it to a black editor background. There's addins that even allow using arbitrary colors instead of the small set in the built in editor; I made mine look more like tB lol

[Schmidt]

With Olaf's views about what the future of VB6 should be I'm not too disappointed...

A VB6-successor will have no (long-term) future, when it is not working on multiple platforms (Win, Linux, Mac) - period.
(and since its a "visual language" - this includes *all* the underlying GUI-mechanisms - e.g. for VB-implemented "UserControls or Widgets").

...he doesn't seem like he would be willing to drop the whole RC6 and no native, VB-compatible UI things.

You still don't understand the importance of it (due to lack of interest in OS-architectures and "structural, software-engineering"-things) -
but (as said earlier already) this might change, as soon as Wayne starts working on the Linux-support for real...
I leave it to Wayne, to educate you then, about all the up-cropping problems, when the time for it arrives...

To give just one example... your current knowledge about shell32.dll or comctl32.dll (and their accompanying typelibs) -
will worth nothing on the Linux-platform ... 98% of the current pool of "It works with TB"-Demo-Apps will not compile.

With that in mind, you might want to think about, on what basis e.g. a "native, tb-implemented UserControl" shall work,
so that the implementing "VB-drawing-primitives" will work on *all* platforms (without any changes, no matter for which platform you compile it).

And once you have developed such "nice, platform independent working" GUI- and native UserControl-modules+Classes -
what reason is there, to not develop the whole IDE based on *that* (and not on top of a Browser-engine, Electron-like).

There's quite a lot of things in the meantime, which do not make any sense to me (engineering- and management-wise) at the tb-Front...
(when the goal still remains, to make it a platform-independent tool in the end...).

What's happening currently, is only useful when TB remains a "Windows-only-tool"
(for a dying-out community of on average 60years old "Win-only VB-devs", which might carry it along for a decade or two - but not more).

Just my $0.02 on that matter...

Olaf

[fafalone]

Yes thank you Captain "Professional" for the great wisdom of informing me Windows APIs only work on Windows and not Linux.

I understand the important of cross platform ability, but I don't think you understand the importance of existing apps that are for Windows to begin with to continue to work as-is. 'Rewrite the entire UI *first*' is too high a barrier to bringing in existing code. Without UI compatibility, people probably won't even be interested in taking the first step into a successor at this point, let alone jumping to cross platform.

[Schmidt]

Yes thank you Captain "Professional" for the great wisdom of informing me Windows APIs only work on Windows and not Linux.
I understand the important of cross platform ability, ...

If you really understand that, then why does e.g. a "WinDev-lib" even exists?

FYI, the codebase of a TB-App, which really is "portable between platforms", shall have not a single API-Declare,
which points to any Win-only-Flat-Dll (among them "kernel32", "user32", "shell32", "comctl32").

I don't think you understand the importance of existing apps that are for Windows to begin with to continue to work as-is.

Is it really that important, as you make it out to be?
FYI, the most compatible compiler for existing VB6-code is still VB6.exe!

And I dare say, that even in 10 years, the 32Bit-Apps this existing (and near bug-free) compiler produces,
will still "continue to work" (on a then Win12 or Win13).

Our remaining, small community of then - "on average 70year old VB6-devs" will appreciate to still have this option, I guess.

What I'd like to see survive long-term - is "VB6 and its visual concepts" (a re-incarnation, attractive for "younger devs") -
whereas Wayne seems to give too much weight to the opinions of a "loud, but nevertheless shrinking community - nearing retirement"
(wasting whole years with "Win-only stuff", on a "compatibility" which is not really needed - because VB6.exe is still there).

Olaf

[fafalone]

If you really understand that, then why does e.g. a "WinDev-lib" even exists?

FYI, the codebase of a TB-App, which really is "portable between platforms", shall have not a single API-Declare,
which points to any Win-only-Flat-Dll (among them "kernel32", "user32", "shell32", "comctl32").

Because *I* understand the importance of continued support for Windows development too, and got tired of doing API declares the old way of grabbing them one or a few at a time for new projects or having to write new ones for platform built-in stuff.

And thanks for restating the shocking revelation that any *Windows API declares* will not work *on Linux*. Maybe one day someone will learn that for the first time from you.

Is it really that important, as you make it out to be?
FYI, the most compatible compiler for existing VB6-code is still VB6.exe!

And I dare say, that even in 10 years, the 32Bit-Apps this existing (and near bug-free) compiler produces,
will still "continue to work" (on a then Win12 or Win13).

Our remaining, small community of then - "on average 70year old VB6-devs" will appreciate to still have this option, I guess.

What I'd like to see survive long-term - is "VB6 and its visual concepts" (a re-incarnation, attractive for "younger devs") -
whereas Wayne seems to give too much weight to the opinions of a "loud, but nevertheless shrinking community - nearing retirement"
(wasting whole years with "Win-only stuff", on a "compatibility" which is not really needed - because VB6.exe is still there).

Olaf

Yes, yes it is as important as I've made it out to be. And of course VB6.exe will be the *most* compatible, but it won't ever be updated to add any new features. Almost everyone has wanted something new in the language. We know 32bit support will be around for decades to come, but that doesn't mean the VB6 runtime in particular will (vbscript is being phased out already... the day will come when msvbvm60.dll will become deprecated like that and stop shipping with Windows; then sometime after that, things in it will start breaking in newer Windows versions and won't be fixed).

Do you have any evidence besides your own opinion that there's a huge number of people who want *some* VB6 compatibility, but don't care to have their Windows UIs continue to work because all they care about is going cross-platform, and nothing else? I think if that was a popular opinion we'd here somebody besides you giving it, and with enough support maybe the priority order for tB would have changed. Or do you think these are people not currently in the VB community, but would come running to use it back from wherever they are now?

Again, everyone knows cross-platform support is increasingly important, but compatibility is more important. There just not a huge market for "VB6-compatile, but only non-API code"; their needs are being met by other languages. A working ecosystem of upgraded VB6 full compatibility with cross platform *potential* is a draw. But you're making the barrier for entry a mountain so high you may be alone climbing it.

[SearchingDataOnly]

I agree more with Olaf. But the problem is that Wayne has spent too much time on compatibility, too much time on details, too much time on the Win platform. Well, he is now riding a tiger (getting off a tiger is not an easy task), and he can only continue to work hard and release the official version twinBasic-1.0 as soon as possible. When the official version of twinBasic is successful in the market, Wayne needed to bring in external capital and build a full-time development team to work on cross-platform compiler, cross-platform UI-libs and cross-platform IDE.

[yereverluvinuncleber]

Someone is actually doing something and telling us the progress and I'm happy with that, ie Wayne with TB64. VB is at last going somewhere. Before, it was largely going nowhere despite the efforts of many fixing it up in the form of various additions in the codebank and online. VB now has an owner and a Project Manager who knows what he wants to achieve and a direction. He is making it work. That is a success.

Olaf made serious progress on the cross platform front with RC 5/6 but we have had no recent update regarding progress on what I call 'OlafBasic' (not sure what OlafBasic actually consists of, how much actually exists or is under development) but I'd love to have an update from Olaf on the progress of his magnum Opus. I use RC5/6 every day and appreciate it for what it is so far.

Wayne is correct in his decision that TB64 needs to replicate VB6 and all its foibles to fill a perceived gap in the market due to VB6 entering 'legacy mode', Olaf is also correct in that VB6 needs a cross platform future to survive in the longer term. There is some conflict between the two directions but these won't be resolved by arguing about them. Wayne is taking steps in a direction and perhaps the cross compatibility aim will suffer in the medium term but I have confidence that a direction/solution will reveal itself. Wayne will tell us his plans when he is ready.

I've always said we ought to contribute to a group goal but this group can't work together, that is evident.

I am hoping that RC and TB64 have a future together and possibly some sort of symbiosis toward that aim of cross compatibility. I hope it will at the very least continue to work...

There really isn't a battle here, it is just how we do it and step by step, perhaps we can make progress. If would be nice if you lot here could let bygones be bygones and not battle over it all. It isn't constructive.

[fafalone]

"I tried my program and it didn't work" is the number one thing turning people off to tB.

I just have a hard time believing "I tried my program and it didn't work, but if I rewrite the entire UI first and everything else dependent on Windows, maybe it will, or maybe it still won't" ('OlafBasic' almost certainly won't support internals-hacking asm thunks or obscure undocumented msvbvm60 calls either, so the 'maybe it won't' is inevitable) is something people are clamoring for. It's just not realistic that people looking for a VB6 replacement in 2024 or later are interested in major rewrites of existing code before they can even run it. And without a lot of existing work to get people interested, why would a non-VB6 person suddenly want a VB6 replacement?

[Semke]

i keep getting this error when adding available packages

twinBASIC Internal Error 33330 : IDE was unable to read builtin package file data

[WaynePhillipsEA]

i keep getting this error when adding available packages

twinBASIC Internal Error 33330 : IDE was unable to read builtin package file data

Most likely, you've extracted the IDE zip file content over an old version of the IDE. You must extract the zip file cleanly into a new location.

[VB6 Programming]

twinBASIC status update:

twinBASIC Update: June 24, 2024

Highlights include a new multi-line caption-editing dialog, implementation of several missing VB6 control properties, and advanced pointer handling via CType(Of ).

https://nolongerset.com/twinbasic-update-june-24-2024/

[yereverluvinuncleber]

(for a dying-out community of on average 60years old "Win-only VB-devs", which might carry it along for a decade or two - but not more).

Just an observation, these 60 year old devs might have a bit of technical 'clout' being in the business so many years. Some of them will have influence in making a suggestion here and there. In addition, this thread has received over a million views, that is an indication of how popular a subject TwinBasic is. Bear in mind, this little forum of a few win-only VB devs, is generating a lot of hits on a subject that at least some of the world, finds quite interesting.

[fan2006]

bug with lenb when non-english characters used in udt .

[xiaoyao]

Just an observation, these 60 year old devs might have a bit of technical 'clout' being in the business so many years. Some of them will have influence in making a suggestion here and there. In addition, this thread has received over a million views, that is an indication of how popular a subject TwinBasic is. Bear in mind, this little forum of a few win-only VB devs, is generating a lot of hits on a subject that at least some of the world, finds quite interesting.

The forum does not allow twinbasic questions or technical articles or code libraries to be displayed in the VB6 section, which is a big loss. It would also be good if this topic or questions about TWINBASIC could be pinned to the top and displayed in the VB6 topic category.
In fact, every question about the TWINBASIC release and every code bank module file should be displayed in the VB6 topic category at the same time, because the two are almost the same.
At the same time, TWINBASIC should be displayed on many other forums and community websites, such as python, linux, vb.net, excel vba, office automation, WEBIDE, JAVASCRIPT, C# and other community categories for posting and asking for help. Twinbasic should be everywhere.

What is the positioning of TWINBASIC? Replace VB6 to develop some gadget software? Or develop cross-platform software and develop scripts instead of powershell, like AutoHotkey.exe and AutoIt3.
Maybe its function is like python, enabling rapid development, and it is similar to an IDE like codeblocks, which can quickly develop some EXE programs like VC++.
In the future, the web version of the IDE will not run on the Windows system. You can directly open the web page on your mobile phone to use the purchase, sales and inventory software, ERP management software, and the web version of the remote desktop to directly operate the WIN10 system on the Amazon cloud server.
python, javascript, node.js, java, c# rule everything, vb6, vb.net, twinbasic are becoming more and more difficult to follow.
In another 20 years, maybe our generation of VB programmers will all leave the world, and no one will use the VB language anymore?

[fafalone]

tB:VB6::VB6:VB1. Of course, think of the chaos if 99% of the forum was VB1 because most people weren't ready to upgrade to VB6

[xiaoyao]

twinbasic,
form1.printform,Do not know if this method has been implemented?
I used Vb6 to add some tags and three images. As a result, when printing, the text of this tag is always out of focus. Sometimes it becomes left-aligned, and sometimes the text is not fully displayed.

Because the size of this print is very small, it is a supermarket label, but it also needs to print two two-dimensional code pictures.
It is mainly about the printing system of BB, as well as the font size and size of the text

[VB6 Programming]

twinBASIC status update:

twinBASIC Update: July 3, 2024

Highlights include initial Printer object support, a new PDF Merge utility from fafalone, and an answer to one redditor's burning question.

https://nolongerset.com/twinbasic-update-july-3-2024/

[xiaoyao]

I agree more with Olaf. But the problem is that Wayne has spent too much time on compatibility, too much time on details, too much time on the Win platform. Well, he is now riding a tiger (getting off a tiger is not an easy task), and he can only continue to work hard and release the official version twinBasic-1.0 as soon as possible. When the official version of twinBasic is successful in the market, Wayne needed to bring in external capital and build a full-time development team to work on cross-platform compiler, cross-platform UI-libs and cross-platform IDE.

Perhaps the best choice is to be acquired by b4i, b4a development tools company, which implements Android app development, Apple app development, b4j Java interface and program development.They got a lot of venture capital money.