No troll. What are the (legitimate) reasons people are still using VB6 ?

[dreammanor]

Deleted the error post!

[dreammanor]

Deleted the error post!

[Schmidt]

Enormous and useless...

That's my cue to ignore anything you have to say.

Really now?
So why on earth did MS come up with .NET-Core + VSCode (bundling stuff up in much leaner incarnations)...
if not for exactly that reason?

Olaf

[DEXWERX]

@Shaggy we agree far more than we disagree. I used to think code collapsing was a must, when it first started turning up in text editors/IDEs. It turns out I stopped using it altogether a few years ago (except in config type files). If a piece of code seems like it really needs collapsible sections, to me it's a hint that it needs to be refactored (double so in BASIC dialects). Just pointing out an obvious difference of preference between us, that we should celebrate rather than quibble over.

You mention debug / edit and continue however you have the same and actually probably a slightly superior debugging experience in the .Net IDE mainly because you can debug across projects much more easily then in VB6 and things like conditional breakpoints.

So easier than starting 2 IDEs Or using Debug.Assert? amiright?
I think the only thing I prefer from VS debugging experience is the stack trace.

[jmcilhinney]

I hate .NET for a lot of reasons. One of the reasons is this:

That sounds like a reason to not use it but to hate it? That says more about you than VB.NET, I think.

The problem is that you can't simply "don't use it". And it's big, really big. Enormous and useless, and it's development meant that nothing else was properly progressed since. So, I think I can say I hate it.

That's my cue to ignore anything you have to say.

Really now?
So why on earth did MS come up with .NET-Core + VSCode (bundling stuff up in much leaner incarnations)...
if not for exactly that reason?

Olaf

So you're saying that you agree with Carlos Rocha that .NET and/or VB.NET and/or VS.NET is useless and it's your contention that Microsoft thinks so too? Is that really what you're saying and, if not, why are you saying it to me?

[Shaggy Hiker]

Really now?
So why on earth did MS come up with .NET-Core + VSCode (bundling stuff up in much leaner incarnations)...
if not for exactly that reason?

Olaf

Because...progress means moving things forwards.

[Shaggy Hiker]

@Shaggy we agree far more than we disagree. I used to think code collapsing was a must, when it first started turning up in text editors/IDEs. It turns out I stopped using it altogether a few years ago (except in config type files). If a piece of code seems like it really needs collapsible sections, to me it's a hint that it needs to be refactored (double so in BASIC dialects). Just pointing out an obvious difference of preference between us, that we should celebrate rather than quibble over.

Yeah. Originally, VB.NET didn't allow you to put collapsible sections inside methods. You couldn't collapse things like If...End If blocks, and you couldn't add Regions within methods. People were saying things like what you said, and I was thinking, "what are you talking about?" Now I know. C# has allowed more collapsible variations, which VB.NET did not. Now that VB has added those regions, I totally agree with you. Being able to collapse regions within methods allows you to do some pretty bad things by hiding the dirty laundry. What WAS the case with VB was more rational. You could collapse methods, and you could add Regions to group sets of methods into an area that could be collapsed (such as Properties, or private methods, or something like that).

[Shaggy Hiker]

So yes i have VB6 installed and yes i have used it in anger

This has always amused me. I realize it's a British phrase that simply hasn't hopped the pond, but whenever I read something like that, I always think of JavaScript: If you've used it much....you've certainly used it in anger.

[Carlos Rocha]

Because...progress means moving things forwards.

@Shaggy, you call it progress and moving forward. I call it correction of a big mistake. And I mean BIG.

[Eduardo-]

Because...progress means moving things forwards.

You should be a politician.

[NeedSomeAnswers]

So easier than starting 2 IDEs Or using Debug.Assert? amiright?
I think the only thing I prefer from VS debugging experience is the stack trace.

Well yes i would say it is, I can and generally do have multiple projects inside a single solution and debugging across them is just standard rather than having to add them into a project group or something like that.

