Well, I tried TwinBasic again and it didn't work for me but I'm still impressed.

[SomeYguy]

I think that the TwinBasic compiler & linkers are too finicky.

Some Vb6 code of mine - and it is good clean code by most standards including proper variable declaration & usage, etc. etc. - refuses to "just work" in TB while they run and compile flawlessly in VB6. The projects are self-contained, pure VB code and API calls. No reliance on external controls whatsoever.

I do realize that perhaps TB is trying to force certain coding "standards", but is that really necessary?. If one uses "Option Explicit" in VB6 and otherwise writes clean, clear code then is that not good enough for TwinBasic?.

BUT,

I'm still quite impressed with what I saw except that I'd really like to see a much-more-like-VB6 IDE. I'll stick with VB6 for now and check back on TB later.

As ChatGPT says, "Happy Coding!"

EDIT: I should also add that I'm just thankful that there is a lively VB6 alternative in the making .

[WaynePhillipsEA]

Firstly, thanks for trying out twinBASIC.

A significant amount of real world VB6 code does now "just work" in tB, but of course there is a reason we are still in BETA...

There's very little detail in your post for me to be able to comment on specifics, but I'd sure like to learn more. Are you perhaps able share the project with me for me to take a look?

[yereverluvinuncleber]

OP, read this: https://en.wikipedia.org/wiki/Softwa...ase_life_cycle

[fafalone]

Supporting VB6 means supporting even terrible, poorly written code. So of course well written code should work, and more and more is all the time, but the caveat is it's still in pre release, beta status because it's known not to be there yet. Nothing wrong with skipping this part of development; I think the tradeoffs of some things not working are more than worth the new features, but others don't and especially if you only ever use VB6 for one or a handful of things and the issues aren't easily avoided..

But tB is definitely at the point where I'm sure Wayne would love a detailed bug report on the problem or if you're able to share the project either publicly or privately with him so the problem can be fixed, because bugs now are usually much 'deeper' than before.

If the issue is related to forms... there's been few releases in the past month while the forms engine gets a major overhaul for detailed compatibility; might worth looking again next release. And obviously when v1.0 comes around.

Edit- ouch, double ninja'd lol... I'm so slow on mobile

[SomeYguy]

Firstly, thanks for trying out twinBASIC.

A significant amount of real world VB6 code does now "just work" in tB, but of course there is a reason we are still in BETA...

There's very little detail in your post for me to be able to comment on specifics, but I'd sure like to learn more. Are you perhaps able share the project with me for me to take a look?

Hi Wayne and thank you. I do not wish to release code for this one as it is a closed-source commercial product and it is about 60k lines in total. But I've attached a screenshot which gives an idea of some of the errors. To be clear, I could likely revamp the project code so as to work with TB and might do that at some point. But first I think that I'm just going to wait for awhile in your development cycle and see what happens. And all isn't bad - I have other VB6 code which runs just fine with TB.

OP, read this: https://en.wikipedia.org/wiki/Softwa...ase_life_cycle

Thanks but no worries. I'm well aware of the pre-release and development cycles. My first SW products were written on a Commodore VIC-20. And as said in my original post, even though TB isn't a VB6 "Everything-imported-just-works", I'm still appreciative and aware that TB is progressing every day and is currently the most viable upgrade solution.

Supporting VB6 means supporting even terrible, poorly written code. So of course well written code should work, and more and more is all the time, but the caveat is it's still in pre release, beta status because it's known not to be there yet. Nothing wrong with skipping this part of development; I think the tradeoffs of some things not working are more than worth the new features, but others don't and especially if you only ever use VB6 for one or a handful of things and the issues aren't easily avoided..

But tB is definitely at the point where I'm sure Wayne would love a detailed bug report on the problem or if you're able to share the project either publicly or privately with him so the problem can be fixed, because bugs now are usually much 'deeper' than before.

