twinBasic Criticism

[Peter Swinkels]

Remembering tb being recommended I went to see where I could get a copy to see whether it had improved since I last tried it. Unfortunately I can't find the download link for the community edition, which btw apparently adds one of those obnoxious nag screens to your programs! Yay! (sarcasm) (By their very own admission on their tb webpage.)

[Peter Swinkels]

I found the download link... and what a waste of time. It crapped out on four different vb6 projects...

From their very own site:
"Seamless VB6 Compatibility"

LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL

Edit:
I submitted a few issues on their github and to be fair I did get a few vb6 programs to work with a bit of tweaking.

Edit 2:
It seems the splash (nag) screen only appears with 64-bit projects. Okay.

Btw:
I really don't like tb's ide, especially considering it is supposed to be a vb6 replacement/substitute.

[fafalone]

Don't know why you posted that in a thread about VBDOS but ok... (maybe mods can move your posts and my reply to the tB forum?)

...is "crapping out" how you describe App.Path not being quite right until after you save for the first time, just like VB6?

Or the minor PictureBox drawing glitch?

Yes there's a number of minor bugs, but all my apps run now, even the complex ones and ones that didn't a couple years ago, heck I just made a kernel mode minifilter driver in it... PhotoDemon runs now, someone was just celebrating their 270k line ActiveX DLL now working... commercial projects like XYPlorer and iGrid have working tB builds now... I'll go ahead and keep thinking tB is great for the 99% of things that work rather than think it's garbage because some things still don't while it's in beta, but to each their own.

Downloading... the twinbasic.com home page has a big red "DOWNLOAD NOW - GET STARTED" button that takes you straight to the Releases page with the latest version on GitHub. The twinbasic repo front page ought to point you to the Releases section that's right there... but it does take you to another page with a giant red "GET STARTED" button that leads straight to the Releases downloads. So it could use some simplification (I'll update it later) but hardly some labyrinthine mystery.

And yes since a project like this is way too big to be a spare-time freely distributed hobby project, there's some need for selling it. With no royalties or restrictions on commercial use for the Community Edition, and the only limitation being a splash screen on x64 binaries (and some experimental LLVM stuff is disabled)... real hard to characterize the terms as anything but generous.

IDE... The tB IDE is fully theme-able; did you look at the Classic theme? Below is the VB6 and tB default layout in classic theme side by side... should feel pretty familiar. The tB IDE has a ton of new, modern stuff that makes me way more comfortable and productive, which outweighs the few areas where the VB6 IDE is better-- just about exclusively with windowing; split window, multiple windows, window behavior. tB needs improvement there but with the advanced info popup, cold folding, global search, inline code hints... not even close.

[Peter Swinkels]

I call it a really annoying short coming, it breaks nearly every app I ever wrote and from what I can tell the IDE's error handling is awful. Some cartoony red error message box pops up and you're left guessing where the heck the error occurred. LOL

That webpage is one huge mess shouting about the glorious TB (how typical) is and if he wants to sell it I get that but there is no way in hell I am going to buy tb based on my current experience.

Fine, but the colors are just scratching the surface. I could make a list of what I don't like about the ide, did I mention it unnecessarily inserts brackets when I am typing code to name one?

EDIT:
Oh, here's another gem, those line numbers to the left of your code, I thought we left those behind, oh about four decades ago? Yes, yes they aren't part of the actual code, but still, why? In the extremely unlikely event I still gave a damn about the line number I'd look at the status bar.

[fafalone]

For most errors, and all errors immediately in your own code, it jumps to line or at least procedure; for that class of error, VB6 handles it worse; it quits. For syntax errors in code, tB is amazing compared to VB6... it lists them all at one time instead of leaving you hitting them one by one when trying to compile, and warns of lots of potential issues VB6 misses.

Bracket autoclose works pretty well now; I think there's 1 known issue with it? Or is the complaint it exists at all...