Stack trace i forgot about that one another really great addition, see your doing my work for me now

This has always amused me. I realize it's a British phrase that simply hasn't hopped the pond

I used that phrase without even thinking about it but yes its a very British thing to say thinking about it.

[Schmidt]

So you're saying that you agree with Carlos Rocha that .NET ... is useless
and it's your contention that Microsoft thinks so too?

Yes, of course I agree with him (thought I made that clear already).

Mainly because he mentioned "useless" in context with "big" + "enormous" (so please try to combine the two things in your thoughts).

Perhaps a better word-choice would have been "pointless" instead of "useless"...

To use something "big and unwieldy" is pointless:
- when leaner tools already exist
- which do exactly the same thing
- and offer basically the same productivity for the tool-user
- whilst saving time and money

There might be VB6ers who really hate .NET - but I'd like tho think, that most of us just tried to ignore it.
(along the lines of: "The opposite of love is not hate - it's indifference").

See - it's not us, who go over into the .NET-subforums to "stir things up" - it's always you guys who come over here -
and I wonder why...

Companies (or selfemployed devs) who saw it coming (it was not that hard to see, really) -
and ignored or skipped .NET (the "monster-version(s)" I mean, not the lean reincarnation in .NET-core),
simply made a reasonable decision.

Whereas companies who (without need - often triggered by management-decisions, not by developers free choice)
re-implemented an already well-working VB6-App in .NET, wasted huge amounts of developer-time (and money).

Technically, there was never a reason to use .NET - it's only "advertisement-driven business-decisions"
which led to the situation we have now... (although MS is finally trying to correct its mistakes with .NET-core).

Olaf

[Shaggy Hiker]

@Shaggy, you call it progress and moving forward. I call it correction of a big mistake. And I mean BIG.

I know you feel that way, and you're entitled to it. VS has certainly grown. It was C/C++ and VB back in the 90s. It still has C/C++, but added C#, F#, and VB.NET. More recently, it has added Xamarin, a pretty good JS editor (it was added at least by 2015, but is pretty good as of 2017), Python, and others. I suppose MS is kind of going for "one IDE to rule them all". Is that big? Absolutely. Is that useless? Only if you don't use any of that.

My point with progress is that it does mean change. Half the objections from VB6 fans is that it is not being extended, the other half seems to be fear that the arrow isn't going in the direction they'd like. We hear complaints about all the different frameworks. You don't have that with VB6 because it isn't being developed. If it was, you'd be dealing with the same thing. The VB6 runtime is built into the OS, and has been for a very long time. The .NET runtime is built into the OS, but since it is still being developed, new runtimes keep coming out every few years. Many are built into the OS, some are too new. What .NET Core will do is mean that there won't be a runtime. Even VB6 has a runtime that has to be there for the applications to work, you just don't need to worry about it because it's fixed and unchanging. Of course, .NET Core won't do all I'd like, because it's cross platform, and no UI is truly cross platform, at this point. Xamarin may get there...or not, but that just gets back to the "use it in anger" quip.

So, progress, change, maybe even making things better...and maybe not, but still progress, change, evolution. That's what happens with systems still under development.

[Schmidt]

C/C++ ... JS ... Python...
"one IDE to rule them all".
Is that big? Absolutely.
Is that useless? Only if you don't use any of that.

Umhh, there's leaner (and IMO better) tools, to develop with these languages.
Which again brings up Carlos and my point - "big is useless, when a leaner tool exists which does the same thing".

You might try Komodo or JetBrains IntelliJ for JS-development.

What .NET Core will do is mean that there won't be a runtime.

That's wrong - even C-produced binaries need a system-specific runtime-lib.

So, progress, change, maybe even making things better...and maybe not, but still progress, change, evolution.

