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.
File I/O is now supported in twinBASIC with v0.13.30
Experimental support for the Encoding argument has been added to support UTF-8 and UTF-16 as well as ANSI.
twinBASIC are now looking at handling migration from a VB6 project (.vbp).
A VB6-compatible Forms engine, including GUI support, implementation of all basic controls and support for ActiveX controls, is expected (in Alpha) in February.
good job twinBASIC :)
twinBASIC update:
https://nolongerset.com/twinbasic-up...ember-12-2021/
Highlights include the File I/O system reaching feature-complete status, an updated twinBASIC roadmap, and experimental text encoding support.
Olaf really can't help himself can he. Someone mentions VB.Net and he is just ready to pounce lol.
Interesting discussion on Tuples though. I don't use them much(though I should) but I think they are a great feature. There's just so many times where you want to return multiple values from a function and it just seems wasteful to define and entire class just for that one function. Tuples solve this problem.
well, Wayne can add whatever he wishes, since he is the dev,
for me, I can already do that stuff anyway
Sub DoStuff(U As UDTtype)
U.Name = "MyName"
U.Age = 20
U.Income = 50000
U.Object(1) = "Plate"
End Sub
Sub DoStuff(B() As String)
B(1) = "MyName"
B(2) = "YourName"
End Sub
what would be the use? it just feel bloated and non-intuitive.
like this: max, min = maxmin(a, b)
we could just easily do:
Sub maxmin(Byval A As Integer, Byval B as Long, Min As Long, Max As Long)
Actually, from experience I think that applies much more so to you Niya.Quote:
Originally Posted by Niya
Personally, I would prefer if TB would constrain itself to what VB6 does at the moment. That should be the mantra. Introducing new functionality always introduces new complexity, bugs and more importantly, delays. Just make it work, fix the intrinsic bugs that will be created in any case and then only add new functionality when the product is usable.
We don't need tassles, bells, whistles, basket, foghorn &c. We just want a bike we can ride.
You know I really don't understand you guys. Do you guys want TwinBASIC to succeed or not? Like it or not, the programming world has changed since VB6's prime years. People are now programming with tuples, Async/Await. Functional style constructs are also becoming increasingly popular. This means, functions must be first class citizens to support higher order functions. Python is now being touted as the BASIC of the modern age, a language that is simple and easy to learn and it has all of these things. Simplicity is no longer an excuse to avoid these things. Modern programmers are not afraid of these things. If you want TwinBASIC to take off, then you must bring it up to the expected standards of the modern programmer.
I mean don't you guys want to see a world where TwinBASIC can crack top 10 on one of those indexes you guys like so much like TIOBE? This is what must be done for that to have a chance of happening. Don't you want a vibrant and thriving community akin to other communities like C#, Python and JavaScript? Then you must make the language attractive to the modern programmer. Don't you guys want 100 super talented people like Olaf to come into this community? This is how you attract that talent. You do not do this by artificially crippling your language to the point that it resembles something from the 90s.
One of TwinBASIC's core missions is 100% compatibility with VB6 and most of these things can be implemented without sacrificing that mission. Come on guys. Stop being so afraid of change.
As per my post above, this is just a terrible idea if it's permanent. I really hope Wayne doesn't give into this sentiment.Quote:
Originally Posted by yereverluvinuncleber
You are the master of the misquote and I've seen you do this before.Quote:
Originally Posted by Niya
I definitely said - "only add new functionality when the product is usable" and I explained my reasoning but somehow you fail to see 50% of what is said and only misquote in order to... ? well, frankly I don't know, is it to give yourself something to do?
Please, in future don't do that. It annoys.
That had nothing to do with .NET.Quote:
Originally Posted by Niya
I'd just like it very much, when the language could remain free of unnecessary "features".
Nobody is using them much... (aside from a few special, often math-heavy areas).Quote:
Originally Posted by Niya
Tuples are just "dynamically created Mini-Lists" (an aggregation, returnable from a function, or "storable in an outer List") -
and in VBScript/VBA/VB6 we already have the Array() function, to create such Tuples on the fly.
E.g. if your OuterList is a VB6-Collection, one can easily add (and later retrieve) tuples this way:
Dim OuterList As New Collection, Tuple
OuterList.Add Array(1, 2, 3)
OuterList.Add Array(4, 5, 6)
For Each Tuple In OuterList: Debug.Print Tuple(0): Next
All possible, due to the Variant-Type (which I consider one of the strengths of the language).
Olaf
To be honest, I really don't agree with this mindset. I've alreavy detailed why about 2 posts ago.Quote:
Originally Posted by Schmidt
You are correct but for right now. They aren't that popular a feature but I will be lying if I told you I don't see them showing up more and more when I look up random snippets of code online in other languages. Personally, they are not a feature I'm willing to die for. I would be 100% fine without them. That being said, I think for the good of TwinBASIC, Wayne should not ignore this. Tuples might be necessary if he wants to attract modern talent to his product. Modern programmers expect these things. I think he should implement them.Quote:
Originally Posted by Schmidt
I get that you guys have your own ways of implementing Tuple-like functionality with the VB6 syntax and base libraries but I cannot envision these young cats out here being enthusiastic about such a primitive way of doing things, especially if they come from environments like Python or C#.
if people would skip TwinBasic just because theres no tuples they most be very narrow minded.
the reason I would pick TwinBasic is:
- it can replace VB6
- newer compile
- better optimized and faster
- fix DPI and other issues VB6 has
- eventually cross platform
- eventually fully 64bit
if TwinBasic would be:
- Identical to VB6
- tons of .NET & other languages functionalities
- fully support to tuples
- no cross platform
- no 64bit
I would just keep using VB6.
Tuples alone? No. But Tuples along with most other modern features, definitely yes. If all TwinBASIC aimed to be is just a perfect VB6 clone with no improvements to the language. I would not look it it twice nor recommend it to anyone.Quote:
Originally Posted by baka
Just that...Quote:
Originally Posted by baka
I have my own list of improvements/additions but I would NEVER muddy the waters at this point and dare to introduce any of them as I want TB/RB to succeed. If that success is jeopardised by the addition of the multiplicity of such small improvements then that is a risk I am not willing to ask anyone to take.
Baka's list above would be in itself a phenomenal achievement.
Quote:
Originally Posted by Schmidt
Olaf, I love the way that you use the tools at hand to solve a situation, combination of brainpower and the understanding of the tool that you have to use in the first place.
I had always perceived the variant type to be one to avoid given my original intention to migrate my programs to VB.NET. However, I am beginning to revisit variants in the light of my less than positive exposure to VB.NET and the potential of the forthcoming replacement TB (and RB). Should I re-evaluate the variant type and take it off my naughty list? I have tried to avoid it when at all possible.
the route for TwinBasic should be:
1. fully vb6 compatible
2. optimization of all vb6 functionality that need improvement
3. how to add features for different "upgrades" of core VB6 functionality (to keep legacy but also fix different issues VB6 has, like DPI aware)
4. how to easily switch 32 to 64bit. to differentiate between the 2 modes, such as API declaration, type declaration etc.
5. how to easily switch between 32/64/cross platform mode
6. add modern gui, that also help bridge the cross platform mode
7. add sound support, that also can be used in cross platform
8. add support for any monitor changes, this so we can easily adapt the code when monitor is changing resolution etc.
9. other feature that are needed for modern rad development that was not needed 20 years ago. and always keep in mind the cross platform compatibility
when all that is done, and we can start working on projects, that we can release in windows but also other platforms,
when the IDE is stable and the compiled executable is well optimized, at that point, other feature could be added,
now when people are using it, it will also be easier to tell what do we actually need.
like VB6, is done and we know the strong and weak points, and the workarounds to make it work when theres some issue.
so we already know what we would need for VB6. but Im not sure what we need in TwinBasic yet.
I agree 100% with all of this. Don't get me wrong.Quote:
Originally Posted by baka
What I am saying is that you also cannot ignore some of these requests people are making like Tuples. As a fan of more modern language contracts myself, if I were active over there, I'd be pushing for making functions first class citizens in the language. I don't think I would ever want to use a language long term where this is not the case. I think a lot of people would over look it if it doesn't meet a specific standard which is based on what is already popular in other mainstream languages. TwinBASIC looks very promising so far with features like generics and multi-threading. I would hate to see it to stagnate and not keep pushing for new improvements.
EDIT:-
I'd further state that the only real justification not implementing a feature is such a case that violates the goal of 100% VB6 compatibility. The only potential language improvement I've seen so far that violates this is the removal of that garbage Set statement. The truth is most modern improvements would not prevent TwinBASIC from being VB6 compatible.
yeah.
its an inspiration for the DEV, when people give feedback and comments and ideas.
right now I feel that the "improvement" should be about the essentials for VB,
such as "Decimal/LongPtr/LongLong" types, that I would need so I dont need to first declare as Variant and after that change its type to Decimal.
that I wouldn't say anything against. I would say: go ahead. since you are already working with data types, why not add a few more?
unicode and other modes, make the gui work with 24/32bit , well, anything that are about improvement of the core VB6 that is 20 years behind.
if VB6 would improve on its own, Im sure we would have all those things already. thats what TwinBasic should focus first.
but only, if the improvement are obvious and not much time-consuming. like: if the DEV is adding graphic rendering, why not just let it be 24/32bit immediately?
it shouldn't post that much extra work. and like the types, if he adds the VB6 types, its not that much extra work to add a few more.
I think theres an order of things, otherwise its easy you mess up, because theres no end of features, u can always find something new to add.
better stay in course and focus on the basics, since the important thing is to "migrate" all of us first, and we will do that when TwinBasic can do what VB6 can do.
after that we will be part of the ride and will give feedback and bug reports when needed.
I would say though, there should be a cut off point where it's too much. C# is an example of a language that is loaded to the brim with an unrelenting river of features. I don't think any language that derives from BASIC should go that far but it shouldn't remain where it was 20 years ago either. Tuples, Async/Await, easy mult-threading, higher order functions are just some of the more common things I think a modern language should have even if it's derived from BASIC.Quote:
Originally Posted by baka
Olaf is. He doesn't want the language to be changed that much. Perhaps he would correct me on this but it seems to me that if he had his way, then they syntax would not change at all which is exactly what I think is a bad idea.Quote:
Originally Posted by yereverluvinuncleber