And seriously, code line numbers? This isn't constructive criticism, this is looking for anything bad you can possibly say. Every modern editor, including Visual Studio and VSCode, shows line numbers by default. You're literally complaining that tB isn't missing a feature every major IDE has. And it's just that, you being negative for the sake of being negative. I'm sure an option to hide line numbers can be added since the IDE is much more customizable than VB6 or VS, but since you're the first person to even express an interest in such a non-standard feature, it's not yet available. I'd bet anything if tB didn't have line numbers, you'd have been saying "Omg it's 2025 I can't believe it's been decades of modern IDEs having them but tB doesn't."

[Peter Swinkels]

If that's how you want to take it. Fine. Bye bye.

[fafalone]

Take care.

[dday9]

Posts spun off onto their own thread in the twinBasic forum. If anyone wants the original thread they were spun off from, you can find it here: https://www.vbforums.com/showthread....tions-in-VBDOS

[fafalone]

WindowScanner: Appears to work without modification.

Query Assistant: Nonfunctional in vb6 with Office16 refs substituted.

SLUDGE/Scale Calculator - Appears to work without modification.
SLUDGE/Screen Region editor - Serious windowing bug. Will add report.
SLUDGE/Script Object Viewer - Appears to work without modifications. I loaded several .slu files from OpenSLUDGE example projects.

Client-Server - First impression is it works-- Not going to dig into how to use this but starting it up and clicking a few things gives the same output as VB6.

Figures - Appears to work without modification.

Picture Viewer - Appears to work without modification. Viewed multiple images.

Get Environment Information - Works without modification.

Get Memory - Works without modification. Both VB6 and tB gave error 299 but produced identical files.



That's enough. tB obviously does not fail to run nearly every program you've ever written except a few that you had to modify to get to run. Unless your GitHub is all things you didn't write? I looked at the pinned VB6 apps then started down the list from the repo page, I wasn't being selective... 10 is enough to get a pattern; 8/10 worked and 1 of the other 2 didn't work in VB6 either because of numerous missing methods. It's one thing to give constructive feedback and make requests for improvements and new features, but you've clearly formed your opinion and only want to justify it.

[OptionBase1]

I trust you got a refund.

[vbrad]

I seem to recall someone saying that they were able to tweak the display settings so that the TwinBasic IDE looked very similar to the VB6 one.
Might not be a bad idea if that was built in as an easy to set option for crotchety vb6 users (like me!)

[Peter Swinkels]

I know that some of my previous messages were quite direct, but after reflecting on this topic, I’ve realized how important it is to me. I want to give the discussion another try and present my criticism of TwinBASIC in a clearer and more structured way to foster a constructive conversation.
===
Hello everyone,

I've been testing TwinBASIC as a potential replacement for VB6 and wanted to share my findings. I understand that it is still under development, and I appreciate the effort the developer has put into it. At the same time, I have noticed a few things that I believe are worth discussing. Perhaps others recognize these issues, or maybe I am missing some important context.

Here are the key points I've encountered:

The IDE lacks the clarity and user-friendliness of VB6.

Some fundamental features, which seem essential for a stable development environment, are not yet functioning properly.

While others may consider these issues minor, I find them quite disruptive.

I understand that TwinBASIC is developed in the developer’s free time, but at the same time, it is presented as a ready-to-use VB6 replacement and even offered for sale.

Given the previous point, I question whether TwinBASIC is truly ready for commercial release—I would be disappointed as a paying customer after reading the promises on the website.

Users who invest time, energy, and potentially money into a product expect their concerns to be acknowledged, even if they are not seen as a priority by the developer.

If I were a company relying on legacy VB6 software for crucial operations, I would hesitate to trust those processes to a development environment that, while promising, still needs to prove itself.

TwinBASIC is presented on its website (perhaps unintentionally) as something suitable for commercial use (since it is available for purchase), but in its current phase, it is primarily useful for technically skilled hobbyists rather than users looking for a stable and reliable tool.

Additionally:

You may feel proud of something you have programmed and believe you have put enough time and effort into making it work as intended, and that any issues can be addressed later. However, people looking for a solution for their specific needs are not concerned with that—if it doesn’t work for them, it doesn’t work. Would you invest time, effort, or even money in something that doesn’t meet your requirements, or simply wait for an issue to possibly be resolved at some point in the future, even though it is urgent for you?

