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 ?

Quote:

---

Originally Posted by jmcilhinney

a perceived issue with the .NET VS IDE that isn't actually an issue.

---

I've seen it take over a minute to start on my computer. But this may not be Microsoft's fault as there are lots of things outside their control that can cause (realtime antivir file scanning seems to be a common cause)

Quote:

---

Originally Posted by ChrisE

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 ?

---

I wouldn't expect that it is possible. ActiveX was a 90s technology that MS walked away from back then.

Quote:

---

Originally Posted by Shaggy Hiker

ActiveX was a 90s technology that MS walked away from back then.

---

Sorry, but that isn't true. At all.

We are still getting new ActiveX libraries as part of Windows 10. Stuff like WMI and Explorer haven't disappeared, nor has MS Office yet.

.Net is the foreigner in Windows. Sadly we're all paying the .Net tax now since the bag o' crap comes preinstalled. This opens a completely unnecessary attack surface and makes Patch Tuesday a far larger burden than it needs to be.

https://stackoverflow.com/questions/...com-exe-in-net

Quote:

---

Originally Posted by dilettante

.Net is the foreigner in Windows.

---

Well, you could say the same about Java and it seems to be rather popular. Java updates are more prone to breaking things than .NET updates in my experience.

Quote:

---

Originally Posted by ChrisE

how would one create a ActiveX exe in .Net ?

---

Not sure as I've never had the need to.

Quote:

---

Originally Posted by ChrisE

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 ?

---

Perhaps then it's time to do a little research and look. Because, yes, it's possible to do all that.

-tg

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.

---

Code:

---

Two friends were talking about their own success.
- I have a farm that takes me one full day to cross by car.
- I already had a car like that...

---

What I can say about your post is that I don't want your VS, I want your PC :p

Quote:

---

Originally Posted by Carlos Rocha

Code:

---

Two friends were talking about their own success.
- I have a farm that takes me one full day to cross by car.
- I already had a car like that...

---

What I can say about your post is that I don't want your VS, I want your PC :p

---

I was thinking about that, too. My work PC is...nothing special. That's not slagging the company, it is just a coincidence of timing, and will be resolved in time, but it's the fact. I also do a fair amount of development on a virtual server. Not sure what the performance should be for that. It doesn't really matter, since there's a lag in working over the wire, and that makes startup times irrelevant. That lag exists in every application run on that server, so you just learn to type a bit slower. As a comparison, that's not a fair comparison.

However, my home system is pretty doggone good, as it's a recently built gaming system with some pretty good hardware built around an SSD. Startup times on that are pretty awesome.

Which brings up one point: Whatever is currently slow might not be slow in a couple years. Some people complain about the size of programs, but not so much now that you can get a terabyte HD for a few hundred dollars. We used to worry about arrays that exceeded one memory frame. Now....we just don't. Could we write code as compact as that? Yeah, sure, but nobody bothers because we just don't care about 64K limits (or 4K limits, if you wrote for TRS-80 Level 1s).

So, when we compare speeds, it's also kind of important to compare hardware capabilities. Still, I'd say the biggest single slowdown with launching versions of an IDE have to do with....details, whether third party add-ins, features, or bad installations.

I guess I could sum up this post with one word: Whatever.

VB 6.0 loads in probably 1/3 of a second for me - with AV installed and configured for maximum scan aggression.
VS.NET loads in about 1 second, but I'm using an old version of VS.NET that probably has less bloat than more recent versions.

No fancy new hardware, just some old Dell boxes that my last employer sold once they were taken out of production.

I keep my development devices as bare bones as possible as far as what other programs get installed, I find that is a huge factor in overall performance. Limit services that are running to just the essentials, pare down what runs at Startup via MSConfig to only what is necessary.

Quote:

---

Originally Posted by Grant Swinger

https://stackoverflow.com/questions/...com-exe-in-net

---

This link is a good proof of the advantages of .NET, which is that things that are easy to do in VB6 require very complex steps in .NET.
It also proves the advantage of OOP, that is, the operation that can be achieved in one step, which needs to be turned 9 turns in OOP.

Quote:

---

https://stackoverflow.com/questions/...com-exe-in-net
Enterprise services will allow you to do just that. You can run a COM component as:

A DLLHost process
A service
An inproc library (this is in the same process as your other code)
There are numerous examples on the internet about these. What it comes down to is:

Decorate your classes that you need to expose to COM with Interfaces
Components that you want to host need to be derrived from ServicedComponent
Decorate your interfaces with a GuidAttribute (use a unique Guid)
Decorate the interfaces and classes that are exposed to COM with a ComVisible(true) attribute
Hope this helps.

---

Quote:

---

Originally Posted by Shaggy Hiker