If the issue is related to forms... there's been few releases in the past month while the forms engine gets a major overhaul for detailed compatibility; might worth looking again next release. And obviously when v1.0 comes around.

Edit- ouch, double ninja'd lol... I'm so slow on mobile

Very good, understood and let me clarify that I'm not bashing TwinBasic. In fact, maybe I should have kept my keyboard shut. I'm going to crawl back into my hole now and re-emerge into the TB world at a later date.

[yereverluvinuncleber]

That might have been wise...

All failure at this point is 'grist to the mill' as long as Wayne has enough code and information to test the specific issues that you raise. Beta may be a long road but eventually TB32/64 will reach a point where it is more-or-less 'usable' by most with only edge-cases or unknown failures to deal with. The more you give Wayne, the quicker your issues will be fixed.

[fafalone]

Very good, understood and let me clarify that I'm not bashing TwinBasic. In fact, maybe I should have kept my keyboard shut. I'm going to crawl back into my hole now and re-emerge into the TB world at a later date.

Sorry I didn't mean to come across as discouraging feedback; I just wanted to make the point that there's awareness not everything runs yet, expected in this part of the development cycle, and that if something labeled Beta has an issue, especially when so much *is* working, there's definitely a need for people to test their programs in it, but also to be more specific when a test fails so that can be addressed. Your comments are definitely welcome and I apologize if my comment made you feel otherwise.

From the screenshot I wouldn't expect it to run with so many design time errors; unless they're all in property pages (which have a designer and editor so get imported but they're not enabled so errors in them won't impact execution). Curious what those are.

[WaynePhillipsEA]

Could you copy the full list of diagnostics (right click inside the diagnostics panel), and paste or attach here?

[yereverluvinuncleber]

In the absence of this thread continuing to resolve someYguy's post I thought I'd post a picture of two TwinBasic apps operating 99-100% as they should.



The dock at the bottom and the steampunk clock with its prefs window are all in TwinBasic.

[yereverluvinuncleber]

Oops, that was the VB6 version posted above, I suppose this is an even better advert for TwinBasic now that I can show the TB version of the same apps alongside.

[BenJones]

I not really used TB to test any of my projects just been looking now and then at each beta. it looks quite good and they have done a good job. I think the only time I use it full time is when it in final release and it been sold for a few years, I hope they do something like MS did and do one of payment like MS did I don;t like this subscription stuff.

[yereverluvinuncleber]

I don't like this subscription stuff but...

A. The free version does everything VB6 does and more.
B. The commercial option allows 64bit binary compilation.

Personally, I will purchase a month's subscription and during that month I will convert my above test clock/calendar program to 64bit and then test it against the 32bit version, I'll need a month to get that done and document the process. Only then will I make the decision as to whether I need 64bit TB or not.

Bear in mind that the only way you can officially obtain VB6 these days is through an MSDN subscription and that costs six times more per month than a TwinBasic subscription does.

Remember also, that the pro version of VB6 cost $549 in 1998 as a one-off purchase, probably nearer to $1,100 today. Do you really want to pay that?

[VanGoghGaming]

You can already compile 64-bit binaries with the free version of tB, have you not tried it yet? The only difference is that you get an obscenely long splash screen at startup!

[BenJones]

I don;t like splash screens to they remind me of the 1990s do like ms do and do a community edition splash screens put e right off things.

[fafalone]

2 more days to buy a perpetual license.
https://twinbasic.com/blackfriday

[yereverluvinuncleber]

You can already compile 64-bit binaries with the free version of tB, have you not tried it yet? The only difference is that you get an obscenely long splash screen at startup!

Not yet ready to try it myself, the point being that it takes time and effort and I am currently finishing my project so no time available. However, some time in the future, near or far when TwinBasic is live, I can see myself dipping into 64bit compilation as the subscription licence allows me to do so. Not an issue.

I don;t like splash screens to they remind me of the 1990s do like ms do and do a community edition splash screens put e right off things.