I want to emphasize that I am not listing these points to be negative, but because I believe they are important when evaluating the future and development of TwinBASIC. I’m open to different perspectives and curious to hear what others think!

What are your thoughts?

[bahbahbah]

What are your thoughts?

Well, it is a beta. Things are still changing. People are paying for it now because it does the job for them.

The IDE lacks the clarity and user-friendliness of VB6.

examples?

Some fundamental features, which seem essential for a stable development environment, are not yet functioning properly.

examples?

it is presented as a ready-to-use VB6 replacement and even offered for sale.

Yes, it's also presented as a beta with a free version that you are welcome to test before you spend any money.

People that complain about free things, complain about betas not working, complain without giving examples are just lazy. If you want constructive discussion, bring concrete problems.

[WaynePhillipsEA]

OK, since your attitude and tone has changed quite considerably, I'll jump back in:

The IDE lacks the clarity and user-friendliness of VB6.

Fine, I would appreciate if you please give us actual examples, and then perhaps we can consider what we can do to improve.

Some fundamental features, which seem essential for a stable development environment, are not yet functioning properly. While others may consider these issues minor, I find them quite disruptive.

Fair point - we're in BETA development. Again, give us actual examples, otherwise I'm not sure how we're supposed to know what you're referring to.

I understand that TwinBASIC is developed in the developer’s free time, but at the same time, it is presented as a ready-to-use VB6 replacement and even offered for sale.

Everyone following the project understands that we are still in BETA. I believe nobody purchases a licence of a significant investment, such as a development environment, without trying out the latest version of the demo version, or in this case completely FREE community edition first. Inside the tB IDE, we make it very clear that the software that you are evaluating is a BETA product.

Additionally, at the top of every page on the twinBASIC website, says "Get ready for V1"... another clear indicator that we have not reached V1 status yet. Further, on the order form page, we say "pre-order" nine times on that page. If someone, somehow, misses the fact that we have not yet reached the stable V1 state of development, then there's not a great deal more that we can do.

I suspect almost everybody looking at the project fully understand that current pre-order licence purchases at this stage are helping support us toward the goal of reaching a stable V1 release. I can tell you that not a single order has had to be refunded on the basis that we are somehow mis-advertising the offering, and so I believe the status of the project is already quite clear and reasonable.

Given the previous point, I question whether TwinBASIC is truly ready for commercial release—I would be disappointed as a paying customer after reading the promises on the website.

It is absolutely not ready for commercial release. That's the whole point of us being in BETA(!). Again, developers purchasing licences understand that they are supporting us in the final stages of the BETA development.

Users who invest time, energy, and potentially money into a product expect their concerns to be acknowledged, even if they are not seen as a priority by the developer.

Absolutely, I agree, but I do take issue with what you are implying here. I was one of those that responded to your issue posted to GitHub. By responding, I've acknowledged it, and I told you that it would be dealt with in due course. There are many more open issues that we consider, at this time, to have higher priority than yours, and so unfortunately it won't be fixed *immediately*. It *will* get fixed, and it won't probably take that long. To imply that we didn't acknowledge it is just outright lying.

If I were a company relying on legacy VB6 software for crucial operations, I would hesitate to trust those processes to a development environment that, while promising, still needs to prove itself.

That's fine, you're entitled to that opinion. Come back some time later after v1 is released and the dust has settled.

TwinBASIC is presented on its website (perhaps unintentionally) as something suitable for commercial use (since it is available for purchase)

Nonsense, as already discussed. It is advertised as a pre-order offering for a product in BETA state, and as far as I'm concerned this is clearly communicated.

[fafalone]

I don't think tB can be much more clear that the status now is "Preview" and "Beta". The purchase is offered as "Pre-order" and the price presented as a discount applied for supporting the project in the preproduction phase. Each download is titled "twinBASIC BETA #".

With the IDE... a Find/Replace dialog just like VB6's was added because that's what everyone found most useful; and the Monaco widget left accessible for those who liked that. The Classic theme was added for people more comfortable with less syntax highlighting more like vb6 and other appearance tweaks for similarity. People's concerns *are* listened to. The bugs you report will be fixed. You could have just asked for an option to disable parentheses/bracket autoclose and to hide line numbers; but also bear in mind a lot of other people *want* those things, so they're likely to stay enabled by default. There's one or two issues with the autoclose, but I'm confident they'll be fixed before v1.0. Articulate what's a problem and how it can be improved, rather than ludicrous rants like line numbers are some archaic useless thing seriously hurting the IDE when this is a standard feature on by default in VS, VSC, Delphi RAD Studio, IntelliJ, NetBeans...