I was thinking about that, too. My work PC is...nothing special. That's not slagging the company, it is just a coincidence of timing, and will be resolved in time, but it's the fact. I also do a fair amount of development on a virtual server. Not sure what the performance should be for that. It doesn't really matter, since there's a lag in working over the wire, and that makes startup times irrelevant. That lag exists in every application run on that server, so you just learn to type a bit slower. As a comparison, that's not a fair comparison.

However, my home system is pretty doggone good, as it's a recently built gaming system with some pretty good hardware built around an SSD. Startup times on that are pretty awesome.

Which brings up one point: Whatever is currently slow might not be slow in a couple years. Some people complain about the size of programs, but not so much now that you can get a terabyte HD for a few hundred dollars. We used to worry about arrays that exceeded one memory frame. Now....we just don't. Could we write code as compact as that? Yeah, sure, but nobody bothers because we just don't care about 64K limits (or 4K limits, if you wrote for TRS-80 Level 1s).

So, when we compare speeds, it's also kind of important to compare hardware capabilities. Still, I'd say the biggest single slowdown with launching versions of an IDE have to do with....details, whether third party add-ins, features, or bad installations.

I guess I could sum up this post with one word: Whatever.

---

Microsoft used to be the dominant giant. When Microsoft was closed and conservative, competitors (such as Google) then defeated it through open source and openness. When Microsoft's products are getting bigger and more inefficient, competitors will beat it with smaller, more efficient products.

Quote:

---

Originally Posted by dreammanor

This link is a good proof of the advantages of .NET, which is that things that are easy to do in VB6 require very complex steps in .NET.
It also proves the advantage of OOP, that is, the operation that can be achieved in one step, which needs to be turned 9 turns in OOP.

---

I'm afraid that this doesn't really work. While it is true that there are some things that are easy to do in VB6 that require complex steps in .NET, the reverse is also true. Creating a COM component in VB.NET isn't a great example to use for the superiority of VB6 because, in my experience, the most common reason for having to create a COM component in .NET is so that it can be used in VB6 code. In my decade and a half of .NET development, I've not once had to create a COM-visible assembly so the fact that doing so is laborious has exactly zero effect on me.

Quote:

---

Originally Posted by jmcilhinney

I'm afraid that this doesn't really work. While it is true that there are some things that are easy to do in VB6 that require complex steps in .NET, the reverse is also true. Creating a COM component in VB.NET isn't a great example to use for the superiority of VB6 because, in my experience, the most common reason for having to create a COM component in .NET is so that it can be used in VB6 code. In my decade and a half of .NET development, I've not once had to create a COM-visible assembly so the fact that doing so is laborious has exactly zero effect on me.

---

Maybe you can list some of the opposite examples to compare the features of VB6 and .NET. For example, things that are easy to do in .NET require very complex steps in VB6.

It feels like we're getting to that VB6/.NET homeostasis point where nothing gets resolved, and since I don't have much faith in the .Netters to demonstrate much of anything of substance, I'll play the role of the devils' advocate here and ask a scary question of my own:

Hardcore VB6ers- would you still recommend VB6 as a viable language for NEW software development? Please explain.

Quote:

---

Originally Posted by dreammanor

Maybe you can list some of the opposite examples to compare the features of VB6 and .NET. For example, things that are easy to do in .NET require very complex steps in VB6.

---

I've never actually used VB6 in anger myself. I tried it once, many years ago, and didn't like it at the time. That's not necessarily a reflection on the language - there are undoubtedly many things that I don't like that aren't inherently bad - but I found that it didn't suit me, while I took to VB.NET immediately and with fervour. As a result, I have to rely on what those who have used VB6 say on matters like this and I have seen many developers who have migrated from VB6 to VB.NET say that they find doing various things easier in VB.NET. Maybe that's just because they didn't know the best way to do them in VB6, at least in some cases, but I suspect that that also applies to at least some complaints about VB.NET from long-time VB6 developers.

With that in mind, one of the most common topics I've seen those who have migrated use as an example is multi-threading. I don't know how multi-threading is implemented in VB6 but I don't think that it was ever a focus for those who developed the language and I don't think I've ever heard a developer speak of the options available in a favourable manner. .NET has numerous options for implementing multi-threading and parallelism, with some of the newer options being built on top of the older ones. Just recently, I created a Wait/Progress dialogue for Windows Forms that can be used in any application can be displayed modally over any form to allow work to be done in the background. It took me a few minutes to whip up and it can be used simply by showing a form and handling an event or two. I'm not sure how that would be done in VB6 but my impression is that it would not be quite so straightforward.

Obviously multi-threading is not the be all and end all of Windows GUI programming but, in this day and age, I'd suggest that it's probably more common and more useful than creating COM components for the majority of people.

Quote:

---

Originally Posted by jpbro

