Page 1 of 4 1234 LastLast
Results 1 to 40 of 150

Thread: THE .net and vb6 holy war

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    481

    THE .net and vb6 holy war

    Hello There,

    Since I have joined I have noticed that there is a sort of holy war between .net and vb6 developers. I could not sleep last night thinking about this and trying to figure out why this would be.

    VB6 developers think differently that .NET programmers from my observation, so does that make one right and one wrong?

    To sum it up in my opinion,

    .NET programmers think that vb6 developers are generally messy/lazy code writers and are missing the power of true OOP

    VB6 programmers think that .NET is bloated and slow

    Could it be that both sides are right. Who is to say that if a VB6 program works well, and sells, that the VB6 app is worse than the same app written in .NET, or the other way around.

    My point is, why are so many .NET folks so against bringing back support for vb6? Maybe vb6 fits the needs of small companies who just want to get an app out and working, and .NET works for larger companies with a more corporate environment/mindset.

    If a vb6 works well, or a .net program works well, why is one better or worse than the other?

    I think the argument is like the holy war in the middle east, both sides are so passionate about their perspective on reality there is no solution, but are we not better and more intelligent to overcome this?

    I know this is a technical discussion, but its on the topic of the latest movement to revive support for vb6:
    http://visualstudio.uservoice.com/fo...improved-versi

    Thanks!

  2. #2
    I'm about to be a PowerPoster! Hack's Avatar
    Join Date
    Aug 2001
    Location
    Searching for mendhak
    Posts
    58,333

    Re: THE .net and vb6 holy war

    Moved To Chit Chat

  3. #3
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: THE .net and vb6 holy war

    You can find a few threads on this subject in General Developer.

    I don't see this as the holy war in programming. I'd say the holy war is between C# and VB (at least in the .NET world), or between Android and Windows solutions for a different point of view.

    I think that the major objection between VB6 and VB.NET is that the objectsion VB6 people have are pretty much wrong. I've written the same app in VB6 and VB.NET. If there was a differnece in performance for that VERY CPU-intensive app I couldn't see it. The calculation ran for a few days in both cases. No two runs were identical in length, so if one run took an hour more or less than another, it could be the language or it could be the details of that run. I wasn't trying to compare the two, either, nor were they true comparisons, since the .NET version was VASTLY improved over the VB6 version. However, the iterations for each version were about the same, and those ran in roughly the same time, with no clear benefit either way.

    It's hard to argue that the framework that ships with .NET isn't MUCH bigger than the framework that ships with VB6, but the real difference isn't so much. After all, what worked the best for VB6 was when the framework was included in the OS. Such has been the case with the .NET framework for years now, so that argument is pretty much dead in practical terms.

    As for which one is easier to write in, it is clearly .NET. You can do more with less code in most areas, and the IDE is VASTLY superior. Of course, the IDE for VB6 would be equally superior if VB6 had continued, because the IDE is just Visual Studio. Each new version adds some features, so .NET gets those features and so would VB6...except that it was abandoned over a decade back.

    Frankly, having worked for years in VB6 (and earlier), and years in .NET, I use .NET because I prefer it. I loved VB6, but .NET is better. In most cases, the people who stick with VB6 seem to do so more because they want to believe it is better rather than for any sound reason. After all, they can't come up with any valid reason why it is better. All we ever hear is the same old, innaccurate complaints about .NET being bloated and slow. It just comes across as whining. The disinformation is annoying enough to prompt a response. If that's a holy war it's kind of like creationism vs evolution: All the facts are on one side, while the emotion is evenly split.

    In any case, the bottom line is this: VB6 is dead. It would be a horrible business decision for MS to resurrect VB6 as it was. If it was improved to add the features that .NET has and VB6 lacked, such that VB6 was modernized, it would no longer be VB6. And finally, it would be downright suicidal for MS to release VB6 as open source. So, VB6 is dead. You can keep on using it as long as it works. When it stops working, you can move on or you can pout about it. But VB6 is dead.

    There may well be another language that will come along to fill the niche that early VB was intended to fill. Something vastly simpler. I doubt it, but it might happen. It won't be VB6, though.
    My usual boring signature: Nothing

  4. #4
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: THE .net and vb6 holy war

    VB.Net is the natural successor to VB6. It makes no sense to me why people talk about reviving it when it has evolved already. If VB6 is so great, just stick with it.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  5. #5
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: THE .net and vb6 holy war

    That's true. Sticking with VB6 is kind of like nostalgia, except that nostalgia these days just ain't like it used to be.

    If MS were to revive VB6, would they keep it frozen as it was in 98, or would it have new features added? For example, it didn't really do multithreading. You often don't need that in any language, but would you add it to VB6? The same can be said for LINQ and lambdas. You don't have to use them in .NET, so why not add them as an option to a new VB6? Another big question would be DB access. VB6 had DAO, RDO, and ADO. The first two were deprecated, but were still in use. ADO wasn't as good as ADO.NET, so would you create a new ADO that added the advantages of ADO.NET?

    Is the point to make a VB version that is frozen in time and never has any new features? If you don't do that, then the new VB6 wouldn't look any more like the old VB6 than .NET does. On the other hand, if you do make a VB version frozen in time....why?
    My usual boring signature: Nothing

  6. #6
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: THE .net and vb6 holy war

    Quote Originally Posted by Shaggy Hiker View Post
    If MS were to revive VB6, would they keep it frozen as it was in 98, or would it have new features added? For example, it didn't really do multithreading.
    Actually they couldn't. What the VB6 compiler really does is create COM clients. It can create servers too as in the case of ActiveX Dlls and Exes. VB6 is limited by how COM is built. COM uses funky apartment models for its threading. Makes it easy for developers to use multithreaded classes but severely limits what the developers of such classes can do. COM I believe is the reason MS started on the .Net Framework for its next iteration of VB. You see, COM goes well beyond VB6. Its an integral part of the OS. If they wanted to add all those nice features we have in VB.Net to a COM based VB they will have to break COM itself which would have far reaching consequences for Windows itself. Now the .Net Framework wasn't initially as strongly integrated into the normal functioning of Windows so they could have put whatever features they wanted without breaking the OS and as Windows continues to evolve, they would integrate .Net more into it. As a matter of fact .Net would probably replace COM eventually, perhaps by Windows 15 or something. They corrected all the mistakes they made with COM when they built .Net.

    Point is there was really only one way this could have gone. .Net has a future. COM has already passed its time and since COM and VB6 are intricately linked, VB6 had to go as well. Don't take anything I've stated here as fact though. Its just the way it seems to me.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  7. #7
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: THE .net and vb6 holy war

    I wasn't planning on getting involved in this thread (I'd only been visiting out of morbid curiosity)... except that Niya hit a couple of points (whether he knew it or not). About 11 years ago, before even VS2002 came out, and .NET was a new infant on the block... I attended a conference where one of the main topics was ADO ... it was in the early days, they weren't even calling it ADO.NET ... that would come later. Annnnny ways.... there was a panel to discuss some of the changes from VB6 to .NET... it was eye opening and informative. Among the main things I learned in that panel session were:
    1) Creating User Controls was going to be drastically different - this stuck out because our entire system was built around custom user controls
    2) Wait? I have true inheritance now?
    3) (what would become ADO.NET) is light years ahead of ADO classic and will be a lot of fun to work with.
    4) Wait, you mean to tell me I can inherit anything?
    5) The VB6 conversion tool included in VB.NET was only done to appease those who had come to expect it, but it was still going to screw up most of your code.
    6) Wait, so all I need to do is Inherit XYZ and it's done?
    7) There had been an attempt at trying to get COM to work in .NET natively. A lot of work. You think the FW is bloated now? It would have been far worse had it included the needed bits to allow COM to run in-process natively with .NET. This actually held up the release of .NET for a while. Eventually it was decided that a break was going to be needed. They didn't really want to and they knew there would be some alienation as a result, but it was a risk. Or scrap .NET all together and start over and wait another ... who know how long.
    8) Inheritance? Sweeeeeet!
    9) Did I mention that I was stoked about inheritance?

    Item #7 there is the key to all of this brouhaha. Yes, there was a clear intent in breaking compatibility, but it wasn't done to just mess with VB6ers, or on a whim... it was done after a lot of careful and deliberate research into maintaining compatibility. In the end, it just wasn't technologically feasible.

    So when .NET came out, you had your choice... stay with VB6 or move on. I moved on. I think I'm the better for it. For those that haven't moved on, it's been 10 years, so there's almost (almost...) no excuse to not have converted by now. I've seen the argument about creating apps faster in VB6... hmmmm... I half believe it. Early on, sure, I could whip out a VB6 app faster. But that's only because I was familiar with it. I've been doing .NET development exclusively now for 6 years... I can now whip out an app faster in .NET than VB6. It's all about familiarity. Honestly, if people want to stick with VB6, that's fine, let them. But I think you're missing out on some truly wonderful stuff. And even if MS suddenly decided that, OK sure, we'll keep VB6 uptodate... what would you add to it? What does it not do now that you wish it did that causes you to want it's life to be extended?

    Think about it for a moment. I mean REALLY think about it.

    I'll wait.




    And there lies the problem. I can almost guarantee that at least three people thought about it... and NONE of them share a common vision. Maybe one item between two, and another item between another, but the three of them aren't going to come up with a single common list. Everyone's out for themselves. Everyone is thinking about what THEY need, not what would benefit the language over all.

    I've heard, make integers 64-bit... 1) that's a biiiig jump 2) even .NET integers are still 32-bit, so I don't see that happening soon ... OK, so let's just go for simple language parity... and go with the lowly Integer. Alakzim, alakazoo! OK, so now Integers in VB6 are 32-bit... what just happened to Longs? I guess they became 64-bit... then there's all those APIs... counters... calls to the database... how many of us current and former VB6 developers used longs because they were 32-bit and could store a bigger number than Integer? You just now broke each and every one of those instances. So now *I* have to go through my code and change all of that, re-test everything and re-deploy. I might as well move to .NET at that point.

    Some times languages are like girlfriends, and there are times when circumstances dictate that you just have to break off the relationship and end it.

    Now, where I do get offended is when someone tries to berrate me or call me foolish for moving on. I realize some (and some of them are on this forum and quite vocal about their opinions) feel like the've been thrown under the bus, some have their reasons. Some valid, even I'll admit that. But a great deal of the "backlash" is the same self-centered selfish rhetoric that they've been spouting for the last 10 years. Rather than finding a new pub, they're content to sit at the counter, crying in their beer lamenting about the good-old days, and doing everything they can to bring the rest of us down, to include making baiting comments that just end up in some of the nastiest threads I've seen around here.

    No, there is no holy war. It's just politics. On the left, you've got the extreme .NETters who want all things pure .NET and only .NET. And on the right you have the conservative VB6ers that wish for the better times when VB6 ruled and wonder why did things have to change? And then there's 75% of us firmly in the middle, going what the heck? If it works, it works... but at the same time, know that there will come a time when VB6 runtime will no longer be included, and won't even be able to run. At the moment, as long as the VB6 runtime can still be run, I'm sure they'll include it as part of the OS... why wouldn't they? It doesn't cost them to add it. But there will be a point where there will be a fundamental change in the OS, either driven by a software technology or a change in hardware, that will render VB6 useless.What then?

    -tg


    Hmmm... for someone that wasn't planning on getting into this thread, I kind got verbose there didn't I? What can I say? I'm a VB developer, we're verbose by nature.
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  8. #8

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    481

    Re: THE .net and vb6 holy war

    I do not think any of you who defend .net are wrong, I think it is the perfect tool for you. I respect you and your talents!

    All I want is a like vb6 ide/compiler I can move to, to future proof my companies software ( how I make a living ). I think www.xerocoder.com of xojo.com might be it.

    I really don't know why its so hard for me to move to .net.... I am not lazy, I am a risk taker, I have a high IQ, I am open to change. From what is posted above I am just a lazy, unintelligent, should not be a developer.... Ok, maybe all are right. But here is the reasons I have not upgraded to .net, I humbly ask for help.

    Taken from the visual studio user voice vote to bring back VB6 ( I Posted this)
    @Reed Kimble,

    You state that

    "It was never intended for modern hardware (no one envisioned today's architecture when building VB6, or rather, no one expected it to survive into today's architecture). If you ever had to deal with user questions about "how do I do this or that complicated thing in VB" you would quickly understand why .Net is so preferable. The VB6 answer would be huge and messy and prone to all kinds of mistakes. The .Net answer would be much less code and much more stable."

    Can you please give me an example. I have to applications written in vb6 that control intelligent lighting and radio automation, and I have never been asked to do something that cannot be done in vb6. If that was the case and .net really allowed me to do something vb6 cannot, I would have switched in 2001. Please help me understand what .net can do, that vb6 can in reference to the end user experience ( not counting theoretical design concepts ).

    you state
    "There really is a "right" and "wrong" here for those who are willing to openly look at both sides."

    I am not sure that helps. Let me give you the top 6 reasons I have not switched

    1. Why do a re-write to get to the same exact place, if I rewrite my application why not move to a cross platform solution to expand my market reach

    2. If I can do ANYTHING in vb6, I can in .NET why would I move?

    3. I am doing a lot of direct hardware communication, why would I want an extra layer of abstraction (.NET Framework) to slow things down?

    4. Why do I need all this extra complexity in my code (creating and object just to pass it to another object?) extra work with little benefit. I don't want to send the whole box of chocolates, just one piece.

    5. I have to obfuscate my code to protect it from design secrets ( recently looked at one of my competitors code and how they did things... his solution was written in .NET)

    6. Now that MS is steering back to COM development because of efficiency, why would I put my trust in VB.Net when it may see the same fate as vb6.

    Please understand I am not wanting to argue, I would just like to understand your opinion on the points above so I can learn the right way. I don't know if I am right and I am willing to change if I can justify the effort.


    oh and lastly.. about your question: Think about it for a moment. I mean REALLY think about it.

    All I want is for MS to continue support for vb6, until I can find a proper replacement.

  9. #9
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: THE .net and vb6 holy war

    Now that MS is steering back to COM development because of efficiency, why would I put my trust in VB.Net when it may see the same fate as vb6.
    Now, that's the comment that chaps my hide the most... because to be quite honest, that could be said for just about any language... seriously. I've seen a number of VB6 descendants come and go around here... each one was touted as the way... and then six months later the main developer stops working on it, and then it just withers and dies. Will .NET stick around? Probably not. It will probably go the way of the dodo at some point as well. And when that time comes, I'll adjust if I need to. If it means COM makes a comeback, great, then I'm all set since I already have that skill set. But that doesn't mean VB6 will come back. COM is a technology, VB was a tool... just because the technology may make a comeback doesn't mean the tool will. Maybe they'll have figured out how to get COM working with .NET...

    What if Apple one day decided that Objective C wasn't what they want to use any more either, and they go to a different language?
    All languages are at risk of suddenly being dropped. So we take a chance that it will stick around for a while, long enough to make it worth the effort. So far .NET it working out for me. And given that it's lifespan has already exceeded that of VB6... I'm going to go ahead and go out on a limb and bet that it's going to keep sticking around for a while yet. Don't dropping .NET would not only impact VB, but it would take out an entire army of C# developers too... And believe me... you think VB developers are zealous? C developers have it defined in their header files.

    1 - cross platform... VB6 isn't going to get you that either... almost no language will. You can get to some platforms with a language, but there isn't a one-size fits all language. But again, this falls into the selfish reasons people want VB6... not everyone needs cross platform. I don't. Never have. Will I? Meh... maybe... when the time comes, I'll adjust.
    2 - Correction, if you can do everything YOU need in VB6, why change? That runs counter to your point 1 though... since clearly VB6 CAN'T do MacOS. So this argument is almost invalid. As a point of order, there are somethings you can do, or at least do better in .NET than you can in VB6. Inheritance is one of those things. That one thing alone was worth my time to move on. I saw the potential of it in what I was doing at the time.
    3 - Fair enough point... but you don't HAVE to go through the framework... if the hardware has an API... go straight there...
    4 - So send the one piece! When I need a datatable, I create a datatable... I don't create an entire dataset, just for one table... that's crazy. If I want to send an integer, then I send an integer. I'm not sure where your comment came from, but it sounds like something got torched when it should have been a simple flambe.
    5 - Even obfuscation doesn't completely protect. Nothing will. All you can do is throw up walls and make it as difficult as you can for someone to figure out, but you can't stop the most determined leeches. This is in fact some thing I do agree with as being a negative with .NET.
    6 - I think I addressed this in my opening statement.

    Bottom line, I know I'm not going to convince you that you should dump VB6... if it works for you, that's great, I'm happy for you and by all means keep using. To me, it just had too many limitations. At the same time, I doubt there is much of anything that you can say to convince me to sign any kind of petition to bring back VB6 from the dead. It's already been in the "no longer adding to it" state than its original life span was - which was officially 96-02, when they stopped adding to it, service packs were still released until 06 I think it was... and all support of any kind ended in '10 (doesn't sound right, but feels right)

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  10. #10
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: THE .net and vb6 holy war

    oh and lastly.. about your question: Think about it for a moment. I mean REALLY think about it.

    All I want is for MS to continue support for vb6, until I can find a proper replacement.
    And by "Support" what do you mean? And again, you just proved my point that a majority of the "bring back VB6" that's out there is self-centered and selfish...

    So what do you mean by "support" ... VB6 apps still run on Windows 7, 8 and 8.1... getting the IDE installed... there's mixed results there, but it installs on Win 7 just fine... I think I've seen some people report that they got it working in Win 8 somehow... How much longer are you going to sit around begging for support until you find a suitable replacement? Not to be snippy but what the heck have you been doing the past 10 years? Why haven't you spent even the last 3 years looking for a replacement? what's holding you back? I bet it's the same thing that keeps me from trying out skydiving... fear... you've got your safe zone sand box and you don't want to leave it, and yet half of your reasons preclude you from not only .NE but VB6 as well... so that tells me you are simply too afraid to stick your neck out there, and learn something new. Based on your excuses, I suggest JAva... it's probably closest to cross-platform as you're going to get, and it has the ability to talk to the hardware when you need to.

    Please take what I'm about to say with the tongue in cheek and humor in which it's intended: It's time to man up, stop crying in your beer, drink the stupid beer (unless it's watered down at this point), suck it up and learn something new. Get off the proverbial fence, and get on the horse and ride dang it! RIDE! RIDE LIKE THE WIND!


    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  11. #11
    Frenzied Member
    Join Date
    Oct 2012
    Location
    Tampa, FL
    Posts
    1,187

    Re: THE .net and vb6 holy war

    Quote Originally Posted by axisdj View Post

    5. I have to obfuscate my code to protect it from design secrets ( recently looked at one of my competitors code and how they did things... his solution was written in .NET)
    Nice business ethics you have.

    Anyhow to the point, vb6 technology is old and deprecated. Maybe it gets the job done, but I could never be someone to be complacent with technology. I think the bigger thing is the C# vs VB.NET angle anyways.

  12. #12
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: THE .net and vb6 holy war

    Gee, TG takes "staying out of it" to a whole new level.


    Also, for a guy who doesn't want to argue, you sure throw out a bunch of red-meat comments. I was going to discuss doing some direct hardware communication more effectively in .NET, but what's the point? Many of us have spent years working in VB6, so we know you can't do ANYTHING. Buy you've been able to do everything you've thus far needed. That's good enough.

    However, MS isn't going to bring VB6 back. You sound like you have done some time in business, so you probably realize they can't bring it back. What would they do, say that they were going to resurrect VB6, but make no changes to it, or updates? That wouldn't fly. Heck, you've said explicitly that you only want it to be brought back while you find something to replace it that you are happy with, so even you, a true fan, are talking short-term fix. Are you going to buy VB6 every year, or are you asking them to support something they aren't going to sell? You want the support, but you don't want change that would break your apps, so you have no reason to buy. What kind of a business model is that?

    Even if you ignore all the differences between the language, you can't make a business case for bringing back VB6, so why complain to us? It's not a holy war, it's just business. What would you like us to do about it?
    My usual boring signature: Nothing

  13. #13
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: THE .net and vb6 holy war

    Quote Originally Posted by Shaggy Hiker View Post
    Gee, TG takes "staying out of it" to a whole new level.
    Sigh... I know... I know... I know... I feel so ashamed... I almost felt like I was falling for flame bait... tried to keep it civil and reasonable.

    I'm glad though I'm not the only one that sees the contradictions in the OP's wants. Stay in VB6 but future proof his apps... Stay with VB6 but maybe go cross-platform. Which... I'm trying to figure out what kind of hardware control kind of app would work on an Android or iPhone, but what do I know, I write business level applications.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  14. #14
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: THE .net and vb6 holy war

    Quote Originally Posted by axisdj View Post
    ....net really allowed me to do something vb6 cannot...
    Free threading.

    Lambdas.

    Delegates.

    Generics.

    Type inference.

    Inheritance.

    Reflection.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  15. #15
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: THE .net and vb6 holy war

    Everything changes.

    Microsoft to Developers: .NET Support Isn't Going Away

    Microsoft didn't go so far as to do a full 180 turn with its developer message. There were no mea culpas around the company's plan to phase out Silverlight, Windows Forms and Windows Presentation Foundation (WPF). That decision led to some grumbling from various .NET developers who continue to maintain that the Windows Runtime isn't a robust enough platform for building business apps.
    That's just passing on what Microsoft has said about parts of .Net that are now reduced to maintenance mode, much as all of VB6 has been.

    Then you have her uninformed speculation:

    It's not clear whether Microsoft ultimately will move the full .NET programming interface to the Windows Runtime at some point in the future, as some of the .NET faithful are hoping.
    Remember, she's no computer scientist.

    A serious look at WinRT makes it pretty clear "the full .Net programming interface" (?) won't ever be supported if she means the legacy UI frameworks, gratuitous multithreading, etc. because it can't be. WinRT has a heavily sandboxed, heavily asynchronous, quite different execution model from that of a traditional Windows desktop application.


    So don't cry for VB6, it has lots of company today.

  16. #16

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    481

    Re: THE .net and vb6 holy war

    I don't want this to go forever, but I felt I have to respond.

    Several of you state that my first point ( going cross platform ) , please understand, I am only saying if I need to rewrite my whole program, I would want that benefit, if not I am completely happy with windows only.

    I think .Net is perfect for business apps, My apps are more GUI-Hardware control.

    OK well , thanks for all the responses, still have no suggestions on a vb6 Like replacement that fills my requirements. For now I will continue to educate myself on QT Creator, XOJO, and XEROCODER so that when the time comes that COM is eliminated from windows and vb6 compiled apps don't work, I will be prepared to work fast. I think only that situation will push me for a complete re-write, because otherwise I could just be wasting my time, because when COM goes, I think a lot of other options will have to update as well.

    Thanks for your time, and keeping most of the discussion civil.

    Wishing all success in their field.

  17. #17
    WiggleWiggle dclamp's Avatar
    Join Date
    Aug 2006
    Posts
    3,527

    Re: THE .net and vb6 holy war

    Will you guys sign my petition to bring back VB5. This is what i started with in elementry school and I believe it is far better than VB6, .NET and .ORG. Please sign the petition.


    Thanks.

  18. #18

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    481

    Re: THE .net and vb6 holy war

    Quote Originally Posted by techgnome View Post
    And by "Support" what do you mean? And again, you just proved my point that a majority of the "bring back VB6" that's out there is self-centered and selfish...

    So what do you mean by "support" ... VB6 apps still run on Windows 7, 8 and 8.1... getting the IDE installed... there's mixed results there, but it installs on Win 7 just fine... I think I've seen some people report that they got it working in Win 8 somehow... How much longer are you going to sit around begging for support until you find a suitable replacement? Not to be snippy but what the heck have you been doing the past 10 years? Why haven't you spent even the last 3 years looking for a replacement? what's holding you back? I bet it's the same thing that keeps me from trying out skydiving... fear... you've got your safe zone sand box and you don't want to leave it, and yet half of your reasons preclude you from not only .NE but VB6 as well... so that tells me you are simply too afraid to stick your neck out there, and learn something new. Based on your excuses, I suggest JAva... it's probably closest to cross-platform as you're going to get, and it has the ability to talk to the hardware when you need to.

    Please take what I'm about to say with the tongue in cheek and humor in which it's intended: It's time to man up, stop crying in your beer, drink the stupid beer (unless it's watered down at this point), suck it up and learn something new. Get off the proverbial fence, and get on the horse and ride dang it! RIDE! RIDE LIKE THE WIND!


    -tg
    I have been researching and looking for a replacement since 2005, and only recently have found three that come close- QT Creator, XOJO, and XEROCODER.

    Yes it is fear that keeps me from moving to a new platform, fear that I will have to work 18 hour days for months, just to get the functionality my app has now.

    Thanks for the verbal motivation push.. hahaha

  19. #19
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: THE .net and vb6 holy war

    My experience with some of those 'other' platforms (not those specifically), is that they tend not to live up to their promise for a while....then fade away. I do some hardware interface stuff, as well, for robotics. I started on a platform that used a VB6-like compiler...that went away. I then switched to a promising company that had a full .NET library for interacting with their hardware in a thorough and elegant way (threading is awesome for hardware, by the way)....they appear to be out of business, now.

    It's just hard to know what horse to back.
    My usual boring signature: Nothing

  20. #20
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: THE .net and vb6 holy war

    Quote Originally Posted by axisdj View Post
    ...so that when the time comes that COM is eliminated from windows and vb6 compiled apps don't work, I will be prepared to work fast. I think only that situation will push me for a complete re-write, because otherwise I could just be wasting my time, because when COM goes, I think a lot of other options will have to update as well.
    Relax. COM cannot completely go away anytime soon. That's why I said by "Windows 15 or something" earlier. Like I said, COM is heavily integrated in a lot of Windows functionality. They cannot remove it in only a couple Windows releases. It must be gradual. Most likely COM will always remain in some fashion but eventually reach a point where MS stops adding new classes or improving it. As for now, COM is still very much alive and kicking.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  21. #21
    WiggleWiggle dclamp's Avatar
    Join Date
    Aug 2006
    Posts
    3,527

    Re: THE .net and vb6 holy war

    So is that a No on signing my petition for VB5?

  22. #22
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: THE .net and vb6 holy war

    Quote Originally Posted by dclamp View Post
    So is that a No on signing my petition for VB5?
    It might have been more effective if you had included the link, instead of making the rest of us go look it up...
    Sign DClamp's Petition here
    Sheesh...


    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  23. #23
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: THE .net and vb6 holy war

    Ah, the classics.
    My usual boring signature: Nothing

  24. #24
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: THE .net and vb6 holy war

    VB6 has garnered a lot of criticism over the years, some it warranted and some of it not so. I think that a lot of VB6 developers had already developed an "us and them" mentality long before VB.NET arrived. When Microsoft introduced VB.NET and so much changed within VB, those who were wedded to it felt that they had been betrayed by an ally, i.e. Microsoft, and developed an even more "us against the world" attitude.

    A lot of criticism was levelled at VB.NET, some of it warranted but most of it not, and VB.NET developers began to feel set upon. VB.NET suffered criticism from those who already had issue with VB and that was mostly undeserved and it also was being attacked by the VB community. With hackles raised, VB.NET developers decided to defend themselves and their chosen language. To be unjustly criticised by VB6 developers was just too much, who themselves and complained so long that they were unjustly criticised.

    The fact is that VB6 and earlier was a very successful language that could do a lot of things well but did little to encourage good habits. Those who took pride in their work could still write good code but, without any actual figures to back up my claim, I would say that VB6 had a greater proportion of developers who didn't take such pride than many other languages. That's because it took less effort to get something to produce a result in VB6 than many other languages, which is both a strength and a weakness. VB.NET is not as good as VB6 at some things but better at many others and the things it is good at are more relevant to more developers than those that it's not. For a few, moving to VB.NET might be a detriment. For most others, they would lose nothing and possibly gain much by switching from VB6 to VB.NET. If VB6 was still being actively supported then there would be no reason to switch but it's not. Microsoft has no obligation to continue VB6 support because people like it.

  25. #25
    WiggleWiggle dclamp's Avatar
    Join Date
    Aug 2006
    Posts
    3,527

    Re: THE .net and vb6 holy war

    Quote Originally Posted by techgnome View Post
    It might have been more effective if you had included the link, instead of making the rest of us go look it up...
    Sign DClamp's Petition here
    Sheesh...


    -tg
    Sir, Thank you for helping with my Petition. Your heart is in a good place.

  26. #26
    Frenzied Member
    Join Date
    Oct 2012
    Location
    Tampa, FL
    Posts
    1,187

    Re: THE .net and vb6 holy war

    Wow getting rickrolled on vb forums. A first time for everything?

  27. #27
    Wall Poster TysonLPrice's Avatar
    Join Date
    Sep 2002
    Location
    Columbus, Ohio
    Posts
    3,834

    Re: THE .net and vb6 holy war

    Quote Originally Posted by Niya View Post
    VB.Net is the natural successor to VB6. It makes no sense to me why people talk about reviving it when it has evolved already. If VB6 is so great, just stick with it.
    Yeah right...name one software company that said, "that's it we nailed it" and never sent out an improvement. You can't even buy a bar of soap that isn't "new and improved".

    Just having some fun....
    Please remember next time...elections matter!

  28. #28
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: THE .net and vb6 holy war

    Quote Originally Posted by TysonLPrice View Post
    Yeah right...name one software company that said, "that's it we nailed it" and never sent out an improvement. You can't even buy a bar of soap that isn't "new and improved".

    Just having some fun....
    VB.Net is the "new and improved" VB6.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  29. #29
    WiggleWiggle dclamp's Avatar
    Join Date
    Aug 2006
    Posts
    3,527

    Re: THE .net and vb6 holy war

    Quote Originally Posted by jayinthe813 View Post
    Wow getting rickrolled on vb forums. A first time for everything?
    Ehhh.... not the first time

  30. #30
    King of sapila
    Join Date
    Oct 2006
    Location
    Greece
    Posts
    6,597

    Re: THE .net and vb6 holy war

    First let me state that the OP not sleeping at night thinking of it made me giggle.
    Now, so if MS decides not to include VB and just leave us with C#, am i to assume that there will be a lot of whining here, right?
    Or if MS decides to create a new programming language - software and deprecate .Net, maybe we can all gather together , VB6ers and VB.NETers and have a good, strong weep.
    For me, since i don't own a company and just have to work for one, i would use whatever the company has available. Probably see what companies newest requirement are, start learning and apply for a job but i have been also offered a vb6 job lately and i am thinking of it, since they money is nice, with the crisis and all.
    Now if i was hosting my own company i could excuse myself for getting into a language fight but in the end i suppose i would go with the most modern technology and what would be supported for the forthcoming years. I mean i hate W8, i believe it is the turdiest turd ever created by a human hand but if one company will use, let say new W9 with Microsoft .NET2 the return of Jaggar, that will be bound and supported on future Windows versions and another company uses lovable W7 with .NET 5.0 that will be the last .NET framework created then,if i could choose the job, i would go with the first company, of course cursing MS for ruining my weekend...Again.
    So, yeah i will have to stay awake and think this one.OK, sorry couldn't resist.
    P.S. VB.NET here in Greece is starting to be a thing of the past, almost 90% of the job positions state C#, so i can kinda feel the VB6 people that MS stole their bone but he is also stealing my bone.So i would say, get over it and start learning new stuff.Or don't.
    P.S2 In a perfect world that VB6 would be updated and run modern apps(multithreading, better DB management(don' give a rats ass about lamdas and other "sophisticated" stuff) etc) and i had to choose then i would go with the new VB6 or better yet and updated C++ would be nice.GUI memory managementtt!!!!Viruuussss!!!!Ehh, ignore that one, i mean i have a virus, cough cough,apppsssiuuuuuu, yeah, etc.
    ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς μάλα πολλὰ
    πλάγχθη, ἐπεὶ Τροίης ἱερὸν πτολίεθρον ἔπερσεν·

  31. #31
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: THE .net and vb6 holy war

    Quote Originally Posted by sapator View Post
    Now, so if MS decides not to include VB and just leave us with C#, am i to assume that there will be a lot of whining here, right?
    Or if MS decides to create a new programming language - software and deprecate .Net, maybe we can all gather together , VB6ers and VB.NETers and have a good, strong weep.
    I'm quite sure that, if VB.NET gets canned, there will be a great deal of grumbling. If C# is still supported though, a developers entire .NET knowledge is transferable and all that needs to be learned is a new language syntax. In many cases, the only difference between VB code and C# code that does the same thing is the addition of some semicolons. I wouldn't really be complaining at all because I already do most of my work in C# anyway. I'd just have to shift my focus in order to maintain my MVP award. With all those newbie C# developers though, it probably wouldn't be hard.

    If .NET was canned altogether then that would be a different thing altogether. That would require a lot of retooling by a lot of developers, myself included. I'm sure that that day will come though. What you won't hear in either case is, more than a decade after the fact, old VB.NET or .NET developers starting petitions to have support and further development reinstated. They would have all moved on to other languages and technologies long since or else accepted that they worked in maintaining legacy systems and that's it.

  32. #32
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: THE .net and vb6 holy war

    Quote Originally Posted by sapator View Post
    P.S. VB.NET here in Greece is starting to be a thing of the past, almost 90% of the job positions state C#
    Actually, every VB.Net programmer is also a C# programmer. Every thing that can be done in VB.Net would be done exactly the same way in C#. The only difference between the two languages is syntax. In fact you should be able to chuck any small to medium sized VB.Net app into a converter and get C# code that works immediately.

    As a matter of fact here is an example from one of my larger projects. This is a fairly large method that I wrote to upload files.

    Here is the original VB.Net code:-
    vbnet Code:
    1. '
    2. Private Sub InternalBeginUploads(ByVal files As IList(Of MBFTProtocol.MBFTFileInfo), ByVal startIndex As Integer, ByVal firstFileStartOffset As Long)
    3.  
    4.         SetElapsedContinue()
    5.         SetRemoteDownloadSettings()
    6.  
    7.         SendTextMessage("File being prepared for transfer")
    8.  
    9.         'We do not change the list under resume conditions
    10.         If Me.UploadChangedFilesOnly AndAlso (firstFileStartOffset = 0 AndAlso startIndex = 0) Then
    11.             files = files.Where(Function(f) New FileInfo(f.FullSourcePath).Attributes And FileAttributes.Archive).ToArray
    12.         End If
    13.  
    14.         g_lFileBytesExpectedInAll = files.Sum(Function(fi) fi.FileSize)
    15.         g_lFileBytesSentInAll = files.Take(startIndex).Sum(Function(fi) fi.FileSize) + firstFileStartOffset
    16.         g_iNumberOfFiles = files.Count
    17.         g_lstFiles = files
    18.  
    19.         'This will tell the remote machine how many files
    20.         'to expect
    21.         Dim uplInfo As New MBFTProtocol.PrepareToDownloadMessage
    22.  
    23.         uplInfo.Files = files.ToArray
    24.  
    25.         If startIndex <> 0 OrElse firstFileStartOffset <> 0 Then
    26.             uplInfo.IsResume = True
    27.         Else
    28.             uplInfo.IsResume = False
    29.         End If
    30.  
    31.         g_enState = enumFileUploadState.SendingUploadInfo
    32.         If Not MyBase.SendProtocolData(uplInfo) Then
    33.             g_enState = enumFileUploadState.SendFailed
    34.  
    35.             g_sErrorMsg = "Failed to send upload info"
    36.         End If
    37.  
    38.         For Me.g_iCurIndex = startIndex To files.Count - 1
    39.  
    40.             Dim curFile As MBFTProtocol.MBFTFileInfo = files(g_iCurIndex)
    41.  
    42.             Dim fs As FileStream = Nothing
    43.  
    44.             g_lCurFileSize = curFile.FileSize
    45.             g_sCurFile = curFile.ShortFileName
    46.             g_lCurFileBytesSent = 0
    47.  
    48.             Dim nf As New MBFTProtocol.UploadingFileAtIndexMessage
    49.  
    50.             nf.Index = g_iCurIndex
    51.  
    52.             'These conditions are resume conditions
    53.             If g_iCurIndex = startIndex AndAlso firstFileStartOffset > 0 Then
    54.                 nf.IsResume = True
    55.                 nf.ResumeFileOffset = firstFileStartOffset
    56.             End If
    57.  
    58.  
    59.             Try
    60.                 If Not Me.CompressBeforeUpload Then
    61.                     fs = New FileStream(curFile.FullSourcePath, FileMode.Open, FileAccess.Read)
    62.                 Else
    63.                     SendTextMessage("Compressing file:" + curFile.ShortFileName)
    64.  
    65.                     'g_bCompressing = True
    66.                     g_sLastMsg = "Compressing File:" + curFile.ShortFileName
    67.                     fs = MBCompression.GetCompressedFileStream(curFile.FullSourcePath, FileMode.Open, FileAccess.Read)
    68.                     'g_bCompressing = False
    69.                     g_sLastMsg = ""
    70.  
    71.                     nf.CompressedSize = fs.Length
    72.  
    73.                 End If
    74.  
    75.                 'Facilitates resuming
    76.                 If g_iCurIndex = startIndex Then
    77.                     fs.Position = firstFileStartOffset
    78.                     g_lCurFileBytesSent = firstFileStartOffset
    79.                 End If
    80.  
    81.  
    82.                 SendTextMessage("Sending file")
    83.  
    84.                 g_enState = enumFileUploadState.SendingFileInfo
    85.  
    86.                 'Prepare the state of the remote machine
    87.                 'to receive the file. Note: We must not
    88.                 'try to send anything other than
    89.                 'the file after this point up until the file send
    90.                 'has been completed as this message
    91.                 'can set the remote machine to start writing
    92.                 'smack in the middle of a file stream which
    93.                 'would make it impossible for the remote
    94.                 'machine to recognize messages
    95.  
    96.                 If Not MyBase.SendProtocolData(nf) Then
    97.  
    98.                     g_enState = enumFileUploadState.SendFailed
    99.  
    100.                     g_sErrorMsg = "Failed to send info for file:" + curFile.ShortFileName
    101.                     fs.Close()
    102.  
    103.                     If Me.CompressBeforeUpload Then File.Delete(fs.Name)
    104.  
    105.                     Return
    106.                 End If
    107.  
    108.                 g_enState = enumFileUploadState.SendingFile
    109.                 If Not Me.AdvSocket.SendStream(fs) Then
    110.                     g_enState = enumFileUploadState.SendFailed
    111.  
    112.                     g_sErrorMsg = "Failed to complete sending file:" + curFile.ShortFileName
    113.  
    114.                     fs.Close()
    115.                     If Me.CompressBeforeUpload Then File.Delete(fs.Name)
    116.  
    117.                     Return
    118.                 Else
    119.                     If Me.UploadChangedFilesOnly Then
    120.                         Dim attr = File.GetAttributes(curFile.FullSourcePath)
    121.  
    122.                         File.SetAttributes(curFile.FullSourcePath, attr And (Not FileAttribute.Archive))
    123.                     End If
    124.  
    125.                     If Me.DeleteAfterUpload Then
    126.                         File.Delete(curFile.FullSourcePath)
    127.                     End If
    128.  
    129.  
    130.                 End If
    131.  
    132.             Catch ex As Exception
    133.                 If Not Me.SkipFileOnError Then
    134.                     g_enState = enumFileUploadState.SendFailed
    135.                     Dim respErr As New MBFTProtocol.FileTransferResponseError
    136.  
    137.                     g_sErrorMsg = ex.Message
    138.  
    139.                     respErr.ErrorMessage = ex.Message
    140.  
    141.                     If fs IsNot Nothing Then
    142.                         fs.Close()
    143.                     End If
    144.  
    145.                     MyBase.SendProtocolData(respErr)
    146.                     SendTextMessage("Remote error:" + ex.Message)
    147.  
    148.                     Return
    149.  
    150.                 Else
    151.                     Dim skipMsg As New MBFTProtocol.SkippingFileUploadMessage
    152.                     skipMsg.ErrorMessage = ex.Message
    153.                     skipMsg.FullFilePath = curFile.FullSourcePath
    154.  
    155.                     If Not MyBase.SendProtocolData(skipMsg) Then
    156.                         g_sErrorMsg = "Failed to send skip message"
    157.  
    158.                         g_enState = enumFileUploadState.SendFailed
    159.                     End If
    160.  
    161.                 End If
    162.             End Try
    163.  
    164.             If fs IsNot Nothing Then
    165.                 fs.Close()
    166.                 If Me.CompressBeforeUpload Then File.Delete(fs.Name)
    167.             End If
    168.         Next
    169.  
    170.         g_enState = enumFileUploadState.UploadsComplete
    171.         SaveElapsed()
    172.  
    173.         MyBase.SendProtocolData(New MBFTProtocol.NoMoreFilesMessage)
    174.  
    175.     End Sub

    And here is the code after passing it through Telerik's online converter:-
    c# Code:
    1. //
    2. private void InternalBeginUploads(IList<MBFTProtocol.MBFTFileInfo> files, int startIndex, long firstFileStartOffset)
    3. {
    4.     SetElapsedContinue();
    5.     SetRemoteDownloadSettings();
    6.  
    7.     SendTextMessage("File being prepared for transfer");
    8.  
    9.     //We do not change the list under resume conditions
    10.     if (this.UploadChangedFilesOnly && (firstFileStartOffset == 0 && startIndex == 0)) {
    11.         files = files.Where(f => new FileInfo(f.FullSourcePath).Attributes & FileAttributes.Archive).ToArray;
    12.     }
    13.  
    14.     g_lFileBytesExpectedInAll = files.Sum(fi => fi.FileSize);
    15.     g_lFileBytesSentInAll = files.Take(startIndex).Sum(fi => fi.FileSize) + firstFileStartOffset;
    16.     g_iNumberOfFiles = files.Count;
    17.     g_lstFiles = files;
    18.  
    19.     //This will tell the remote machine how many files
    20.     //to expect
    21.     MBFTProtocol.PrepareToDownloadMessage uplInfo = new MBFTProtocol.PrepareToDownloadMessage();
    22.  
    23.     uplInfo.Files = files.ToArray;
    24.  
    25.     if (startIndex != 0 || firstFileStartOffset != 0) {
    26.         uplInfo.IsResume = true;
    27.     } else {
    28.         uplInfo.IsResume = false;
    29.     }
    30.  
    31.     g_enState = enumFileUploadState.SendingUploadInfo;
    32.     if (!base.SendProtocolData(uplInfo)) {
    33.         g_enState = enumFileUploadState.SendFailed;
    34.  
    35.         g_sErrorMsg = "Failed to send upload info";
    36.     }
    37.  
    38.  
    39.     for (this.g_iCurIndex = startIndex; this.g_iCurIndex <= files.Count - 1; this.g_iCurIndex++) {
    40.         MBFTProtocol.MBFTFileInfo curFile = files(g_iCurIndex);
    41.  
    42.         FileStream fs = null;
    43.  
    44.         g_lCurFileSize = curFile.FileSize;
    45.         g_sCurFile = curFile.ShortFileName;
    46.         g_lCurFileBytesSent = 0;
    47.  
    48.         MBFTProtocol.UploadingFileAtIndexMessage nf = new MBFTProtocol.UploadingFileAtIndexMessage();
    49.  
    50.         nf.Index = g_iCurIndex;
    51.  
    52.         //These conditions are resume conditions
    53.         if (g_iCurIndex == startIndex && firstFileStartOffset > 0) {
    54.             nf.IsResume = true;
    55.             nf.ResumeFileOffset = firstFileStartOffset;
    56.         }
    57.  
    58.  
    59.         try {
    60.             if (!this.CompressBeforeUpload) {
    61.                 fs = new FileStream(curFile.FullSourcePath, FileMode.Open, FileAccess.Read);
    62.             } else {
    63.                 SendTextMessage("Compressing file:" + curFile.ShortFileName);
    64.  
    65.                 //g_bCompressing = True
    66.                 g_sLastMsg = "Compressing File:" + curFile.ShortFileName;
    67.                 fs = MBCompression.GetCompressedFileStream(curFile.FullSourcePath, FileMode.Open, FileAccess.Read);
    68.                 //g_bCompressing = False
    69.                 g_sLastMsg = "";
    70.  
    71.                 nf.CompressedSize = fs.Length;
    72.  
    73.             }
    74.  
    75.             //Facilitates resuming
    76.             if (g_iCurIndex == startIndex) {
    77.                 fs.Position = firstFileStartOffset;
    78.                 g_lCurFileBytesSent = firstFileStartOffset;
    79.             }
    80.  
    81.  
    82.             SendTextMessage("Sending file");
    83.  
    84.             g_enState = enumFileUploadState.SendingFileInfo;
    85.  
    86.             //Prepare the state of the remote machine
    87.             //to receive the file. Note: We must not
    88.             //try to send anything other than
    89.             //the file after this point up until the file send
    90.             //has been completed as this message
    91.             //can set the remote machine to start writing
    92.             //smack in the middle of a file stream which
    93.             //would make it impossible for the remote
    94.             //machine to recognize messages
    95.  
    96.  
    97.             if (!base.SendProtocolData(nf)) {
    98.                 g_enState = enumFileUploadState.SendFailed;
    99.  
    100.                 g_sErrorMsg = "Failed to send info for file:" + curFile.ShortFileName;
    101.                 fs.Close();
    102.  
    103.                 if (this.CompressBeforeUpload)
    104.                     File.Delete(fs.Name);
    105.  
    106.                 return;
    107.             }
    108.  
    109.             g_enState = enumFileUploadState.SendingFile;
    110.             if (!this.AdvSocket.SendStream(fs)) {
    111.                 g_enState = enumFileUploadState.SendFailed;
    112.  
    113.                 g_sErrorMsg = "Failed to complete sending file:" + curFile.ShortFileName;
    114.  
    115.                 fs.Close();
    116.                 if (this.CompressBeforeUpload)
    117.                     File.Delete(fs.Name);
    118.  
    119.                 return;
    120.             } else {
    121.                 if (this.UploadChangedFilesOnly) {
    122.                     dynamic attr = File.GetAttributes(curFile.FullSourcePath);
    123.  
    124.                     File.SetAttributes(curFile.FullSourcePath, attr & (!FileAttribute.Archive));
    125.                 }
    126.  
    127.                 if (this.DeleteAfterUpload) {
    128.                     File.Delete(curFile.FullSourcePath);
    129.                 }
    130.  
    131.  
    132.             }
    133.  
    134.         } catch (Exception ex) {
    135.             if (!this.SkipFileOnError) {
    136.                 g_enState = enumFileUploadState.SendFailed;
    137.                 MBFTProtocol.FileTransferResponseError respErr = new MBFTProtocol.FileTransferResponseError();
    138.  
    139.                 g_sErrorMsg = ex.Message;
    140.  
    141.                 respErr.ErrorMessage = ex.Message;
    142.  
    143.                 if (fs != null) {
    144.                     fs.Close();
    145.                 }
    146.  
    147.                 base.SendProtocolData(respErr);
    148.                 SendTextMessage("Remote error:" + ex.Message);
    149.  
    150.                 return;
    151.  
    152.             } else {
    153.                 MBFTProtocol.SkippingFileUploadMessage skipMsg = new MBFTProtocol.SkippingFileUploadMessage();
    154.                 skipMsg.ErrorMessage = ex.Message;
    155.                 skipMsg.FullFilePath = curFile.FullSourcePath;
    156.  
    157.                 if (!base.SendProtocolData(skipMsg)) {
    158.                     g_sErrorMsg = "Failed to send skip message";
    159.  
    160.                     g_enState = enumFileUploadState.SendFailed;
    161.                 }
    162.  
    163.             }
    164.         }
    165.  
    166.         if (fs != null) {
    167.             fs.Close();
    168.             if (this.CompressBeforeUpload)
    169.                 File.Delete(fs.Name);
    170.         }
    171.     }
    172.  
    173.     g_enState = enumFileUploadState.UploadsComplete;
    174.     SaveElapsed();
    175.  
    176.     base.SendProtocolData(new MBFTProtocol.NoMoreFilesMessage());
    177.  
    178. }
    179.  
    180. //=======================================================
    181. //Service provided by Telerik ([url]www.telerik.com[/url])
    182. //Conversion powered by NRefactory.
    183. //Twitter: @telerik
    184. //Facebook: facebook.com/telerik
    185. //=======================================================

    You should notice that it executes the exact same steps in order to work. As a matter of fact, both version would compile to the same MSIL code which is what the runtime cares about. I'm not worried about VB.Net being phased out in favor of C#. Only a minor inconvenience for me since I'm more comfortable working with VB syntax. But I don't have to learn anything new to do something in C# that I can already do in VB.Net.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  33. #33
    King of sapila
    Join Date
    Oct 2006
    Location
    Greece
    Posts
    6,597

    Re: THE .net and vb6 holy war

    I kind of know about the C# but i prefer not to have to put that damn ";", and not to use "{}" and not to check my uppercase (mind you i do all of that in Javascript, so i am just blowing steam right now). I think C# has some coding about the pointer * sign additions in some cases and some marshalling techniques that are hard to be translated to VB, other that that, yep, that's why i also apply to C# jobs but if you deprecate VB.NET then this site should be called CsharpForums, excuse me, i mean, csharpforums

    "uplInfo.Files = files.ToArray;" i would do UplInfo.Files = Files.ToArray; and i'm out.
    ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς μάλα πολλὰ
    πλάγχθη, ἐπεὶ Τροίης ἱερὸν πτολίεθρον ἔπερσεν·

  34. #34
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: THE .net and vb6 holy war

    Quote Originally Posted by sapator View Post
    "uplInfo.Files = files.ToArray;" i would do UplInfo.Files = Files.ToArray;
    What's the point of that ?
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  35. #35
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: THE .net and vb6 holy war

    Quote Originally Posted by Niya View Post
    What's the point of that ?
    I wonder the same thing. It is convention to start a method parameter with a lower-case letter in both VB and C#. You don't have to adhere to that convention but I can't think of any good reason not to.

    That said, neither would work. Unlike VB, C# requires parentheses on a method call. Without parentheses, you are actually using a reference to the method itself, which is the equivalent of using AddressOf in VB. I always use parentheses on method calls in VB anyway though, so that's not a gotcha that I ever fall victim to.

  36. #36
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: THE .net and vb6 holy war

    Wow, I was guessing there was some drunken posting going on, but Sapator sure sobered up fast between those two posts.

    Stupid semicolons, anyways.
    My usual boring signature: Nothing

  37. #37
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: THE .net and vb6 holy war

    Quote Originally Posted by Shaggy Hiker View Post
    Stupid semicolons, anyways.
    It is because of it's use of semicolons that C# never needed to use stupid underscores as line continuation characters. At least VB managed to rid itself of those, for the most part. I can't speak for everyone but, even though I still write quite a bit of VB code, I never give a second thought to using semicolons in C#. I cut my teeth on C and C++ though, so maybe that's the reason. Those who started out with VB6 and then VB.NET and then C# might feel slightly different about it. I do the majority of my work in C# too, not just bits here and there.

  38. #38
    Frenzied Member
    Join Date
    Oct 2012
    Location
    Tampa, FL
    Posts
    1,187

    Re: THE .net and vb6 holy war

    I cant remember to put the ";" terminator for the life of me. Sometimes ill just sit there looking at the squiggly lines scratching my head until it hits me.

  39. #39
    King of sapila
    Join Date
    Oct 2006
    Location
    Greece
    Posts
    6,597

    Re: THE .net and vb6 holy war

    So i was offered a job using VB6 and MSSQL2000 and a job using 4.0 framework and MSSQL 2008. The first job pays more cash and it may or may not be updated (in a couple of years) to C# and the other job pays less money but is on todays standards.
    Which one should i accept and why?
    Thanks.
    ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς μάλα πολλὰ
    πλάγχθη, ἐπεὶ Τροίης ἱερὸν πτολίεθρον ἔπερσεν·

  40. #40
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: THE .net and vb6 holy war

    Quote Originally Posted by sapator View Post
    So i was offered a job using VB6 and MSSQL2000 and a job using 4.0 framework and MSSQL 2008. The first job pays more cash and it may or may not be updated (in a couple of years) to C# and the other job pays less money but is on todays standards.
    Which one should i accept and why?
    Thanks.
    That's hardly a question that we can answer because only you know your priorities. I wouldn't take a job working with VB6, even if it paid more, because I wouldn't enjoy it. Those who enjoy VB6 wouldn't have that impediment and some may just want more money regardless. You should take the one that you believe will best fulfil your desires of a job, whatever those may be.

Page 1 of 4 1234 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width