If you're a developer looking for solutions to your specific needs, cost and time are factors. Hiring new developers to rewrite from scratch in a mature language sometimes isn't practical for those and other reasons. It's also a long standing problem in software development that rewrites often lack features or edge case handling ability of the legacy software. There is no alternative to twinBASIC besides rewrite in a new language or keep holding onto vb6. So investing in its success is worthwhile for a lot of people who see staying on vb6 forever as untenable. And most understand the scope and difficulty of such an endeavor, and engage constructively by making bug reports and improvement requests, without crapping all over it because it doesn't run 100% of their own code perfectly right now in beta, like because of that it's completely hopeless and useless despite the fact it already runs a ton of stuff, runs a lot more than a year ago, and despite its beta status is *already* seeing commercial production use. Which btw if your business need is so urgent, a VIP license to get your bugs and feature requests to the front of the line is still far cheaper than a rewrite.

[axisdj]

I know that some of my previous messages were quite direct, but after reflecting on this topic, I’ve realized how important it is to me. I want to give the discussion another try and present my criticism of TwinBASIC in a clearer and more structured way to foster a constructive conversation.
===
Hello everyone,

I've been testing TwinBASIC as a potential replacement for VB6 and wanted to share my findings. I understand that it is still under development, and I appreciate the effort the developer has put into it. At the same time, I have noticed a few things that I believe are worth discussing. Perhaps others recognize these issues, or maybe I am missing some important context.

Here are the key points I've encountered:

The IDE lacks the clarity and user-friendliness of VB6.

Some fundamental features, which seem essential for a stable development environment, are not yet functioning properly.

While others may consider these issues minor, I find them quite disruptive.

I understand that TwinBASIC is developed in the developer’s free time, but at the same time, it is presented as a ready-to-use VB6 replacement and even offered for sale.

Given the previous point, I question whether TwinBASIC is truly ready for commercial release—I would be disappointed as a paying customer after reading the promises on the website.

Users who invest time, energy, and potentially money into a product expect their concerns to be acknowledged, even if they are not seen as a priority by the developer.

If I were a company relying on legacy VB6 software for crucial operations, I would hesitate to trust those processes to a development environment that, while promising, still needs to prove itself.

TwinBASIC is presented on its website (perhaps unintentionally) as something suitable for commercial use (since it is available for purchase), but in its current phase, it is primarily useful for technically skilled hobbyists rather than users looking for a stable and reliable tool.

Additionally:

You may feel proud of something you have programmed and believe you have put enough time and effort into making it work as intended, and that any issues can be addressed later. However, people looking for a solution for their specific needs are not concerned with that—if it doesn’t work for them, it doesn’t work. Would you invest time, effort, or even money in something that doesn’t meet your requirements, or simply wait for an issue to possibly be resolved at some point in the future, even though it is urgent for you?

I want to emphasize that I am not listing these points to be negative, but because I believe they are important when evaluating the future and development of TwinBASIC. I’m open to different perspectives and curious to hear what others think!

What are your thoughts?

Hello Peter,

You seem to have very high standards for what you expect, in such case I would assume you have written many 100K LOC apps + that adhere to what you expect from others.

Maybe you should use that energy of perfection and offer another alternative, as it sounds like you are highly capable of doing so.

As for me, both my 100K LOC apps load in TB and functionality is getting better every iteration, this is a long painful process, but no one else in the world has come as close to a solution than Wayne, NOT EVEN CLOSE.

Peter, Looking forward to hearing about progress on your next project, a vb6 replacement!

[VB6 Programming]

Hi Peter,

I know that some of my previous messages were quite direct, but after reflecting on this topic, I’ve realized how important it is to me. I want to give the discussion another try and present my criticism of TwinBASIC in a clearer and more structured way to foster a constructive conversation.

