Printable View
Is there somewhere a list of all new features introduced to tB now?
I was about to open an "issue", but didn't want to suggest something already supported.
Also, should they be things only related to the language itself, or can they be also suggestions regarding forms and features that are not currently developed?
I hope WaynePhillipsEA will not get distracted too much by too many "side-wishes" and will still focus on the core to make prio for compatibility.
Don't worry, back compatibility is the #1 priority. I'm not planning any major new features for a little while until we've put the bulk of the remaining missing features in place over the next couple of weeks.Quote:
Originally Posted by Krool
The list of features under 'Compiler Features' on the main homepage (twinbasic.com) is the most thorough list of features for now until the documentation is complete.Quote:
Originally Posted by Eduardo-
Please do come over and post any requests on the github page any time you like. Everyone here is welcome to come over, and the more people we can get involved in the discussions will help shape the future of the product.
https://github.com/WaynePhillipsEA/twinbasic/issues
I certainly don't mind if the issues you raise relate to something not yet implemented... I'll just label them as such, ready to look at when we get to that stage.
OK, thank you for the clarifications.
twinBASIC's 100% Compatibility Goal...
"twinBASIC is a modern version of the classic BASIC programming language. With twinBASIC we aim for 100% backwards compatibility with existing VB6 and VBA projects."
twinBASIC's 100% Compatibility Goal
Good to see there have been 222 downloads of the twinBASIC preview.
Edit: Now 230 downloads
To be a first version, it works a lot better than I expected,
Great work tb.
I'm very impressed too. Great compatibility with the VB6 language. There is still a lot to be done, I'm looking forward to Forms/GUI support being added, and the automatic migration from VB6.Quote:
Originally Posted by yokesee
Slides of the Access DevCon twinBASIC presentation twinBASIC slides
and some other twinBASIC links https://nolongerset.com/devcon-2021/
There have been over 250 downloads of the twinBASIC Developer Preview twinBASIC Developer Preview installation guide
twinBASIC Preview release 0.9.2021 out now.
This release adds late-bound support to twinBASIC classes, which in turn fixes many other issues such as WithEvents support.
do you test twinbasic?Quote:
Originally Posted by mansellan
Yes, been testing since before the first public preview. I've contributed to a bunch of the feature requests on the project's GitHib project. There's more to do (not least of which is forms support), but it's progressing swiftly.
I have the following problem.
the list of com I get empty
I only have OLE Automation V2
It does not let me select any reference.
a greeting
https://www.vbforums.com/images/ieimages/2021/04/7.jpg
Have you registered RC6.dll and RC6Widgets.dll?Quote:
Originally Posted by yokesee
See the instructions hereQuote:
For those who want to run the code, before you start:
the newest RC6-Version 6.0.8 needs to be downloaded
unzipped into a Folder of your choice
and then RC6.dll and RC6Widgets.dll need to be registered (e.g. via the 2 little install-scripts in the Package)
Hi! This is a bug. Could you possibly open up an issue over at GitHub so that we can investigate?Quote:
Originally Posted by yokesee
https://github.com/WaynePhillipsEA/twinbasic/issues
Thanks!
Good on you Wayne, class response.Quote:
Originally Posted by WaynePhillipsEA
Thank you .
In a virtual machine VSCODE and RC6, it worked perfectly.
It may be a problem with my vscode installation
good team Vbbrichclient TwinBasic :)
a greeting
The clock with RC6 works perfectly.
Only to check compatibility
the RC6BaseDlls folder is placed in the workspace next to the Build folder with recording of the 2 .vbs
Also based on RC6, an equally convincing RecordSet test :
Modifications :
vbLeftJustify, vbRightJustify, vbCenter not recognized, replace respectively with 0,1,2
Static replace by Dim in cfMain Class
App.Path replace by absolute address "C:\...\..."
Attachment 181333
if RC6 could be added to the project without the need to register the dll, as u can just put them in the same folder as the compiled .exe that could be what I need to start using RC.
RC5/RC6 has always been doing what you expect (no need to register DLLs), but you always close your eyes and cover your ears.Quote:
Originally Posted by baka
https://www.vbforums.com/showthread....=1#post5443031
no, I can't make RC to work. I can't add it to the references, it gives me errors. I have told about this numerous times. no matter what Im doing I can't add to references, so its impossible to use.
That might happen, if you didn't keep the Dlls from the zipped packages together in their "unzipped Folder-location".Quote:
Originally Posted by baka
Perhaps make another attempt with the RC6BaseDlls.zip-Download?
- unpack it to C:\RC6\
- now go into that Folder (and don't move any Files away from each other, leave them sitting there together, as they are)
- if you have an OS higher than XP, then it should be sufficient, to just DblClick the two *.vbs Files for registering
If you don't like the registering via *.vbs Files, then you can of course do the registering also manually:
- by opening a console in admin-mode
- and then typing: regsvr32 C:\RC6\RC6.dll (and regsvr32 C:\RC6\RC6Widgets.dll respectively)
Now you should see two new (errorfree selectable) entries in your VB6-IDEs References-Dialog:
- RC6
- RC6Widgets
Cannot imagine, that this works for hundreds of Users, but not on your machine
(other than, that you possibly do not run your VB6-IDE elevated? ... or have some "weird AddIn" loaded?).
Olaf
Weekly update on the status of twinBASIC:
twinBASIC status update
Thanks.Quote:
Originally Posted by VB6 Programming
twinBASIC Roadmap/Priorities - twinBASIC are asking for our views on what should be the development priorities for the twinBASIC language.
twinBASIC Roadmap
Both twinBasic and RADBasic are products that are worth looking forward to, but I don't know when twinBasic will stabilize in the language syntax and become a product that can be used in practice.
I have a suggestion, which is:
(1) List all the features of VB.NET, and then discuss which features should be added to twinBasic.
(2) In addition to the features of VB.NET, organize a list of extended features, and then discuss which features should be added to twinBasic.
(3) Implement (1) as the main plan, and implement (2) as the auxiliary plan (future expansion plan)
RADBasic can also take a similar approach.
as for me, what I would like twinbasic to be is, example:
- we do this in VB6 because theres no built-in function that can do it, example subclassing the mouse wheel.
twinbasic should instead give us a built-in alternative so we dont need to subclass again.
- same as before, is "the usual API", like get width/height in pixel and all the trouble with DPI etc.
twinbasic should have a built-in alternative so we dont need to deal with that again.
- a more robust graphic rendering that is following the monitor sync. so, all the graphic methods, that "draw", will actually draw into a memory buffer, and when monitor sync, it will draw "everything" in one go. (like we have with direct2d, I draw everything but not until I use "EndDraw" it will actually show. this will allow flicker-free drawing/animation.
so, instead of adding VB.NET features, VB6 can be upgraded first, by looking at every aspect that are lacking or where we need to do lots o "tricks" to go around a problem, twinbasic should give us an alternative.
Can the grammar check function expose the interface? I am developing a small VB6 IDE, using VB6, VBS, JAVASCRIPT as the code to run
Features:
- Unicode enabled.
- 32 bit and 64 bit versions.
- High DPI aware for any monitor resolution.
- Language localization. Simple create language file based on English.lang file.
- Localized for 11 languages.
- Projects and non-project based editing.
- Easy integration of Console or GUI based code.
- Incremental compiling of code defined as a "module".
- Easy including of Windows Resource files simply by specifying which source code file is the resource.
- Seamless integration of the Compiler (both 32 bit and 64 bit).
- Codetip popups and auto completion.
- Built in Visual Designer.
It would be better to develop a VB6 plug-in package (add in), which can allow many VB6 users to switch over to use your software.Quote:
Originally Posted by baka
The plug-in is just a DLL, and installing your programming IDE may require hundreds of megabytes of space
Develop a VB6 plug-in program for free, which can train more users and let them try some new features.
TwinBasic (as a compiler, a "language") is not responsible to solve your points above.Quote:
Originally Posted by baka
All it needs to focus on is, to provide the ability to compile VB6 *.cls and *.bas modules (as they are) -
later on also providing support, to achieve that feat also on other platforms - but nothing more (especially that latter part is harder than it seems).
Every single one of your points above, can then be solved:
- in a "twinBasic accompanying "Class-Framework with enhanced Drawing- and GUI-support"
- ideally written in twinBasic (or VB6 *.cls or *.bas modules only, to which twinBasic is compatible)
- furthermore, that new Class-Framework should work platform-independent (using no Direct2D, no DirectX, no GDI32, no GDIPlus underneath)
- ideal would be, when you could already start using that framework now, directly in VB6 (to gather experience with it)
- it'd also be nice, when that framework would allow, to solve the same problems you formerly solved with GDIPlus etc., in less lines of code
- it'd also be nice, when the Class-framework itself would be implemented efficiently (binaries significantly smaller than .NET, QT, GTK+)
Now wait,... we have that already... ;)
Well, here I'm kinda thankful, that with twinBasic - it now becomes more and more clear what I was aiming at with the RC5/RC6 ClassLib...
TwinBasic simply providing somewhat earlier "the yet missing part" (I nevertheless continue to work on).
Olaf
I don't think that's the (only) aim of tB.
The aim is to support forms, usercontrols and property pages. It aims to be backward compatible with existent VB6 projects.
So far it only supports bas and class modules because that was the first step (and I think the "easier" part), but it doesn't stop there.
I'm not yet sure, what kind of concept Wayne plans with regards to:Quote:
Originally Posted by Eduardo-
"VB6-compatible GUI support in an extended tB-Runtime-Lib".
I seriously hope, that he doesn't plan to "re-invent, what's already there".
(especially not, since doing so, would require an additional amount of about 3 man-years on his end).
Therefore I think, that he plans to develop this GUI-support in a "Web-based fashion".
(the existence of his little WebServer-Addon, tB currently ships with, is an indicator for that -
and also his existing experience with his current GUI-Outputs in the context of VSCode - which works WebBased (NodeJS+Electron-like) as well.
If that is the case, then our efforts with regards to GUI-support will not overlap at all:
- the RC6-lib providing a "classic, Desktop-based UserControl/Widget-concept" (able to import VB *.frm, *.frx, *.ctl, *.ctx)
- tB-GUI-RTLib providing a "Web-based (Chromium-based) UserControl/Widget-concept" (able to import VB *.frm, *.frx, *.ctl, *.ctx)
Both of the GUI-concepts I've just mentioned above, can be implemented with only "plain *.cls and *.bas support" at compiler-level.Quote:
Originally Posted by Eduardo-
(it's both "Class-library-stuff" - and not the concern of a given compiler).
And as said - both concepts can be brought to a point (quite *easily*), where you're later be able to:
- also import existing *.frm and *.ctl files (because they're both essentially "Class-definitions" underneath, with a bit of Control- and Positioning-Infos "on top")
- which would then work (exactly as they formerly did in VB6) with RC6-Desktop-Widget-mappings, or tB-WebWidget-mappings
- with the advantage, that thusly imported *.frm and *.ctl files, would work also on other platforms like Android or Linux
- either in Desktop-Widget-mode - or in "BrowserControl-based mode", Electron-like
If you'd be willing, I could explain (and demonstrate) these necessary import- transform-steps (to RC6-Forms and RC6-Widgets),
based on a simple VB6-TestForm, which uses a simple UserControl you've written (e.g. your "advanced Shape-Control").
Olaf
I don't know what he's doing and what ideas he has in mind, I only hope that he don't get misguided by wrong ideas.
About yourself: I think you already got what you needed (a compiler for bas and cls), you can write yourself your usercontrols and forms importer in RC, you don't need for Wayne to do anything else, only cross platform compilation is currently missing for you.
You can do you own "Basic" or "VB6 replacement" from what you have now.
I sure hope so as well... ;)Quote:
Originally Posted by Eduardo-
I consider anything which would introduce ActiveX or OCX-stuff into a platform-independently planned compiler, as "the wrong idea".
Any such "MS-dependency-heavy" stuff should not be part in the "official RuntimeLib" of a platform-independent compiler,
and instead be developed as a "side-project" (preferrably by those who need that).
If that's the way you think about all the current ongoing efforts, it cannot be helped...Quote:
Originally Posted by Eduardo-
Eduardo, you have to realize, that there's guys out there who have a vision -
(and who don't think about "satisfying personal needs").
As for my vision with all my ongoing efforts...
It is to ensure a (long-term) future for VB6 - and I seriously hope, that Wayne is sharing that vision...
(a future, 100% compatible Visual Basic simply cannot be restricted to "Windows-only" in the visual department... no way!).
Your vision seems to be:
Let others do all the hard work - I'm not going to invest any of my precious time...
I just want to re-compile "my old stuff" as a 64Bit-executable (on Windows-only) and be done with it.
Well, and that's not really "community-spirit at its best", you know...
I also don't know, why you have absolutely no interest in learning about,
how exactly your current investments into old controls, your old "visual stuff" -
could be brought onto a platform-independently working GUI-platform without too much efforts.
Going "platform-independent GUI" does not mean at all, that existing investments into "*.frm or *.ctl" are lost.
Olaf
That's why I said that I hope that Wayne doesn't get not influenced by wrong ideas.
As for efforts, I offer whatever I could do to achieve backward compatibility, that I believe is the key to success of a (true, not fake) VB6 replacement.
I first need to be asked to do something.
By the time being I made a Component Documenter, not so much thinking in VB6 components that are few these days, but thinking in new components (or existing, migrated) for tB and RB.
So, no. The one following a personal agenda is perhaps you.
What are you planning to do with your RC6 anyway? Do you want to be famous? Are you planning to get money? I don't understand your fixation with that component. Allow other people to do something better.
As for "learning new things", in case that you are talking about your RC6, you already got my answer many times: I'm not interested.
And every time you try to push others into the adoption of your personal project in a Jehovah Witness way, you get people more and more away (OK, some get in, as some convert to be Jehovah Witness too).
I just wonder how long your "friendship" with Wayne will last.
And BTW, I wonder who set up those fake GitHub accounts to present issues related to RC6 in the tB section.
The only relationship that success with you is of the master-slave, like with SDO (DM).
I've known exactly what you meant with "the wrong idea", already the first time.Quote:
Originally Posted by Eduardo-
But that doen't make it "the wrong idea".
Keeping up the platform-independent support not only in the compiler, but also in the supporting "official runtime" which comes with it, is absolutely the right idea.
I've already explained "my agenda" - it's bringing a Visual Basic into the new age.Quote:
Originally Posted by Eduardo-
Any new language which wants to be successful in the long-run, has to be platform-independent.
And a "special language", which focuses on "being more visual than others",
has to ensure that platform-independence also in its accompanying runtime-lib.
Why do you ask this nonsense?Quote:
Originally Posted by Eduardo-
I'm providing (and maintaining) the framework at no costs for over a decade now (so, "money-making with the RC" is ruled out already)
And I will keep my promise, to open everything up under LGPL as soon as "my vision" is reached
(when VB6-Code will run 1:1 on Win and Linux or other non-windows-platforms - but not before).
That's perhaps because you still don't understand why it is necessaryQuote:
Originally Posted by Eduardo-
(to achieve the goal of platform-independently running Visual Basic Code)
Well, the absolute best would be, when VB6-Projects:Quote:
Originally Posted by Eduardo-
- could be simply imported (without requiring you, to change a single line - not even in *.frm and *.ctl parts)
- and after that will run (as 64Bit-compiled binaries) on Windows and Linux
Can this "absolute best" outcome be achieved by using the RC6-lib?
Absolutely.
Would a new Form-Designer (or other parts not covered currently by tB+VSCode) -
require more coding-efforts, compared to e.g. an "ActiveX/OCX-based, WinOnly-supporting Form-Designer"?
No, it would require less efforts.
I know that already - but that doesn't mean I will refrain from commenting when you post stuff I absolutely disagree withQuote:
Originally Posted by Eduardo-
(like e.g. your strong preferrence of a "Win-only" VB-successor).
You got that entirely wrong - I'm primarily a tech-nerd (religious striving is sooo not my thing...).Quote:
Originally Posted by Eduardo-
From your responses it is obvious, that the purpose (and necessity) of a lib like the RC5/6 is still not understood by you
(nor is it understood by the majority of the remaining community... most of the guys with the capabilities to understand, have "migrated" long ago).
Why you're getting personal now, I have no idea.Quote:
Originally Posted by Eduardo-
But nope, there's no such thing as a friendship at the moment - only mutual respect, I hope.
How low can you get in your thought-processes?Quote:
Originally Posted by Eduardo-
Do you mean the "Mo-Lo" account?
If that's the case, then I have a slight inkling who it might be - but will leave it to himself, to reveal his Forum-identity here...
Can you cut out this nonsense, please?Quote:
Originally Posted by Eduardo-
I've mentioned it already several times (in different threads),
that I feel extremely uncomfortable with any kind of "hero worship"...
Olaf
I don't think it is "low" to notify the other when someone is trying to take you as a fool.
But whatever, I don't care anyway the quality of what you do.
About wanted a Windows-only successor, it is another lie from you.
I already said how I thought it would have to be, but anyway I'm not the designer, so it is no my decision. And I right now I don't have the time to search for it (I have to do something else at the moment), may be later (or never).
Are you still onto the topic of that "Mo-Lo" account who's posting in the tB-issue-section on GitHub?Quote:
Originally Posted by Eduardo-
What did you not understand in my reply, that it wasn't me who created this account.
It's you who's acting like a fool (seeing "ghost-accounts" where there aren't any).
???Quote:
Originally Posted by Eduardo-
Is it you, xiaoyao? ;)
Yeah - you want a lot of things (without having the slightest clue, how GUI-support like that has to be implemented,Quote:
Originally Posted by Eduardo-
to not be restricted to "win-only" (and the consequences and compromises which result from these technical implementation-necessities).
Making "wishes" with regards to "how you'd prefer GUI-support to look like" is one thing...Quote:
Originally Posted by Eduardo-
Another thing entirely, whether "such a wish" is technically considered feasible
(in the eyes of the ones who possess the required knowledge, to implement such a platform-independent GUI).
Olaf