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

I didn't think you misunderstood me until you clarified how you did understand me, and now I'm kind of thinking both that you did misunderstand me, and it also doesn't matter.

I suppose my real point was that I don't put all that much weight on event handling. There are so many ways to implement things like that. It's a general pattern of behavior with many specific flavors. I wasn't sure what capabilities VB6 had in that regard, but it sounds like it has plenty, so that's good enough.

Now this article does a decent job of arguing why OOP is a problem...
https://medium.com/machine-words/the...g-d67078f970e2

Quote:

---

I have found that the pure approach tends to take certain relatively straightforward programming exercises and turn them into puzzles, by which I mean clever, non-obvious tricks that amuse and appeal to the kind of person who enjoys brain teasers, but which is completely inscrutable to everyone else.

As a result, I tend to use FP where I think it makes sense, and in ways that I think that an average programmer reading my code will understand. If I am tempted to do anything clever, I’ll write a long comment explaining what I have done and how it works (which satisfies my need to show off — I often think programming should be a performing art.)

So object-oriented programming isn’t what it used to be. It’s still a great tool, and worth learning. But it has been knocked off of it’s pedestal, and you hardly ever see anyone advocating it with the kind of religious fervor that you might have seen twenty-five years ago.

---

And I agree with this sentiment... OOP isn't inherently bad... just like VB6 isn't inherently bad... it's the application of OOP that's gone wrong. I've seen object models that went 10+ levels deep... and were recursive! It was insane. And this was from a professional company too! When it comes to any design pattern or any development technique, you just have to take your queue from Kenny Rodger's the Gambler and "know when to hold 'em, know when to fold 'em. Know when to walk away, and know when to run."

-tg

Quote:

---

And I agree with this sentiment... OOP isn't inherently bad... just like VB6 isn't inherently bad... it's the application of OOP that's gone wrong. I've seen object models that went 10+ levels deep... and were recursive! It was insane.

---

I'm glad to here someone else feels like this, I thought it was just me. I'd been programming for over 20 years before I started to do OOP and figure that's why I felt it was harder to follow or debug. There was just so many levels you had to dig down through sometimes. That being said, I think learning OOP made me a better programmer.

Quote:

---

Originally Posted by techgnome

. I've seen object models that went 10+ levels deep...
-tg

---

wow, never seen that before, I only do Master/Detail
but let the user create multiple instances of -new- or -edit-

+10 is insane

Levels? What levels? Are you talking about that ridiculous.java.crap.that.was.copied.by.dot.net.just.to.save.code.lines.and.turn.things.unreadable? :rolleyes:

I use it because we have our software as a small distribution to just a few clients and to recode would be putting us out of business, HOWEVER, if more clients come on board ( more $$) we will refactor to a code base that supports the new way microsoft is handling the swipe and touch events for the touch screens. Ours worked perfectly on touchscreens up till Win 10 and then it fails. A mouse click event is different than a touch event in the new OS. Various of our user controls now act up on the win10 touch platforms. Bwaaaa.

I would like to suggest that this long discussion about OOP belongs in another thread.

I don't know, it seems sort of amusing to watch both side of the argument get things so wrong.

Quote:

---

Originally Posted by Carlos Rocha

Levels? What levels? Are you talking about that ridiculous.java.crap.that.was.copied.by.dot.net.just.to.save.code.lines.and.turn.things.unreadable? :rolleyes:

---

+10 Deep

I see as ... how would I put it, something like a ...
MasterClass
-ChildClass
--- GrandChildClass
-----GreatGrandChildClass
------GreatGreat...
etc....

wrapping you head around that will take some thought

what do you mean/understand with/as Levels

Quote:

---

Originally Posted by ChrisE

+10 Deep

I see as ... how would I put it, something like a ...
MasterClass
-ChildClass
--- GrandChildClass
-----GreatGrandChildClass
------GreatGreat...
etc....

wrapping you head around that will take some thought

what do you mean/understand with/as Levels

---

Ok, that's basically how I use OO, and the "10+" levels could then make some sense, depending on the subject.
For example, it doesn't make sense to create a window with 3 buttons from scratch if you already have a window with 2 buttons. Just pick it and add another button.
This is not increasing complexity but reducing it, making things clearer and easier to follow, imo.