What are your thoughts?

I think that is a sensible approach.

twinBASIC needs Beta testers. Often different users find different issues, and some issues may be important to one user and minor to another. Only by getting a wide variety of issues reported can twinBASIC hope to be accepted across the VB6 community.

The issues you reported earlier - the bottom of the picturebox being missing and the issue with the App.Path - I don't think anyone else had reported. Reporting these issues is exactly what Beta testing is for - and the more issues that are reported the sooner issues can be found and fixed. Rest assured, these will be fixed. Wayne is committed to 100% VB6 compatibility.

Similarly with any other issues you find: If they are bugs they will be fixed, If there are settings that need to be changed someone will be able to inform you, if they are opinions discussion will ensue. This all moves twinBASIC forward.

[yereverluvinuncleber]

Apologies to Peter Swinkels for being grumpy. I was wound up by his comments.

[Peter Swinkels]

Dear all, thank you for your input and discussion. I have logged the key issues discussed here on TwinBASIC’s GitHub. For now, I’ll leave it at that. If further development or discussion takes place, it will happen via GitHub. Thanks for your contributions!"

[Shaggy Hiker]

And seriously, code line numbers? This isn't constructive criticism, this is looking for anything bad you can possibly say. Every modern editor, including Visual Studio and VSCode, shows line numbers by default.

I found this line amusing. My first thought was, "really? I don't remember that." Fortunately, I had a VS project open on a different screen and noticed that it does, in fact, have line numbers. All these years and I hadn't even noticed. I can't say that I use them (obviously), but you can't get much more unobtrusive than that.

[fafalone]

I use them to remember my place all the time. Often enough that I like them on the side rather than only the current number off on a corner.
The declares up top aren't broken into methods you can pick from the dropdown, and I write more methods with 50+ lines than I probably should, where you don't want to have to search for the exact block you were in a minute ago by reading it as text.

[Peter Swinkels]

As someone who gets easily distracted, even the smallest things can become irritating—especially when I'm trying to focus on my code rather than the quirks of the IDE. No disrespect to TwinBASIC or its developer, but Visual Basic 6.0 had one of the most enjoyable IDEs I've ever worked with. In Visual Studio, you can disable what some might consider minor features, such as line numbers. TwinBASIC’s IDE is certainly not the worst, but in terms of customizability and ease of use, it still has a long way to go.

[DrBobby]

If you pop open the themes folder you can customize to your hearts content. There are ~450 different settings for color, font, and various other things for customizing the TB ide just how you want.

[Peter Swinkels]

If I have to wrestle with my toolset before I can even start building, then I’m missing the point. I code because I want to create things, not because I enjoy tinkering with build scripts.

[OptionBase1]

If I have to wrestle with my toolset before I can even start building, then I’m missing the point. I code because I want to create things, not because I enjoy tinkering with build scripts.

Obviously, you don't have to, you can do that immediately regardless of the UI. If the UI bothers you, you can change it. If you having to change the UI bothers you, you don't have to use it. Obviously Wayne can't appease everyone with the default theme, and that is why the ability to change a lot of it has been built in to the tool.

No one is forcing you to use it or like it.

[DrBobby]

Safe to assume you use the vb6 ide in completely stock form then? No changed toolbars, no addons, etc.

[Peter Swinkels]

I’m not offering criticism to tear the project down — quite the opposite. TwinBASIC might be the most credible attempt I’ve seen to fill the VB6 gap, and that alone makes it worth taking seriously. > > Over the years, I’ve been part of projects that started with real ambition but didn’t gain lasting traction. Not due to a lack of effort or good intentions, but because building something truly usable takes more than technical skill — it requires direction, structure, attention to user experience, and the ability to process feedback constructively. > > What complicates things with TwinBASIC is the tension between how the project is framed and how it's defended. On one hand, there's a polished website, a licensing model, and comparisons to enterprise-grade IDEs — all of which set a professional tone. But when feedback is offered along those lines, the response is often that this is a personal project, built in spare time, and that the team is doing its best. I don’t doubt that — in fact, I appreciate the effort. But that duality creates confusion. > > So this isn’t about blaming anyone. It’s about acknowledging that, if a product presents itself with professional polish and commercial implications, it will be judged by professional standards — even if the team behind it is still small. Critical feedback should be welcomed in that light: not to discredit the effort, but to help it grow into what it promises to be.