Ben, you don't like a lot!

[Shaggy Hiker]

I didn't mind the 1990's, for that matter. Interesting stuff going on.

MS could sell one-off licenses for a couple reasons. For one thing, that's pretty much the only model out there at the time, but more importantly, they were selling the OS. Getting people to write programs for Windows was so valuable that I'm a bit surprised that they charged anything at all for VB6.

TB is not that way. It's not a gateway into something else. It either survives or fails financially, all on it's own. There will be maintenance costs. If everybody buys a single license then never opens their wallet again, TB will be bankrupt. They need repeat sales, new sales, donations, or a subscription model, to be a viable concern. The first three are all iffy.

[yereverluvinuncleber]

I will give them some cash, and I'll do it regularly. IF I was creating for business reasons then I would simply purchase a licence. I may well purchase a monthly subscription just based on what it can do now. Really enjoying using it.

[VanGoghGaming]

Not yet ready to try it myself, the point being that it takes time and effort and I am currently finishing my project so no time available. However, some time in the future, near or far when TwinBasic is live, I can see myself dipping into 64bit compilation as the subscription licence allows me to do so. Not an issue.

To be honest, I am kinda in the same boat, reticent to move in the 64-bit world, mainly because it's a pain to modify existing applications. If you forget to change even one pointer variable from the ubiquitous "Long" to "LongPtr", it's a guaranteed crash! It's a lot easier if you start from scratch with a new project though, like the TwinBasic OCR project I posted a few days ago. Surprisingly enough that ran perfectly fine in 64-bit on the first try!

[yereverluvinuncleber]

Van,

One day, we will have to. That day is coming - but not quite yet! I 'm just pleased the 64bit door is open.

[SomeYguy]

Could you copy the full list of diagnostics (right click inside the diagnostics panel), and paste or attach here?

Wayne,

I'm really sorry, got busy here and pretty much forgot about this. When I get a chance I will try again to build and will copy & post diagnostics. Thank you very much .

[vbrad]

TB is not that way. It's not a gateway into something else. It either survives or fails financially, all on it's own. There will be maintenance costs. If everybody buys a single license then never opens their wallet again, TB will be bankrupt. They need repeat sales, new sales, donations, or a subscription model, to be a viable concern. The first three are all iffy.

I'd agree with the subscription model being likely the best.
For the early versions though, I can see the merit in offering perpetual licences.
It gives the company better cashflow initially and it's also very likely that v2 will have features that will strongly encourage owners of v1 to upgrade.

The common practice of offering upgrades to the next version only, at a discount seems to me a bit of a halfway house between the two models.


As an aside, Teamviewer used to have an interesting model.
Every paid License was a perpetual license, a feature that they strongly advertised.
However older versions could never control PCs with newer versions for "technical" reasons.
Because customers (for whom Teamviewer was a freeware download) were always being encouraged by Teamviewer to upgrade to the latest version then unless all the computers you controlled were your own, you were pretty much forced to buy a new license every year.

Even this scheme turned out to be too generous for the venture capitalists who purchased the company and they moved to a subscription-only model, including expiring existing perpetual licenses along the way.

[SomeYguy]

Wayne,

I'm really sorry, got busy here and pretty much forgot about this. When I get a chance I will try again to build and will copy & post diagnostics. Thank you very much .

Attached is a list of warnings but not fatal errors. There was actually only one fatal error which I traced to having declared a constant within a procedure rather than at the module level. VB6 is okay with this but apparently TB is not. I fixed that one easily enough and the program did build successfully in TB afterward, but the binary fails at runtime.

Out of time to work with this now but will revisit at another time. Thank you so much for this wonderful VB6 alternative and take care.

[fafalone]

tB supports e.g. Const foo = 1 inside a procedure; if you've found an error with that could you make a minimal reproduction?

Right now though for anything else I'd wait for the major update due out hopefully really soon now; going to be huge improvements in compatibility.