Quote:

---

Originally Posted by ChrisE

+10 Deep

I see as ... how would I put it, something like a ...
MasterClass
-ChildClass
--- GrandChildClass
-----GreatGrandChildClass
------GreatGreat...
etc....

wrapping you head around that will take some thought

what do you mean/understand with/as Levels

---

One of the advantages of OOP is that you avoid spaghetti code. With OOP you get lasagne code instead. :)

Attachment 164289

Regarding the 10+ level comment - it was an Infragistics component - not just one of their compoentns, but all of them. I'll use their grid though since that was the worst of it and the main component of their we were using. The problem with their object model was that if you weren't careful, you could find yourself going in circles just trying to do somethign simple like setting a color on a row or a cell. It was insane. In the end to save our sanity, we ended up (sigh) inheriting their grid, and shortcutting the properties that we were interested in 90% of the time, hiding the long drawn out object path that we had to go through, so that in the end we only had to do a simple thisGrid.SetRowColor(rowNum, ColorVal) call rather than someGrid.Views.DefaultView.Rows.findRow(rowNum).formating.SetColor(colorVal) or some crazy stunt. It was a while back. I mostly remember that the object path to do stuff tht should have been reletively simple wasn't and that we jokingly called it the Ifragistics Grid Megazord Properties. Ad there were some properties where you could go in circles because the had a property that had a type that contained Type A, which contained a property of Type B, which contained Type C, which contained Type D, which had a Type A... which sent you right back around.... and you could find yourself going A.B.C.d.A.B.C.D.A.B........endlessly...


-tg

I think I understand what you mean. That's maybe why some people dislike OO.
I see OO as a useful feature, but not like java or C# (ab)use it.

[...]

Quote:

---

Originally Posted by Carlos Rocha

I think I understand what you mean. That's maybe why some people dislike OO.
I see OO as a useful feature, but not like java or C# (ab)use it.

---

I agree, which is why I posted that artticle, because it is the first one I've come across that has been "look, OOP isn't perfect, but it isn't inherently evil either." The key I think is finding that right balance between OOP, FP, and everything else out there. There isn't one single design pattern to fit all. The problems happen when it's taken too far.

-tg

:thumb::thumb::thumb::thumb::thumb:
:thumb::thumb::thumb::thumb::thumb:

Quote:

---

Originally Posted by PriyankaB

:thumb::thumb::thumb::thumb::thumb:
:thumb::thumb::thumb::thumb::thumb:

---

Actually these thumbs ups were meant for the 1st reply on this thread by Eduardo.

Quote:

---

I guess the answer is because we are professional and career programmers and not casual programmers.
To be professional in the sense I'm saying takes many years (let's say 10 or more) with a single language.

And about the focus of you question, I suspect that here we are mainly independant developers or developers working in small companies.
The big companies, I guess mostly already migrated to some other language. For them it is just a matter of some numbers (spending some money).

But we, as developers can't "migrate" 10 or 20 years of knowdge in a couple of months. We would lose our capital that is our knoledge.
And on other hand, VB6 works just fine, there are not unsolvable problems that could force us to move to something else.

Edit: and also because we like VB6 and there is nothing similar to replace it.

---

Many VB users were spooked by the porting issues over to VBA and Net. Much code could be copied over, but not the projects.
Similar in many ways of porting a .hlp file over to .chm -it were possible, but a task complex enough one would rather build the whole thing from scratch.
Portability is the key to a true tower of Babel, but we were all turned away at the Gates of Bill!

Last year, I migrated some old VB6 projects to VS2017.
I had the old VS versions all still installed on my Win7 PC.

1) Open in VB6.
Run project to make sure everything works and is updated.

2) Open that project in VB Express 2008. (Skipped over VS2005)
Migrate VB6 project.

3) Open the VS2008 project in VS2013. (Skipped over VS2010)
This VS2013 project is compatible with VS2015 & VS2017

Yeah, that can work for some people, but not for most. That conversion tool that was found in VS2008 was discontinued for a reason. The languages are too different to be so easily migrated. The code created by the migration tool is going to be loaded with strange things. In most cases, it won't run, but for some projects it at least results in a functioning program, if not an ideal one.

