Printable View
I think that I understand better than you what the options are and what is technically required for each one (and the constraints of each option). But I don't have to prove anything to anybody, less to you.
And no, Mo-Lo is not the only account I wonder who made it.
But who cares anyway, strange things happen all the time.
Alright you chaps, break it up, haven't you got wives and children to go home to?
That's enough fighting for tonight. Time to go home and get to bed, up again tomorrow, bright and early then we can all smile again and be one happy family.
https://www.vbforums.com/images/ieimages/2021/05/7.jpg
If tB aims to be 100% VB6 compatible I wonder how does it work to have an "independent" GUI framework that is not based on the..
window classes to emulate VBThunderForm and more..
window classes to replicate intrinsic controls etc.
So, there must be a "legacy" version which will work on windows only.
Schmidt/Olaf
that is my "vision", of what "I" like it to be.
you say its not responsible to do what I would like, but on the other hand I could say "why not".
is twinbasic just a 100% compatible vb6 and thats it?
SearchingDataOnly wants more features from VB.NET. that could also be said, "its not responsible", u need to work with that u have, instead of "upgrading" it, as you seems to not want that.
you want your RC6 to be used as the "magic" component that we can use to "please" our needs.
that for me is also making u bias to it and of course critical to anything that could replace it or compete with your RC6.
my requests will make your RC6 obsolete, as I only need a good and stable render-method as everything else VB6 is enough for my needs.
I think you are scared that twinbasic will have it all and make your effort wasted.
that is also why I posted about integrate RC into twinbasic, as that would make me more interested and maybe even use it.
but it need to be integrated in a way that it will feel "right", VB6-right. not Olaf-right.
but again as always, the post I made about integration I didnt get a good response, instead I need to knee down and praise and just accept that Im a lower species.
that is also one reason I dont use RC, because of the way you treat others. to get respect you also need to give respect. if you piss on others, others will piss on you.
That's not, how I understand the "100% goal".Quote:
Originally Posted by Krool
I understand it as "the language being 100% VB6-compatible" - and I think that goal is absolutely achievable
(even for a VB6-compatible compiler which supports and works on other platforms).
IMO, as soon as *.cls and *.bas modules work, the 100% goal is already fully reached.
What more do you expect from the author of the compiler?
That he replicates each and every OCX which was ever produced in the last 25 years?
(so that any imaginable *.frm code imports without the slightest hickup?)
It's an impossible task - somewhere you have to draw a line...
All I can imagine as a "reasonable effort for the runtime, regarding GUI", is the support for the intrinsics:
TextBox, CommandButton, ListBox, ComboBox, Image, PictureBox, Frame, Timer, etc... because those are "simple enough" - but not much more.
And I would suggest, that the hWnd and hDC props of these Intrinsics, should be marked "deprecated" as well
(so that there's at least the chance to write different implementations for the intrinsic-abstraction-layer when it is used on other platforms).
Because when you have a platform-independent compiler (and GUI), one is well-advised,
to use Win32-APIs as "sparsely as possible" (including the "SubClassing" everyone loves so much).
Stuff like that should not make it into the runtime-lib of such a compiler
(just my personal opinion, though Wayne might have a different stance on that).
Why is that so important?
Because of "protection of Code-Investments" (primarily the ones, which are about to be written in tB-Code).
Because *if* system-specific stuff would be supported in the official runtime, it'd send "the wrong signal" -
in that it encourages users (who don't know better), to write a ton of platform-specific code without realizing it...
who then start "blaming the tool" (as soon as they realize, that they have to rewrite it *completely* - to be able to run it on non-windows-systems).
Olaf
Enough with the bickering.
In the posting you probably mean (#152?), I've gone to some length' to explain what's:Quote:
Originally Posted by baka
- the responsibility of a compiler
- and what's better addressed by (Class)Libraries (no matter if a "runtime-lib" or an "external one")
- and continued to describe, how the RC6 would address concrete issues, mentioned in your citation
If you felt offended by a purely technical explanation (can't find anything in that post, where I "got personal" with you), then I cannot help it...
And here *you* go, getting personal... (instead of searching a technical discourse with me,Quote:
Originally Posted by baka
for example by clearly describing what exactly you mean with the term: "VB6-right").
I also don't know, what you mean with "Olaf-right" exactly, because (according to your own words) -
you've never used the RC5/RC6 (or any RC-related code, written "by Olaf") in your own apps so far.
Olaf
Krool, it may be possible to access/run-on apple hardware with an alternate Windows boot shell. I think that is supported until at least 2029, but you have to use an older version of Windows to setup, because they removed the ability in the control panel. I'm running a Samsung T5 with alternate boot setup on it, utilizing the Windows Enterprise image. The student edition also works if you have a license for that. Does anyone have any experience running on non-windows hardware like that?
EDIT: Video showing secure desktop shell running in tandem.
https://www.youtube.com/watch?v=9eQ1D0yeN5c
Ok, the "bickering-posts" are gone ... (including mine).Quote:
Originally Posted by Shaggy Hiker
JFYI, you were probably unaware, but a youtube-link to "Jordan Peterson" vanished along with them into the gutter.
(can already feel unimaginable amounts of "Karma" building up)... ;)
Olaf
I don't know who that is. Does karma build up on unrecognized side effects?
hi OlafQuote:
Originally Posted by Schmidt
but it says on the TwinBasic website:
In my reading of it that sounds like he's going to support forms as clearly as he does modules and classes?Quote:
Once we have finalized and fixed up any bugs in the first release of twinBASIC, we will be focusing on three key areas over the coming weeks and months:
Forms / GUI support, including full backwards compatibility with existing VB6 forms.
Native compilation.
Cross-platform compilation.
(But actually I'd be perfectly happy if instead of a windows form my gui appeared in a browser window.)
Absolutely! That's the worst kind...Quote:
Originally Posted by Shaggy Hiker
I guess we will see, what exactly Wayne meant with that... ;)Quote:
Originally Posted by vbrad
And as said 100% compatibility at language (compiler-) level can certainly be achieved,
(even down to the pointer and struct-level, when the Variant-, BSTR, SafeArray allocations, and VBClass-VTables are kept identical, which the tB-author already did care of AFAIK).
Another matter entirely are "Forms" (and Controls).
Just think about it yourself for a bit.
E.g. when you have a Form with an MSHFlexgrid on it...
Then the only way to run this Form "fully compatible in tB" is: to load the original MSHFlexGrid, period.
If you resort to doing that (as the author of that kind of "import-mode", then (IMO) - you send the wrong signal:
- because this imported tB-Project (which contains this Form) will never work on other platforms
- and because this Form (with that HFlexGrid from MS) can only work as long as MS supports the 32Bit-mode
But isn't that latter point exactly, why most users here plan to switch from VB6 to tB?
(protection for your code, when MS decides to ship a "64Bit-only Win-OS")
See, this mode (loading an existing OCX, which exists only in a 32bit version) is basically pointless to be supported by tB - because:
It will only work as long as the OS ships with a 32bit layer - and it will fail as soon as the OS ships in "64bit only".
But wait, the above sentence is true also for your existing VB6-compiled App... (it will work, as long as MS ships the OS with a 32bit layer).
So why trying to import this "old App, with the old 32Bit only OCX on your Form" into tB in the first place?
So, a "worthwhile Form-importer" (one that will not choke, when MS switches to 64bit only mode),
can only be accomplished for:
- a limited set of selfwritten Controls/Widgets in a tB-provided or external GUI-lib
- for which "mappings" exist in the Loader-mechanism of the targeted "new Form-Engine"
Note the word "limited" in the above point...
You simply cannot expect, that 100% compatible Widget- or Control-wrappers will be written for each and every 32bit OCX which floats around in the wild (in old, still working VB6-Apps).
To conclude:
- "100% at language-level"? ... absolutely possible - even for VB6-code on other platforms
- "100% at Form+Control-level"? ... only possible for a (comparably small) SubSet of the Controls, currently used in existing VB6-Projects
And the thing with that "SubSet of Controls", for which compatible Wrappers have to be implemented is,
that the efforts for:
- writing them already platform-independent (able to work on Win and Linux, in both, 32bit and 64bit mode)
- writing them "Win only" (with the goal to achieve 64Bit-compatibility on Win-only)
are about the same (well, less when these Widgets were written, based on the RC6).
Exactly that topic is a "hard decision" to make for any "provider of a new IDE",
because you will cause "disagreement in either case".
What might help in this regard is, to "look at it long-term" again (the "vision" the author of a new language and IDE has in mind)...
If a given author decides, to make a dozen of old VB6-devs happy with "Win-only GUI and Controls"-support
he's risking loosing hundreds, if not thousands of younger devs, who will ignore your tool, because of "Win-only" -
and the same "Win-only" reason will affect the Tiobe-ranking as well.
That's (IMO) the classic "shooting yourself in the foot"-scenario, because "making this small group happy" -
will be even more pointless, when the author later (in 2031) realizes, that it was all for nothing, because "VB6-compiled 32bit Apps still work".
HTH
Olaf
I think tB will make a lot of people happy who use 64 bit VBA. Those guys "stick" already to Windows so the mantra of cross-platform is not that crucial.
It will help to create add-ins for MS office and allows displaying forms.
And finally it will encourage to finally solve the all time 64bit OCX issue by porting UserControls to tB which then runs on 64 bit host systems, such as VBA.
This is a great niche.
So TwinBasic will not offer a path for projects containing all but a few controls?Quote:
Originally Posted by Schmidt
That would make it uninteresting for a lot of people who rely on grids a lot for example.
I was hoping for at least support for all the built in controls and then for some others,
of of these MSHFlexgrid would be one that is very widely used for business applications.
@VBRad, if it needs to be 100% compatible with VB6 then you can stick with VB6.
If you want to target 64bit you need to make a choice, you can't have both worlds when only the 64 bit world is supported by the OS.
In my case except 1 control I use (and OCX exists also in 64 bits), all are 100% written in VB6, so just recompilation for 64 bits.
Unless doesn't support all built in controls?Quote:
Originally Posted by Thierry69
Krool, Are you willing to speculate whether your controls are likely to operate on TwinBasic/RADBasic from what you've seen so far? Or is there something that makes you feel pessimistic.
How many of your own controls work without making some use of a Windows API? I expect the majority use at least one. I obviously haven't delved deep into your code.
AFAIK, twinBASIC will use for the "windows version" anyway certain MS APIs for it's runtime (oleauth etc.) to be compatible. Maybe Wayne can comment on this.Quote:
Originally Posted by yereverluvinuncleber
To your question:
VBCCR is heavily windows based as these classes are windows only. VBFlexGrid uses GDI for drawing, so you can say it's also "windows".
So will tB allow me some day to port these? So they get 64bit support? I don't know.
Would it be worth? IMO yes, businesses use heavily MS office products with a 64 bit COM host system. (VBA)
But making them Cross Platform requires a complete new development.Quote:
To your question:
VBCCR is heavily windows based as these classes are windows only. VBFlexGrid uses GDI for drawing, so you can say it's also "windows".
So will tB allow me some day to port these? So they get 64bit support? I don't know.
Would it be worth? IMO yes, businesses use heavily MS office products with a 64 bit COM host system. (VBA)
That's why I think the focus on Cross Platform should only be done for new projects, not for existing projects which rely on external OCX components or even Office Automation
Without wishing to get involved in the bickering, I'd suggest posters look at what twinBASIC have already said...
https://twinbasic.com/Quote:
Once we have finalized and fixed up any bugs in the first release of twinBASIC, we will be focusing on three key areas over the coming weeks and months:
- Forms / GUI support, including full backwards compatibility with existing VB6 forms.
- Native compilation.
- Cross-platform compilation.
and
https://www.vbforums.com/showthread....t=#post5515954Quote:
when it comes to cross-platform, the feature set will indeed have to be much more limited. Certainly no GDI/direct2d/etc, as you'd be better off running under WINE for such things.
on the point of cross platform.
Speaking from experience, I have ported a vb6 app to macos using lazarus.
many of my controls including the flexgrid did port with minimal intervention.
I think cross platform can be achieved, but for most projects that will require some manual changes to port to cross platform user controls
I do not think its a show stopper at all.
added later:
to completely say it has to be one or the other is bad. if it initially works just in windows and then takes a few days/weeks to make it work on a another platform is fine and acceptable.
Hi axisdjQuote:
Originally Posted by axisdj
This is very interesting. I'd like to hear what you think of Lazarus after such a project. Are you impressed or disappointed? I spent a little time experimenting in Lazarus There are a couple of grids
built in there as I remember but they seemed very limited in functionality compared to the MSFlexgrid. How did you overcome that?
Another idea would be to use an interop hybrid control set that utilizes VB.NET user controls as individual control types.Quote:
Originally Posted by Krool
This already works in VBA with the interop toolkit. With cross-addin vb6/vba support, almost anything can be achieved in the future for business applications.
I wonder if TB will support VB.NET user controls, or the hybrid interop user controls?
A few years ago, I developed an extremely powerful Spread with pure VB6, and later I used Cairo (you know what it is) to completely rewrite my Spread, which perfectly implemented/simulated all the features of the original Spread (to be precise, more features have been added).Quote:
Originally Posted by Krool
In other words, you can use Cairo to rewrite all the controls in your VBCCR without any problems. The interfaces of the new control are exactly the same as your VBCCR. After you rewrite your VBCCR with Cairo, I believe it can become a cross-platform product. If you need help, I can help you. I believe that other real Cairo experts here will also support and help you vigorously.
Note:
I dare not mention the VB framework related to Cario, because some of the dark forces here are too strong.
Here is the latest update on the status of the twinBASIC preview...
twinbasic weekly update
It's an art to maximize the functionality of a programming language through minimal grammatical/semantic features.
We seem to see twinBasic.NET
how to use Cairo?Quote:
Originally Posted by SearchingDataOnly
Do you have a tutorial,
Why do you ask? (you were already there...)Quote:
Originally Posted by xiaoyao
https://www.vbforums.com/showthread....cs-using-Cairo
In case the question was with regards to "cairo-drawn Widgets" - I've just uploaded an appropriate Tutorial for that as well:
https://www.vbforums.com/showthread....dgets-Tutorial
Olaf
The twinBASIC presentation at Access DevCon 2021 is now on YouTube...
https://www.youtube.com/watch?v=dBvMBAUSyT8&t=14s
Thanks.Quote:
Originally Posted by VB6 Programming
well done presentation. not boring and informative. not sure about his "bold prediction" but who knows, could be happening. :D
Ok took the step to try out this thing, as I really like what I have seen and read so far... and of course I ran right into trouble. Not sure if this is something for github bug issue and just be something simple I have overlooked someone already has experienced. So, installed default VSC (User) for Win10, found and installed the twinBasic extension, downloaded the tb project zip, unzipped and opened it as a new workspace in VSC. So far all fine. Then I started to follow the rearrange of the WS as shown by Wane in the introduction video, but when I moved the Stack frame something went wrong, and I got this message in the TERMINAL tab:
I think I somehow managed to start the debugger as the icon shown in the video on the Stack panel header is not to be seen, and in the panel there are 2 items "Running..." and they cannot be killed. When I try to run the "hello World" without debugging Shift+F5 it complain complains about a missing "twinBasic debugger extension". Oh my, so I uninstall tb and install it once again and now the code file wont even open. Below EXPLORER I have a HELLOWORD panel, with 2 empty folder items "BUILD CONFIGURATION !" and "PROJECT: HellowWorld !" and a blank code window pain, except for a watermark with keyboard short cuts.Quote:
Warning: This shell is running on your local machine
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Try the new cross-platform PowerShell https://aka.ms/pscore6
PS C:\Users\Joakim>
So how can I get out of this mess and start all over again?
EDIT: I forgot to say that before I uninstalled and reinstalled, I tried to close the workspace and open it again with fresh files from the tb project zip, but it went right into the same situation with 2 items "Running" in the stack panel, and that's why I decided to uninstall and start allover, which apparently have made it worse as VSC seems to remember something no longer current or something like that.
and one more thing, there were some recommendation to install a "debugger for firefox" extension, which I didn't do as noting was mentioned about it on tb page and I don't like to bloat the new environment with stuff I don't need.
Quote:
Originally Posted by 7edm
I had the same kind of problem after updating from 1.52.1 to 1.56.2
I uninstalled everything and reinstalled 1.52.1 and everything came back okay.
Hmm, sounds like you almost had it right at one point actually. Ctrl+F5 (start without debugging) is not currently working with twinBASIC, so will currently display an error. You can run without debugging, just by using the 'Build' button on the twinBASIC panel.Quote:
Originally Posted by 7edm
Please try the following steps:
Close the workspace (File menu > close workspace).
Uninstall the twinBASIC extension.
press F1 > type 'View: Reset View locations'
Uninstall VS Code.
Resinstall VS Code, and follow the quick set up video again.
Let me know how you get on.
Thanks Wayne, that brought back the "HellowWord.twin" to open in the editor again, but something is still not ok. While the "VARIABLES", "WATCH" AND "CALL STACK" panes, which I earlier moved to the right side, went back to the left side, the "DEBUG CONSOLE" stayed to the right.
And the same Power Shell warning shows up in the Terminal panel, and when I click the "run guy" icon to run the code in the debugger I get in the Debug Console:
1st row: a circle with "2" inside, and "Executing 'HelloWordProject.ModHellowWord.Main'...
2nd row: "RunCodeUnderCursor failed: main thread is busy.
ok will leave it as is to not screw up before some further feedback.
EDIT: the DEBUG CONSOLE pane header also has a circle with a 1 inside
Ops my bad, it was busy because there was a "hellow world" msgbox hiding behind VSC, and on retest I notice that when I click the run guy icon, the box indeed comes up behind VSC (it staying "on top".
Another strange thing though. There is a vertical "stripe" to the left of the right panel column covering/overlapping the editor window (see arrow on image) and I have no idea where it's coming from (is there from start up) or how to get rid of it? (ok got it, that was from menu: View->Show MiniMap which I must have been clicking on while solving my problem. So all go and ready to Go then I assume :)
The twinBASIC weekly update is here...
twinBASIC weekly update May 16 2021
How does TwinBasic intend to handle or introduce the concept of multi-threading to VB6?