It feels like we're getting to that VB6/.NET homeostasis point where nothing gets resolved, and since I don't have much faith in the .Netters to demonstrate much of anything of substance, I'll play the role of the devils' advocate here and ask a scary question of my own:

Hardcore VB6ers- would you still recommend VB6 as a viable language for NEW software development? Please explain.

---

I reckon that this is a rather pertinent post. I'd say that a significant reason that nothing ever gets resolved is that there isn't really anything to resolve. Whether VB6 or VB.NET is better is largely a matter of opinion. VB6 can still do all the things it did so if you just want to do those and you like doing them in the way VB6 does them then there doesn't have to be any motivation to change. VB.NET and .NET in general is enjoyable to many and if you enjoy what and how .NET does them, why should you stick to VB6? I think that both groups resent the other, at least in part, because of their actual or perceived effect on themselves. By that I mean that VB6 developers are pissed off that they didn't get the VB7 and beyond that they wanted and think that Microsoft had a responsibility to provide and VB.NET developers as a group are in the way of them getting that. Likewise, VB.NET developers see VB6 developers as hindering the growth and development of VB.NET. Both might be right: if VB.NET had completely flopped then Microsoft might have continued development of COM-based VB and stuck to C# only for .NET and if VB6 developers had migrated to VB.NET en masse then VB may have got a bit more love as a member of the .NET community.

Personally, I didn't like VB6 when I tried it but I have no issue with someone who uses it and does like it sticking with it. I do have an issue with VB6 developers trying to push it on new developers though. I think that it's done out of spite and for validation in many cases. Spite because it means that Microsoft don't get another VB.NET developer and validation because more people using VB6 means that their decision to use it is more justified. Espousing the good points of VB6 is one thing but doing so without pointing out the fact that Microsoft haven't made any improvements to VB6 in decades, never will and would prefer the language to die off is not really being fair to someone who is just starting out in development and doesn't know what will benefit them long-term.

Before anyone gets too upset, I know I'm making generalisations here and no generalisation is ever going to apply to an entire group. It may well not even apply to a majority. Many (most?) groups have a vocal minority so when we say "this group says this" we're generally referring to that vocal minority and possibly not even all of them. I would imagine that the majority of VB6 developers haven't had an argument on the subject in a long time and just get on and write their code, as do the majority of VB.NET developers.

i would never recommend vb6 to anyone that want to make a career.
neither would i recommend to a friend that want to be serious with programming.
but i could recommend to a friend if he wish to make some stuff for personal use, as i can also be of assistance.

if u already know vb6, i would recommend to keep using it if you are fine with windows.

Quote:

---

Originally Posted by jpbro

Hardcore VB6ers- would you still recommend VB6 as a viable language for NEW software development? Please explain.

---

No, but I'll use VB6 to make some personal or internal development tools, just like I'm doing now.

Microsoft abandoned VB6, but .NET did not benefit from it. More and more people are turning away from .NET to other non-Microsoft development tools.

Quote:

---

Originally Posted by jpbro

It feels like we're getting to that VB6/.NET homeostasis point where nothing gets resolved, and since I don't have much faith in the .Netters to demonstrate much of anything of substance, I'll play the role of the devils' advocate here and ask a scary question of my own:

Hardcore VB6ers- would you still recommend VB6 as a viable language for NEW software development? Please explain.

---

well thank God I will only be working for a few more years, so once retired I will be writing stuff for Wildlife statistics
Writing NEW Software is an Investment for Years, so I don't think vb6 should be the language to choose
if all stays the way it is now.

the one thing that M$ didn't take into account, is that VB6 is(would be) still popular... in Year 2019 !

Quote:

---

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

---

All this talk that the VB6 IDE is somehow superior to the VS .Net one is just partisan nonsense.

Firstly I started out as a VB6 developer so i know the language and i know the IDE and over the years as my career took me from place to place i learned new stuff ( not just Microsoft as i worked with ColdFusion & Flex for while and also PHP) now i primarily work with C# .Net although i still support a couple of VB.Net project.

Strictly talking about the IDE and not the languages the current VS versions (which incidentally take about 5 - 6 seconds to open for me on a reasonable but far from top of the line laptop) it;

-allows you to open multiple code windows, and even position them side by side if you want
-has far superior intellisense
-has a much better way of dealing with references
-has nuGet for adding 3rd party controls/dlls which if you have never used is like light years ahead of the VB6 way of doing this
-allows you to create a folder structure in the IDE to put you various classes / forms in etc which makes it a hell of a lot easier to find stuff in larger projects
-has superior source control integration
-alerts you to errors in your code in a far far nicer way and give you an interface to deal with them

and that is just for starters straight off the top of my head

There are a bunch of other features that are not even comparable as you just cant do them in the VB6 IDE such as Mobile development which i haven't even focused on



There is just no comparison between the IDE's at all, i cant think of 1 single feature in the VB6 IDE that i prefer !