And yes, I know TwinBASIC has been in development for several years and is still in beta. I don’t expect miracles. But I do think it’s fair to ask: how much longer will it remain in beta — and how does a small team plan to support something like this in the long run? > > Microsoft supported VB6 — and apps built with it — across multiple OS generations for well over a decade, and to this day those applications still work on modern Windows systems. That kind of stability is why businesses trusted it. If TwinBASIC aims to replace that legacy, then it’s not unreasonable to wonder how long-term reliability and support can be realistically offered — especially by a small, part-time team. > > It’s not about being ungrateful — it’s about understanding what kind of future you’re betting on, and whether that future has the structural support to carry it.

[Peter Swinkels]

Safe to assume you use the vb6 ide in completely stock form then? No changed toolbars, no addons, etc.

Sure, I customized VB6 too — toolbars, window layouts, fonts. But I didn’t need to sift through raw config files or hunt through cluttered, inconsistent option panels to do it. VB6, in 1998, already offered a more discoverable and user-friendly way to configure itself than TwinBASIC does in 2025. That’s the point

[WaynePhillipsEA]

When we introduced the themes support we did mention that there will, of course, be a user-friendly way of editing themes coming later. It will happen before v1. It's often the case that we expose something important, like themes support, and then later refine it. That's just how things work in BETA development.

[Peter Swinkels]

I understand that theme customization is still evolving and that some features arrive in stages during beta — that’s perfectly reasonable. But from a user perspective, it’s not always clear when something will become usable or how much of a feature is actually implemented. > > In the case of theme editing, for example, I only found out there’s no friendly UI yet after trying to dig into it. I didn’t go combing through dozens of GitHub issues, Discord threads, or changelogs to find that out — and honestly, that’s part of the problem. When users say they couldn’t find something, it’s not always because they “didn’t look hard enough,” but because the information isn’t clearly surfaced. What’s obvious to a developer isn’t always discoverable to an end user. > > Good UX isn’t just in the product — it’s also in how information flows, how expectations are set, and how guidance is delivered. If something is “coming before v1,” then that should be made visible in a clear, central place — not something you only know if you happen to follow a specific thread at the right time. > > I’m not here to pick apart your development process — I appreciate the work that’s gone in. But at the end of the day, I’d rather spend my time and energy on my own projects, not chasing down half-documented features or trying to reverse-engineer what’s coming when. Transparency saves everyone time — developers and users alike.

[fafalone]

The UI isn't exactly like VS where there's hundreds of menu options, dozens of dialogs with a dozen tabs and dozens of subdialogs... you should be able to find if some major component is there or not in just a couple minutes. Time spent making a bunch of placeholders is better spent actually making things, IMO. I realize in a perfect ideal world where there's a limitless army of developers what would be absolutely ideal... but even the megacorps that have those don't provide that kind of thing for their beta/preview versions, the details are in the changelogs like tB . Many either don't even provide such extensive documentation for production versions or it's buried in the hundreds of pages that document everything. It's a completely normal experience to have to ask questions on their support forums-- and tB has a knowledgeable community that is very good at that, you'll often be able to get help and answers from me and other volunteers helping out just because we love tB; we're not getting paid to help you or write what documentation exists. I also think there's some rose colored glasses about VB6; it's been unchanged for 25y now, but there was certainly a learning curve and major IDE changes not meeting the standards being asked for here going from VB1 to VB6 in a span of 7 years; VB3 or 4 to VB6 in the timespan tB has existed. Heck 25y in and I couldn't tell you what the stuff in the Query or Diagram menus do.

[WaynePhillipsEA]

Peter, I'm not sure you appreciate just how large and complex this project is, and that there is only one of me. I try my best, but there have to be some compromises in order to get the BETAs out of the door without getting caught up in the time consuming tasks of maintaining accurate and up-to-date lists of experimental/not fully implemented/broken features, which would, ultimately, slow down development. Given your very high expectations from a product still in BETA, I would simply advise returning to tB later once things have matured.

