Hello!
Great job!
When will it be possible to upload VB6 projects to TwinBasic?
Printable View
Hello!
Great job!
When will it be possible to upload VB6 projects to TwinBasic?
That is still a ways off. It still needs a GUI engine which is in the works but not completed yet. However, it is already fully capable of executing non-GUI VB6 code. It just cannot yet read VB6's project formats. You'd have to manually copy-paste your VB6 code.Quote:
Originally Posted by lfeche
Thanks!
twinBASIC status update:
https://nolongerset.com/twinbasic-up...ember-26-2021/
Highlights include a sneak peek at building custom form controls, the related dynamic property sheet, and a bunch of screenshots teasing the upcoming features.
twinBASIC GUI/Forms Designer progress:
https://github.com/WaynePhillipsEA/t...iscussions/451
twinBASIC status update:
https://nolongerset.com/twinbasic-up...ctober-3-2021/
Highlights include a glimpse into the possible GUI release timeline and a discussion about data binding with twinBASIC forms.
Video of the twinBASIC form designer in action, and a simple grid control (less than 100 lines of code for the OnPaint method).
twinBASIC form designer video
This form designer and cross-platform forms engine based on custom-drawn controls is specifically designed for later supporting multi-platforms.
Later there will be VB6-compatible Forms engine, including implementation of all basic controls and support for ActiveX controls.
TwinBASIC is starting to look very sexy! Can't wait to get back to testing it.
twinBASIC update...
https://nolongerset.com/twinbasic-up...tober-10-2021/
Highlights include an extended preview of the yet-to-be-released form designer and a spirited discussion about whether to fork VS Code to create a dedicated tB IDE.
The first version of the Form Designer and Custom Controls are now in twinBASIC v0.11.
Here is a sample project with a grid control...
https://user-images.githubuserconten...ee2ac68be1.gif
Initially this is only available to those who have pre-ordered a twinBASIC license.
twinBASIC update...
https://nolongerset.com/twinbasic-up...tober-17-2021/
Highlights include the alpha release of CustomControls, a twinBASIC wiki, and a revived discussion around "Quirks Mode" in twinBASIC.
That quirks mode discussion is interesting. Not sure how I feel about it. On the one hand, all these quirks and bugs in VB6 are no good and need to be gone but on the other hand it's necessary for backward compatibility with VB6. It seems the aim of 100% compatibility with VB6 would demand some sacrifices. Hope it doesn't become so much that TwinBASIC becomes just as broken and painful to use as VB6.Quote:
Originally Posted by VB6 Programming
Backwards compatibility is never as straightforward as it sounds. But it has to be the overriding aim. Otherwise (as happened with VB.Net) developers simply won't migrate existing apps.Quote:
Originally Posted by Niya
So you have to replicate VB quirks in twinBASIC.
That may sometimes mean you have 2 ways of coding something - the old, quirky, way and a new (more) correct way - each potentially giving different results.
In some cases you may get 2 different results from the same code, depending whether the old or new way is selected. I don't like this, and would prefer the old statements gave the old quirks and new, improved code to give the correct result.
Old quirky statements could be optionally disabled with options/flags, but I think I would still allow them but mark them as 'deprecated'.
I think Microsoft already showed us the way when it comes to how to handle this. In VB.Net, they provided a namespace with most of the VB6 stuff that works the way it did in VB6 but you could opt to use the Framework to do it the .Net way.
TwinBASIC could take a similar approach. They could have all the quirky behavior be the default but then they could provide a bunch of modern replacements with no quirks in the form of a new set of classes, or a modules. This way all of the old VB6 programs still work but anyone that wants to get away from the legacy stuff could use the new classes or whatever to opt-in to the new way of doing things. Those of us that left VB6 to go into VB.Net took a similar path. We started by doing things the old way but slowly learned how to do it the modern way.
You also have to contend with code that might need to work either way - if a library exists it might need to accept an "old" data type or a "new" data type that conceptually are the same. Making sure a library can cope with both versions, including all the quirks can quickly start to get complicated.Quote:
Originally Posted by VB6 Programming
Yea, this definitely a big problem.Quote:
Originally Posted by PlausiblyDamp
It should always run in quirks mode and any 'advances' or changes to original spec. should be switched on an individual basis, item by item, flag by flag.
Improvements are welcome but not required. The same code compiled to 64bit with quirks should be the minimum.
twinBASIC update...
https://nolongerset.com/twinbasic-up...tober-24-2021/
Highlights include the addition of 4 new custom control events, ElementTabStop/Index properties, and a Spanish presentation on twinBASIC.
Quote:
Originally Posted by Niya
I totally agree... if it's not too much work for the twinbasic developers.
There have now been over 1000 downloads of the twinBASIC preview.
https://marketplace.visualstudio.com...false#overview
No need to be complicated.
The superior alternative path is the best one. All VB6 quirks are coded exactly as the originals, with superior alternatives offered in their place. Then all older code will work but ultimately for any new coding the superior alternative will be the one developers will choose automatically. The better in this case being the enemy of the sufficient... or the quirky.
The namespace idea would be a good one. What would be ideal would be the ability to easily toggle on and off the old way would make it easy for somebody to see where they were using the inferior such that they can focus on changing those. Once they have them all changed, they could turn off the inferior way for good. It's good to allow the old way to work, but it's also good to have a means to push people away from it.
Heh, that's almost exactly what MS did with the Net Core transition...
(net framework (net standard) net core)
Net standard was just a bridge. As soon as enough people crossed it, they burned it to the ground.
I don't think that will ever happen with VB6 --> tB.Quote:
Originally Posted by Shaggy Hiker
There will keep appearing new programmers (to tB) coming from VB6 for many years.
twinBASIC update...
https://nolongerset.com/twinbasic-up...tober-31-2021/
Highlights include initial support for a Clipboard object, a new custom control sample (Wayne's TextBox), and support for Return as an alias for Exit Sub.
This literally made me laugh:-Quote:
Originally Posted by VB6 Programming
I love this dude, whoever he is. ;)Quote:
Supporting this feature would break backward compatibility in a very narrow way. The issue is that a bare Return statement with no matching GoSub in VBx is a runtime error and not a compile error. So, it is theoretically possible that some madman out there is relying on a bare Return raising a runtime error and when that code gets converted to twinBASIC...and does not raise an error...then his code will stop working. But, you know what? Screw that guy.
Yeah, that's a good answer. Anybody who is relying on that behavior...has issues.
twinBASIC update:
https://nolongerset.com/twinbasic-up...vember-7-2021/
Highlights include our first look at a working twinBASIC form, the early makings of inheritance support, and the promise of custom ActiveX control development.
A new release of twinBASIC v0.12.117 is available.
The licence key requirement for the Custom Controls is removed from this version so anyone can test/try it.
See Sample6 for an example of using a form with custom controls.
This shows the Form Designer using custom controls. This is an early implementation of the form designer.
The intention is to develop this further in 2 ways:
1) to develop a VB6 compatible form designer using all basic controls and supporting ActiveX controls.
2) to support multi-platform (Windows, Linux, Mac and Android) where ActiveX controls aren't supported.
https://marketplace.visualstudio.com...false#overview
twinBASIC update:
https://nolongerset.com/twinbasic-up...ember-14-2021/
Highlights include temporary removal of the license key requirement for CustomControls and partial inheritance support using Implements ... Via.
twinBASIC major milestone release - PREVIEW 2 - v0.13.x - 64 BIT SUPPORT
Full 64-bit compilation support, including EXE/DLL builds, integrated debugger, integrated linker, etc.
To get started, first you need to create a win64 build configuration in your projects. To help you, when you first open your projects in v0.13.1, the IDE will prompt you to create one.
Now you should be able to activate the win64 build configuration.
After selecting win64, you'll be prompted to restart the compiler. After doing so, you'll be debugging and compiling in full 64-bit.
https://github.com/WaynePhillipsEA/t...iscussions/496
64-bit compilation for non-licence holders is allowed, though EXE and DLL compilations will display an embedded twinBASIC splash screen for 5 seconds at startup. twinBASIC licence holders will of course not be subjected to this.
twinBASIC update...
https://nolongerset.com/twinbasic-up...ember-21-2021/
Highlights include 64-bit compilation support (no license required!) and a discussion about early binding and reference handling.
twinBASIC release 0.13.5
Latest additions to twinBASIC:
Initial support for File I/O statements: Open (Binary / Random modes only), Put, Get
Implementations for VBA.FileSystem members: FreeFile, EOF, LOF, FileAttr, Loc, Seek, Reset
No link this time? :(
Links :)Quote:
Originally Posted by Niya
File I/O support
twinBASIC Preview 2 out now
twinBASIC install
I was actually referring to the links to your site with all the "around the web" stuff. I enjoy reading those updates....Quote:
Originally Posted by VB6 Programming
The file I/O discussion is pretty interesting. I think Unicode support it should be part of the Open statement syntax for the reasons stated by bclothier. It would encourage defensive coding practices that would just be messy.Quote:
Originally Posted by VB6 Programming
?Quote:
Originally Posted by Niya
Are you meaning this site... https://nolongerset.com/
That's not me, it's Microsoft MVP Mike Wolfe's site. He does a summary every Sunday of the status of twinBASIC.
Ah ok.
twinBASIC update:
https://nolongerset.com/twinbasic-up...ember-28-2021/
Highlights include the first major release of file handling statements and functions in twinBASIC, along with talk of providing a tB license to the Rubberduck project.
twinBASIC update:
https://nolongerset.com/twinbasic-up...cember-5-2021/
Highlights include the implementation of additional File System features, improved performance for Split and Replace, and a discussion about universal binaries.