If you are committed to porting to another language ecosystem (there are usually far bigger issues than just procedural code syntax) it may be a good time for a rewrite anyway.

The best way to tackle that is to first do a radical cleanup, sort of a "VB6 to VB6 conversion" to get rid of accumulated crud and inexperienced choices made in the past. At that point you should have a head full of knowledge about the requirements, making a rewrite using a different set of tools far easier.

Of course bulling ahead doing a line by line conversion isn't the answer even then. Every programming ecosystem has its own strengths and weaknesses.

Ideally you'd assign this task to someone who fully groks both VB6 and B4J, Java, C#, VB.Net, or whatever your porting target is.

Quote:

---

Originally Posted by RipVoidWinkle

Last year, I migrated some old VB6 projects to VS2017.
I had the old VS versions all still installed on my Win7 PC.

1) Open in VB6.
Run project to make sure everything works and is updated.

2) Open that project in VB Express 2008. (Skipped over VS2005)
Migrate VB6 project.

3) Open the VS2008 project in VS2013. (Skipped over VS2010)
This VS2013 project is compatible with VS2015 & VS2017

---

Do you need to add Web-Apps and Mobile-Apps to your VB6 project? If not, it doesn't seem necessary to migrate to VS2017. If so, developing Web-Apps and Mobile-Apps on VS2017 doesn't seem to be an easy task.

For a commercial company like Microsoft, when a product has no competitors, the company will significantly reduce its investment in this project. So we can't expect Microsoft to make VB6 better (open source or improve it). Everything depends on ourselves, to make it better, or to choose to leave it.

Quote:

---

Originally Posted by RipVoidWinkle

Last year, I migrated some old VB6 projects to VS2017.
I had the old VS versions all still installed on my Win7 PC.

1) Open in VB6.
Run project to make sure everything works and is updated.

2) Open that project in VB Express 2008. (Skipped over VS2005)
Migrate VB6 project.

3) Open the VS2008 project in VS2013. (Skipped over VS2010)
This VS2013 project is compatible with VS2015 & VS2017

---

Strange that you told us in post #19 that you...

Quote:

---

So, I moved to VB 2005 and had to make a few code tweaks.
Everything in VB.NET is OOP.
Once I did that, I just kept migrating to 2008 –> 2010 –> 2013 –>2015 –>2017
which was a matter of Open/Save in each new version.

---

It looks like you are just trolling.

So I won't waste anyone's time by asking how the projects you moved magically became OOP just by opening them in Visual Studio.Net.

Quote:

---

Originally Posted by RipVoidWinkle

Last year, I migrated some old VB6 projects to VS2017.
I had the old VS versions all still installed on my Win7 PC.

1) Open in VB6.
Run project to make sure everything works and is updated.

2) Open that project in VB Express 2008. (Skipped over VS2005)
Migrate VB6 project.

3) Open the VS2008 project in VS2013. (Skipped over VS2010)
This VS2013 project is compatible with VS2015 & VS2017

---

nonsense

Quote:

---

Originally Posted by RipVoidWinkle

Last year, I migrated some old VB6 projects to VS2017.
I had the old VS versions all still installed on my Win7 PC.

1) Open in VB6.
Run project to make sure everything works and is updated.

2) Open that project in VB Express 2008. (Skipped over VS2005)
Migrate VB6 project.

3) Open the VS2008 project in VS2013. (Skipped over VS2010)
This VS2013 project is compatible with VS2015 & VS2017

---

He forgot to say that these projects are all slight variations of a "Hello World" project.

Also, the primary reason I didn't initially "update" my primary project to net was because of compatibility issues. However, having recently explored recent versions of net VS, it just seems that actual development in the net VS IDE would be much more cumbersome. So, I've come to believe that the VB6 IDE is just an absolutely superior IDE, and that it's fortuitous that I didn't originally force an "update". I just routinely get 3 or 4 executions of the VB6 IDE opened, trying out some concepts in slightly different forms. This is all lightening fast in VB6. I can't even imagine doing that in a recent version of the net VS IDE.