[yereverluvinuncleber]

P e t e r - b e t a !!

[Peter Swinkels]

The UI isn't exactly like VS where there's hundreds of menu options, dozens of dialogs with a dozen tabs and dozens of subdialogs... you should be able to find if some major component is there or not in just a couple minutes. Time spent making a bunch of placeholders is better spent actually making things, IMO. I realize in a perfect ideal world where there's a limitless army of developers what would be absolutely ideal... but even the megacorps that have those don't provide that kind of thing for their beta/preview versions, the details are in the changelogs like tB . Many either don't even provide such extensive documentation for production versions or it's buried in the hundreds of pages that document everything. It's a completely normal experience to have to ask questions on their support forums-- and tB has a knowledgeable community that is very good at that, you'll often be able to get help and answers from me and other volunteers helping out just because we love tB; we're not getting paid to help you or write what documentation exists. I also think there's some rose colored glasses about VB6; it's been unchanged for 25y now, but there was certainly a learning curve and major IDE changes not meeting the standards being asked for here going from VB1 to VB6 in a span of 7 years; VB3 or 4 to VB6 in the timespan tB has existed. Heck 25y in and I couldn't tell you what the stuff in the Query or Diagram menus do.

I hear your point, and I agree that tB already does a lot with limited resources. Still, constructive feedback — even if it echoes standards from other tools — can help shape it into something more broadly approachable. I think everyone here wants to see it thrive

[Peter Swinkels]

Peter, I'm not sure you appreciate just how large and complex this project is, and that there is only one of me. I try my best, but there have to be some compromises in order to get the BETAs out of the door without getting caught up in the time consuming tasks of maintaining accurate and up-to-date lists of experimental/not fully implemented/broken features, which would, ultimately, slow down development. Given your very high expectations from a product still in BETA, I would simply advise returning to tB later once things have matured.

> Thanks for your honest response — I do genuinely appreciate how much work this project involves, especially knowing it’s largely a one-person effort. My intentions are never to add pressure or demand polish before its time, but simply to offer perspective from someone who wants to invest in TwinBASIC early on, and is trying to understand how best to navigate and contribute. > > I’ll take your advice and give things some breathing room where needed, but I still believe early feedback — even if occasionally challenging — can help identify patterns or pain points that might otherwise go unnoticed. In any case, thanks for all your work so far. I’ll keep following the project with interest.

[Peter Swinkels]

P e t e r - b e t a !!

Yep, I'm well aware it's still in beta — and hats off to what’s already been accomplished so far. That said, early impressions still matter, and I think sharing what feels unintuitive or surprising can help smooth the path for future users.

[Peter Swinkels]

Just a quick note to say that someone else echoed support for the feature request I posted earlier (regarding a “Single Procedure View” in the IDE). They mentioned having the same difficulty navigating long functions and even switching back to VB on occasion — which really mirrors my own experience.

It’s just one other voice, but it’s good to know I’m not the only one bumping into this. Hopefully it helps show that even small improvements in editor ergonomics can make a noticeable difference.

https://github.com/twinbasic/twinbas...ent-2988863614

[yereverluvinuncleber]

Regardless of how Peter manages to find something to complain about, the TB IDE is an impressive piece of work, it is quick and responsive and it gives us some new and improved capability. It won't be the equal of the VB6 IDE (with addins) for a while but when you compare both in vanilla form it can do a lot very well - and it is still in an early BETA incarnation with lots to come no doubt.

The language improvements are the future and undeniable whilst the compiler in 32/64 bit form is simply amazing.

The mere fact that you can design and code using VB6 in a new IDE is an unexpected reality that just a few years ago was a pure dream.

[fafalone]

Even putting aside all the new language features... Code folding, regions, quick find widget with regex and multiline, run function in place, and the advanced info popup are just such huge boosts to my productivity tB wins out despite the few things VB6 does better. And that's before considering WinDevLib too... Never needing to search for APIs one or two at a time is such a massive boost that it saves me a ton of time overall even counting the time spent making it.

[Peter Swinkels]

Apparently, sharing observations that aren't glowing praise counts as complaining. Interesting take.