Yep, exactly - Evolution... which happens in a tree-like fashion - with many dead branches along the way...
(and there's no reason - at least for me - to follow the wrong branch twice).

Olaf

[DllHell]

Technically, there was never a reason to use .NET

I'd love to have reflection, better oop, function overloading, consistent 0 based arrays, etc in vb6.

And the latest open-sourcing means that if\when MS moves on, they won't be stuck like we are.

[Carlos Rocha]

I'd love to have reflection, better oop, function overloading, consistent 0 based arrays, etc in vb6.

And these things would probably be in VB6 along with some other, like 64bit, if they didn't decide to turn things into a wrong direction.
And probably MS would have now a word to say in the mobile market. And in the web.

Now they are running after the lost time, but with a big hole in the foot.

[Shaggy Hiker]

And these things would probably be in VB6 along with some other, like 64bit, if they didn't decide to turn things into a wrong direction.
And probably MS would have now a word to say in the mobile market. And in the web.

No they wouldn't. MS screwed up in the mobile market for totally different reasons. .NET was FAR better at writing for the early form of mobile. However, then Apple did their thing. MS never came up with a suitably functional competitor to the Apple ecosystem. They did once before, of course. Back in the 80s and early 90s, the situation was roughly the same: You could spend a lot more money to play in the closed garden of Apple, or you could spend less and live in the free-wheeling landscape of DOS. There were arguments to be made either way, largely around safety/quality control versus more weirdness but far greater versatility. MS didn't do that with mobile, but Android did, and still is. Apple is safety and quality control, Android is more open, free-wheeling and has a larger total share. MS...well, they weren't so open, and they weren't so safe. They kind of adopted the worst of both worlds, just without any real vision, either.

VB6 would be worse than bad for mobile, unless it were RADICALLY re-written. What made VB6 so popular was that it was easy to get up and going. You could build a nice looking form with drag and drop without even knowing how to program. Figuring out what happened behind those buttons....you could put it off if you wanted to. I would guess that a whole lot of people learned by doing rather than the far more tedious options available at the time.

That's not the case when it comes to mobile. A UI designed for mouse and keyboard would be terrible on a tiny screen. It might even be usable, but it won't be good. The sizes of things, the contrasts, the positioning, not only do they all have to change, but they all have to be able to change dynamically. The same application might change aspect in an instant. Nobody ever turned their CRT monitors sideways just to check (well, somebody may have, cause everything is possible). To make a really responsive mobile UI, you need to be able to be totally flexible, on the fly, as far as where things are located, and how big they are. Windows Forms doesn't have that capability, and you can't add it easily. Of course, you CAN add it, but not easily, so the advantage of VB6 has gone away. VB6 wasn't the only language. It wasn't the most powerful. It was the easiest to learn and easiest to use. When you abandon that...you might as well be writing in C.

So, thinking that VB6 could have allowed MS to come up with some excellent mobile device is ignoring the fact that there isn't an excellent means to deal with the multi-touch, rapidly changeable, nature of mobile devices. There are means. There are means that work. All those means are C to VB6. You didn't love the language because it was all that there was, you loved it because it was easy to learn and easy to work with. Once you throw those out....what do you have left? Not a tool that will cause people to beat a path to your mobile phone.

[Schmidt]

I'd love to have ...

- reflection ... is already built-in (in any VB6-produced COM-binary)
- better oop ... what exactly are you missing (remember that "inheritance is discouraged from" in the meantime)
- function overloading ... I find the concept of Optional Params and ParamArrays far better suited for the task, seriously
- consistent 0 based arrays ... that's the default I thought (I sometimes use other LBounds, but rarely - but am glad to have the choice)

And the latest open-sourcing means that if\when MS moves on, they won't be stuck like we are.

Oh, they are - believe me...
Every ".NET-WinForms-App" will have to be rewritten at the same time VB6-Users will have to "switch to something else".

Olaf

[Schmidt]

VB6 would be worse than bad for mobile, unless it were RADICALLY re-written.

That's totally wrong.

VB6 is an Event-driven language (all modern ones are)...
Theres perhaps 50 lines of Code to write (once), to provide VB6 with a multi-touch EventProvider
(wasn't there something entered into the VB6-codebank the last days?).

And a "Container-Resize"-Event is already there (which only needs to be linked to the systems "device-orientation-changed"-message).

Add to that a simple Layout-Manager-Class (just 100 more lines, later triggered from within the Resize-Event) -
and you can *comfortably* develop self-layouting Forms with VB6 "for years to come", starting right now.
(there's Win10 Tablet-devices out there, where you can test all that stuff).

Mobile-development is *very* similar to what most of us currently do, when they use TabStrip-Controls
(just that the "tabs" you hosted in VB6-Containers are now called "pages" - with only one of them visible at any given time -
and tab-switches are usually triggered by a "swipe"-event instead of a "tab-header-click"-event).

But that's it already (basically).

Olaf

[Elroy]

So, thinking that VB6 could have allowed MS to come up with some excellent mobile device is ignoring the fact that there isn't an excellent means to deal with the multi-touch, rapidly changeable, nature of mobile devices.

WOW, Shaggy. I know you're a moderator, but you're starting to sound like a troll in this thread. Why would you say such a thing?

VB6 does just fine differentiating between a _Click and a _DblClick event, handling each appropriately. Why couldn't VB6 have evolved to have a _Touch, _MultiTouch, _TouchResize, _TouchScroll, and whatever else we needed to deal with touch screen interfaces?

If Microsoft had kept developing the VB6 COM architecture, possibly allowing it to have "Tablet Mode" forms, possibly even adopting it to other OS platforms ... I don't see any reason that it couldn't have continued to evolve.

Personally, I think the biggest problem is that Microsoft sees itself as a purveyor of Windows, Office, and attempts to sell their SQL Server stuff. (Ok, they also sell some hardware.) Just look at their homepage. Developer languages are almost an afterthought.

I suspect the same sort of thing is true of Apple, Google, Oracle, and others. They want to sell their hardware and the core software (i.e., OSs and their own production software) that runs on that hardware. That's where the big bucks are.

They just all know they must provide some language support to appease us developers, but that's really small potatoes regarding revenue.

And just as an aside, I know they've at least partially ported their COM architecture to macOS. VBA code runs just fine on Macs.

And again, Microsoft just fails to see how upgrading the VB6 COM based language to these platforms (Surface Mode, macOS, Android, iOS, possibly even Roku, Fire-Stick, etc) could make them large amounts of immediate money. However, personally, I think it would be a huge medium-term boost to their prestige if they were to do such a thing, and it would pay off in the long-run. Personally, if Microsoft worked at it a bit, I think a VB6.5 could become a multi-platform competitor with Java.

Take Care,
Elroy

[DllHell]

- reflection ... is already built-in (in any VB6-produced COM-binary)

You have a class in your vb6 project. How do you dynamically list props and their types or invoke methods? You can't which is a pain point if you want to do it

- better oop ... what exactly are you missing (remember that "inheritance is discouraged from" in the meantime)

this has been beaten to death. for people that want oop, it is missing.

- function overloading ... I find the concept of Optional Params and ParamArrays far better suited for the task, seriously

I've used both and the ability to have functions that take clearly defined objects or types is much nicer to look at. But you can still use paramarrays in .net so you have twice as many choices

- consistent 0 based arrays ... that's the default I thought (I sometimes use other LBounds, but rarely - but am glad to have the choice)

for some things, but not others. And the fact that there is confusion about this means it was definitely a mistake.

Oh, they are - believe me...
Every ".NET-WinForms-App" will have to be rewritten at the same time VB6-Users will have to "switch to something else".

.net <> winforms. And winforms is going open source (https://www.hanselman.com/blog/Annou...penSource.aspx).

[DllHell]

WOW, Shaggy. I know you're a moderator, but you're starting to sound like a troll in this thread. Why would you say such a thing?

VB6 does just fine differentiating between a _Click and a _DblClick event, handling each appropriately. Why couldn't VB6 have evolved to have a _Touch, _MultiTouch, _TouchResize, _TouchScroll, and whatever else we needed to deal with touch screen interfaces?

I think Shaggy is right. It would have to be a massive rewrite. The issue isn't adding events or modifying features, its getting the vb6 vm to run on low power chips. There is too much Windows baggage.

But they are creating a platform for all devices, it just isn't vb6, its .net core

[Schmidt]

You have a class in your vb6 project. How do you dynamically list props and their types or invoke methods? You can't which is a pain point if you want to do it

Ok, here we go... (shows, how much you don't know about VB6 and COM)...

Private Sub Form_Load()  'this example needs a reference to vbRichClient5
  Dim Props As cProperties, Prop As cProperty
  Set Props = New_c.Properties
      Props.BindTo Me 'bind the Property-Enumerator to a VB6-Form-Object
      
  For Each Prop In Props 'enumerate the Properties of the VB6-Form-Object
    Debug.Print Prop.VarType, Prop.Name 
    If Prop.Name = "Caption" Then Prop.Value = "Hello World" 'set the Caption-Prop to a new Value
  Next
End Sub

this has been beaten to death. for people that want oop, it is missing.

No, for people who do OOP properly, inheritance is a "no-go" - we should mention that more often I guess, so that it finally sinks in...

I've used both and the ability to have functions that take clearly defined objects or types is much nicer to look at.

Definitely not.
Just take .NETs intellisense as an example -
you will not only have to find "a single function-name in a class" - no, now there can be dozens of them which pop up suddenly
(but no problem - just go through a few more steps - but look really carefully, to not choose the one with the wrong param-types)

But that's fine I guess - one can sell that whole mess later as "superior intellisense"

.net <> winforms. And winforms is going open source...

Yep - Read: "obsolete GUI-tech was now dumped onto GitHub" (same goes for WPF).

Doesn't change what I said though:
- .NET-Desktop-Apps are to 90% based on a WinForms-GUI
- and every single one of them is "dead in the water" already (has the very same lifespan as VB6-Apps - and needs to be rewritten soon)

Olaf

[DllHell]

Ok, here we go... (shows, how much you don't know about VB6 and COM)...

Private Sub Form_Load()  'this example needs a reference to vbRichClient5
  Dim Props As cProperties, Prop As cProperty
  Set Props = New_c.Properties
      Props.BindTo Me 'bind the Property-Enumerator to a VB6-Form-Object
      
  For Each Prop In Props 'enumerate the Properties of the VB6-Form-Object
    Debug.Print Prop.VarType, Prop.Name 
    If Prop.Name = "Caption" Then Prop.Value = "Hello World" 'set the Caption-Prop to a new Value
  Next
End Sub

I keep getting the error "vbRichClient5 not found"

Yep - Read: "obsolete GUI-tech was now dumped onto GitHub" (same goes for WPF).

I'm sure the community would be able to do great things if they "dumped" the source of c2.exe on github. But what do I know? I'm just a dumb vb6 user

[Schmidt]

I think Shaggy is right. It would have to be a massive rewrite.

That's nonsense.

The issue isn't adding events or modifying features, its getting the vb6 vm to run on low power chips.

You have to be kidding me.
VB6 (and its runtime) *was* designed "in an era, where low power chips were the norm"...
(and the VB6-Runtime did even run on RISC-Processors, which were sold around that time with an appropriate Win-NT/Win2000 for 64Bit DEC/Alpha-CPUs).

The typical hardware-components in 1998 were a single-core Pentium III with 300MHz and 128MB-Ram.
(current phones have typically 8-core CPUs, each core being about 4-6 times as fast as the P III of that era - Ram typically 4-8GB)

Besides VB6 comes with a native C-compiler (C2.exe) - and C-compiled binaries are the base for Googles Java-Stack on Android.

Olaf

[Schmidt]

I keep getting the error "vbRichClient5 not found"

Shows your reading-ability.

But Ok, then you will have to use tlbinf32 instead I guess... (oh, wait - you will have to check the appropriate reference in first... just saying...)

Olaf

[Schmidt]

I'm sure the community would be able to do great things if they "dumped" the source of c2.exe on github.

This will never happen, because they only dump stuff which is no longer relevant in terms of revenue.
VBA is still one of the most important parts of the MS-Office-Cash-Cow...

Olaf

[wqweto]

VBA is still one of the most important parts of the MS-Office-Cash-Cow...

Why would they ship c2.exe with office?

Anyway, I though office was moving to "normal" languages like Python and JS. . .

cheers,
</wqw>

[DEXWERX]

Why would they ship c2.exe with office?

Anyway, I though office was moving to "normal" languages like Python and JS. . .

cheers,
</wqw>

We'll see if that fairs any better than switching Office scripting to .NET. (which was a failure)
Looks like MS is just letting InfoPath die altogether, after switching to .NET.

progress!

[DllHell]

You have to be kidding me.
VB6 (and its runtime) *was* designed "in an era, where low power chips were the norm"...
(and the VB6-Runtime did even run on RISC-Processors, which were sold around that time with an appropriate Win-NT/Win2000 for 64Bit DEC/Alpha-CPUs).

You are right. I remember the glorious WinCE which bright the power of windows to devices running low power chips.

I'm sure you remember too. When they worked really well? Lasted all day on a charge? Had decent process management?

[Schmidt]

Why would they ship c2.exe with office?

You seem to think, that C2.exe works independent from the VB6-VBA-engine.
whereas I'd think, that it does depend on (larger parts of) it.

So, releasing C2.exe as OpenSource standalone would not make much sense I guess...

And as already stated several times in different threads.
The Compiler is *not* the problem - the VB6-like - thight IDE-Compiler-integration is the problem.

If an isolated C2.exe were released as OpenSource, then you have a FreeBasic2.0
(without any GUI or IDE) - same situation as with FreeBasic now (where a VB6-comparable IDE is nowhere in sight).

Olaf

[Schmidt]

I remember the glorious WinCE...
I'm sure you remember too. When they worked really well? Lasted all day on a charge? Had decent process management?

I'm not sure, what this has to do with C-compiled binaries, which run on modern ARM-processors
(as fast, as the C-compiler was able to optimize those binaries).

The performance of a (theoretical) VB6-output (running a C2.exe which can target ARM-architecture),
would be "on par with everything else you see currently running on the mobile devices"...
(if not better, because the VB6-binaries won't have to go through a .NET- or a JAVA-layer first).

Olaf

[Shaggy Hiker]

WOW, Shaggy. I know you're a moderator, but you're starting to sound like a troll in this thread. Why would you say such a thing?

Because it's true. Show me one tool for developing against multiple, changeable, screen sizes that is nearly as good as the form designer in VB6 or VB.NET. If ease of use for a beginner was the selling point, then nobody has yet come up with such a thing for targeting the variety of mobile. It may be that MS could have done so, but the longer we go without such a thing, the more unlikely it seems. You can end up with some pretty slick frameworks, so we may be getting there, but we still aren't there.

Olaf is always talking about "it can be done in VB6." Of COURSE it can be done in VB6. It can also be done in ASM, C, and any number of other languages. The advantage for VB6 was the pure ease when starting out. If you don't care about that pure ease, then why even bother with that language when something like C was already there, and was always versatile? "You can do anything with VB6." should generally be followed with, "if you know what you are doing." But that's true in most languages. What made VB6 take off was how much you could do when you didn't know what you were doing. Since nobody has come up with such a simple means to design for the oddities of mobile, it may be that there isn't one. Would MS have found a solution had they continued developing VB6? Considering that they haven't found one otherwise, I'd say it's pretty unlikely.

VB6 does just fine differentiating between a _Click and a _DblClick event, handling each appropriately. Why couldn't VB6 have evolved to have a _Touch, _MultiTouch, _TouchResize, _TouchScroll, and whatever else we needed to deal with touch screen interfaces?

Yeah, actually, handling multi-touch is pretty trivial. It wasn't there, but adding it is no big deal to any language.

If Microsoft had kept developing the VB6 COM architecture, possibly allowing it to have "Tablet Mode" forms, possibly even adopting it to other OS platforms ... I don't see any reason that it couldn't have continued to evolve.

It WOULD have continued to evolve. But they wouldn't have kept it as easy, because they haven't been able to figure that out for any other language, and neither has anybody else. We have a bunch of experienced developers on here saying, "this is easy." Yeah, it's easy for them with years of experience. You likely wouldn't find it difficult in ANY language that had reasonable tools and reasonable documentation. But what about those starting out?

Hello World was FAR easier in VB6 than any other language at it's time. My point was that it was THAT which made VB6 take off. Hello World is not as easy in any language that works well with mobile as it was in VB6 for Windows Forms. Make THAT tool, and you'll do well. MS has shown that they can't, and VB6/COM isn't some magic bullet in that regard.

Personally, I think the biggest problem is that Microsoft sees itself as a purveyor of Windows, Office, and attempts to sell their SQL Server stuff. (Ok, they also sell some hardware.) Just look at their homepage. Developer languages are almost an afterthought.

I suspect the same sort of thing is true of Apple, Google, Oracle, and others. They want to sell their hardware and the core software (i.e., OSs and their own production software) that runs on that hardware. That's where the big bucks are

Uhhh...yeah, of course. Nobody buys into a platform for the developer tools they have. Windows was a means to make and maintain a monopoly. The Apple closed environment isn't done to make people happy. Android was a grab for share. I don't think they want to sell any one thing, they just want to keep people in the fold. For Windows, that fold used to be essentially "anything other than Macs", since the rest were minor niche players, at best. They didn't come first to market with much of anything. They took what looked like winning ideas from others and made their own version. Developers aren't an afterthought, but languages aren't about direct profit, that's why VS has had free versions for well over a decade. That's kind of the "loss leader".

[Schmidt]

Olaf is always talking about "it can be done in VB6." Of COURSE it can be done in VB6.
It can also be done in ASM, C, and any number of other languages.

That argument falls flat, when you consider what I wrote regarding the Lines of needed Code (which I mentioned for a reason).
So, a single person (out of the VB6-community or from MS) would be enough, to implement (only once):
- 50-80 lines for an Event-Binding to the Touch-Messages wich float around in the system
- 10-20 lines for an Event-Binding to the Device-Orientation-Changed (trigerring the appropriate Move-method of the Container - in turn re-triggering its Resize-Event)
- 100-150 lines for a "Table-like-Layout"-supporting container (all implemented in a UserControl-Container for example)

That's only a few days of work for a single developer.
And if properly encapsulated and compiled into a COMponent, everyone else could just "check it in" and re-use it.

VB6 is RAD because it can easily glue (existing) COMponents together (not necessarily developed by oneself).

Most of the challenges you mentioned (regarding the wide range of dynamically changing Container-Sizes)
can be addressed via such a Layout-supporting-Container-Control (where "SubControls" sit in "Cell-like" areas).

Certain Sub-Controls might have to be wrapped, to better support their "behaviour within a Layout-Cell"
(e.g. a "Labelled TextBox" comes to mind, which shows - depending on the available Cell-Space,
its Label-Description either on-top of the Input-Box, or Left/Right aligned beside it...).

But that's minor details (where the rule "once it's done, everyone can use it" still applies).

Olaf

[DllHell]

I'm not sure

we know

[dilettante]

It is tough to predict the future, but right now the "top languages" are C, Java, and Python, with JavaScript hard to ignore. Unless you are willing to stretch the point and call Python a bowdlerized Basic I think we may have to concede that Basic is mostly dead.

If somebody created something like a Python-based equivalent of Node.js and Electron and they gained even a little momentum it could be "game over" for a lot of other languages. That wouldn't kill them but it might marginalize them into niche usage.

I don't care about popularity except the extent to which it drives support.

[dreammanor]

@Shaggy Hiker,

Microsoft has completely failed in the Internet and mobile Internet fields (of course, they are now struggling to catch up on cloud computing), there are many reasons for this. But one reason is often overlooked: The Internet and the mobile Internet require small, efficient and lightweight products that are not available in .NET. And this is exactly what VB6 is good at.

IMO, the designer of .NET is excellent, but not a master, and the designers of VS6 (VC6 and VB6) are masters.

The perfect .NET platform should look like this:

The original .NET platform only contains C#, and VB.NET is the inheritance and optimization of VB6 (more efficient, lighter), and VB.NET only focuses on web-apps and mobile-apps, which is the real value of the name VB.NET.

Now the name VB.NET has become a joke (VB.NOT).

[dreammanor]

If somebody created something like a Python-based equivalent of Node.js and Electron and they gained even a little momentum it could be "game over" for a lot of other languages.

Maybe something like a Golang-based equivalent of Node.js and Electron would be better.

It is tough to predict the future, but right now the "top languages" are C, Java, and Python, with JavaScript hard to ignore.

Yes, there is no Microsoft proprietary language in the "Top Languages".

Unless you are willing to stretch the point and call Python a bowdlerized Basic I think we may have to concede that Basic is mostly dead.

Maybe VB6 is dead, but the design idea of VB6 has been inherited by others.

[lmstearn]

Just chucking this one from Appleman's revolt into the arena:

The classicVB petition recommends integrating some future VB6 into the Visual Studio IDE. I think this approach would be mistaken and a waste of resources

If it was ever undertaken, with the features of the old IDE as a bonus, then indeed it would be a legit reason for using VB6. Also a great opportunity for MS to add in mobile related functions. BASIC has, and will be a premier learning device for young coders.
Problem is, the "waste of resources", the inspiration required for the task, the oddness when offered as a installation component along with VB Net. Will it promise better compiler to IDE integration? Recommended then is a name change- not VB6 but VB Classic as was suggested in the thread.
However, there are many alternatives on the field- I have a soft spot for WPF and XAML styled code, also a useful learning tool.
As an afterthought, VB6 will be gone along with WOW emulation, but will exist in VM technology forever. Eventually, it may be offered in the Internet Archive as a freebie for our future boffins.

[wqweto]

It is tough to predict the future, but right now the "top languages" are C, Java, and Python, with JavaScript hard to ignore. Unless you are willing to stretch the point and call Python a bowdlerized Basic I think we may have to concede that Basic is mostly dead.

If somebody created something like a Python-based equivalent of Node.js and Electron and they gained even a little momentum it could be "game over" for a lot of other languages. That wouldn't kill them but it might marginalize them into niche usage.

I don't care about popularity except the extent to which it drives support.

Flutter on desktop, a real competitor to Electron -- written in Dart which as a language is used almost only in Flutter framework it seems.

And this seems to repeat closely the story of Ruby on Rails. Where was Ruby as a language before getting propelled into space by the booster rocket that Rails framework was for its success as a mainstream language.

The Compiler is *not* the problem - the VB6-like - thight IDE-Compiler-integration is the problem.

Are you hiding something up your sleeve? Some 324.5 lines of code project that replaces the command line FreeBasic compiler? :-))

cheers,
</wqw>