I'm wondering what the OP (or anyone else) thinks that the illegitimate reasons for still using VB6 might be. I guess the only one that I can really think of that might fall into that category is that they hate VB.NET on principle because they want(ed) Microsoft to produce a COM-based VB7 and beyond. There are undoubtedly such people and I think that that is silly but, even then, it's a person's own choice what language they use so I still don't think that it would be fair to call that an illegitimate reason.

Before a storm of VB6 vs VB.NET hate whips up, just let me say that I'm not claiming that you can't make reasoned arguments in favour of VB6 over VB.NET; just that some people are really interested in reason on the subject and really do just hate on principle. There are also those who combine the two.

Quote:

---

Originally Posted by Elroy

However, having recently explored recent versions of net VS, it just seems that actual development in the net VS IDE would be much more cumbersome. So, I've come to believe that the VB6 IDE is just an absolutely superior IDE, and that it's fortuitous that I didn't originally force an "update". I just routinely get 3 or 4 executions of the VB6 IDE opened, trying out some concepts in slightly different forms. This is all lightening fast in VB6. I can't even imagine doing that in a recent version of the net VS IDE.

---

I can. I often have up to five different instances of VS open at a single time. The last time I went to VB6 I found it to be unusable due to the primitive nature of the IDE.

So, what are you talking about? The one thing that I can think of is that the recent versions of VS are painfully slow to start. MS tried to improve that with 2017, but didn't really get it. I tend to work with VS2010, which is instant, but that means dropping a few features. VB6 only allowed one file at a time (or was it even just one function at a time, I don't recall, though it doesn't really matter), and you couldn't collapse ANYTHING, so you were just scrolling all the time. The point of every IDE advance since then (just look at the developer tools built into every browser) has been to ease navigation. That generally means multiple files and collapsible methods. Collapsible groups, such as the Regions in VS are nice, but can be taken too far. C# allowed collapsible regions within methods, which could be used to hide ugliness rather than clarify anything, which made them loathed....so, naturally, I think MS added that feature to VB with either 2015 or 2017.

If your objection was the slow loading, I tend to agree with the more recent versions. I understand why they did that, on several levels, since the editor has taken on the characteristics of a game in that it is highly graphical. Some of those features are nice. For example, I like the ghost lines linking If to End If, cause indentation isn't always enough if the problem gets sufficiently difficult. The multiple rails in the slider also has some advantages, but not sufficient advantage, in my opinion. If it were possible to toggle off elements you don't use in order to boost launch performance, that might be nice...or not. After all, it's startup, and even on my slower work computer it only takes a few seconds. I think MS has gone a bit overboard with trying to stuff more and more productivity features into the IDE to the point where nobody can use more than a portion of them, but on the other hand, I'm working on a program that is entirely graphical, so I can see why it can slow down launch times.

Quote:

---

Originally Posted by Shaggy Hiker

The one thing that I can think of is that the recent versions of VS are painfully slow to start.

---

That's precisely what I'm talking about. Jumping in and out of the VS IDE is so painful that you (or at least I) forget what I was trying to do. Whereas the VB6 IDE starts almost instantly.

I've always been baffled by that claim. We are SO used to so many programs taking seconds to load. I don't know of a game that loads instantly...well, I guess I do, since things like solitaire can load instantly, but most things aren't that fast. SQL Server Management Studio is even slower, Access isn't all that fast, Excel isn't all that fast. So, why is it so essential that VB6 load instantly? It feels like grasping for benefits of what is clearly an ancient IDE.

It certainly shouldn't apply to switching between multiple instances of the IDE, anyways. The cost is in loading, not in switching, and if you have enough RAM, switching should be instantaneous. Also, if you have enough RAM, loading the second instance will be FAR faster than loading the first. And, even with that, the loading time is a few seconds. Even on my (slower) work computer, VS2017 is probably less than 10 seconds (unless our intrusive security scan has decided to take over the computer, in which case EVERYTHING is slow). Even if that happened every time, do you really open and close the IDE over and over and over? I tend to open one or more and leave them open for hours. Spending 10 seconds once a day isn't even enough time to go get a mug of water.

It just feels like you're saying, "well, we don't have this, we don't have that....but we load FAST!! Great, THAT's what we'll talk about!" Who the heck cares these days?

Yeah if it takes so long to start you just leave it running all day. Nothing new:

https://www.youtube.com/watch?v=ws-Kp2aLcEc

i found this web https://vb6x.org/

How to upgrade Visual Basic 6
to Visual Basic 6.5
with VBA's SDK

https://youtube.com/embed/UPpOZszug1...info=0&start=0

Quote:

---

Originally Posted by xxdoc123

i found this web https://vb6x.org/

How to upgrade Visual Basic 6
to Visual Basic 6.5
with VBA's SDK

https://youtube.com/embed/UPpOZszug1...info=0&start=0

---

Can you help me understand the benefit of this?

Quote:

---

Originally Posted by axisdj

Can you help me understand the benefit of this?

---

Can use some of the features of vba。

https://github.com/VBForumsCommunity/VB65

Quote:

---

Originally Posted by Elroy

So, I've come to believe that the VB6 IDE is just an absolutely superior IDE.

---

VS IDE is a massively complex beast, and I luv it. Comparing the two is a more like daisy to a sunflower- (than steam car to BMW 5? :D )
Albeit one big thing: SDI & MDI. VS doesn't do it. Will they ever? I found SDI indispensable when on many an occasion one could poke the mouse through to an explorer folder or desktop to check files or such. Much better than <alt tab>.
VS runs better if the performance monitoring stuff is switched off. It can also run slow if GPU acceleration is enabled. The older the card and the bigger the driver, the worse it gets. :eek:

[...]

Quote:

---

Originally Posted by dz32

I havent used VS for .NET in quite a while but it always killed me how long debug sessions took to start up. Thats something you have to do 1000x a day.

---

Something must have been wrong with your installation, then. I've used VB5, VB6, 2003...and every single version since then (though not much of 2012 or 2013), and I've never seen debug sessions take ANY time to start in any version. That item has been the same pace (instant) no matter what other changes were made.

I have seen a bad installation do something slow, though I'm not sure it was a bad VS installation, or had more to do with a certain 3rd party set of controls. It didn't have anything to do with debug, it could just take a minute or two (literally) to switch to the form designer the first time. The reason was due to loading some set of controls, which is why I suspect the 3rd party controls....except that I have those controls added on a different computer that doesn't show that slowdown. It also doesn't seem to happen all the time, which suggests it's a VS issue.

Shaggy,

VB6 is a true software tool for me. I just timed it, and it takes exactly 2 seconds for it to open on my machine. I do have the Windows calculator on my toolbar, but I'll often pop-open VB6 just to use the Immediate window as an equation solver, possibly while on the phone with someone and we're working through some simple math.

Also, I'll often pop open VB6 just to check some concept. For instance, I was just interested in how the "__vbaRefVarAry" call works that Dex posted. I popped the IDE open, and, within a few seconds, I had my understanding.

I truly just make quick use of it all the time, similar to the way I use NP++ or Chrome. I also use Word, Excel, and Access quite a bit. Access still opens quite fast (even faster than VB6). However, I must admit that it's annoying to me how slowly Word and Excel open. But none of them is as slow as recent versions of Visual Studio. It's just truly painful to get that thing open, and I'd never consider using it as a quick-tool.

Best Regards,
Elroy

Quote:

---

Originally Posted by Elroy

I just timed it, and it takes exactly 2 seconds for it to open on my machine.

---

I just timed VS 2017 and it took 3-4 seconds to open on my machine. The Start page takes some time to load and that happens in the default configuration but you can change that in the Options dialogue. Maybe my question about what would be an illegitimate reason has been answered: a perceived issue with the .NET VS IDE that isn't actually an issue.

Quote:

---

Originally Posted by jmcilhinney

I just timed VS 2017 and it took 3-4 seconds to open on my machine. The Start page takes some time to load and that happens in the default configuration but you can change that in the Options dialogue. Maybe my question about what would be an illegitimate reason has been answered: a perceived issue with the .NET VS IDE that isn't actually an issue.

---

how would one create a ActiveX exe in .Net ?

I use in VB6 a ActiveX Exe for Database..
a) track Users Logged on
b) send Message to single or all User(s)
c) Log Out User(s)
d) Track User(s) Transaction(s) in the DataBase Add,Edit,Delete

I don't have the knowledge if it's possible to do that in .Net ?