Vb 6.0
-
Hi , I have a homework to do in VB 6.0 but I couldnt even figure out TextBox's Text Property when I code ..it gives an error as "Argument Not Optional" I found text Property textBox1.Item.Text , but the error givenn..Why ? if I code , textBox1.Text it couldnt find such a property... If anybody could help me , I would be greatful..I need a Telephone Book in Vb 6.0.. if somebody has an old project like that...please forward to bcambel[at]gmail[dot]com I did the project in VB.NEt but teacher has refused it , and insist on me to do the project in VB , please hellppp..I am begging :D Anyways , thanks in advance!
-
Hi , I have a homework to do in VB 6.0 but I couldnt even figure out TextBox's Text Property when I code ..it gives an error as "Argument Not Optional" I found text Property textBox1.Item.Text , but the error givenn..Why ? if I code , textBox1.Text it couldnt find such a property... If anybody could help me , I would be greatful..I need a Telephone Book in Vb 6.0.. if somebody has an old project like that...please forward to bcambel[at]gmail[dot]com I did the project in VB.NEt but teacher has refused it , and insist on me to do the project in VB , please hellppp..I am begging :D Anyways , thanks in advance!
Wait a minute! You said you wrote the application in VB.NET, yet you can't figure out the Text property on a VB6 TextBox??? :confused: The TextBox in VB6 works almost entirely the same as the TextBox in VB.NET... Makes me wonder, did YOU REALLY write the VB.NET version or did you, like in your post here, just ask for it and someone, stupidly, gave you their VB.NET version? Sorry, we don't do homework here. You have to write the code! And if you have problems with it, then we'll help. Noone here is going to just hand you their completed project so you can save your ass. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Wait a minute! You said you wrote the application in VB.NET, yet you can't figure out the Text property on a VB6 TextBox??? :confused: The TextBox in VB6 works almost entirely the same as the TextBox in VB.NET... Makes me wonder, did YOU REALLY write the VB.NET version or did you, like in your post here, just ask for it and someone, stupidly, gave you their VB.NET version? Sorry, we don't do homework here. You have to write the code! And if you have problems with it, then we'll help. Noone here is going to just hand you their completed project so you can save your ass. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
I wrote the VB.NET version! I know that both of the properties just look same! I told the problem .I dont force anybody to do my homework.I just ask... If you dont believe , I could send you a bunch of projects that I did before.. Rather that behaving like the lawyer of the CP , if you know the answer , you may help!You dont need to accuse me ..Got it ?
-
I wrote the VB.NET version! I know that both of the properties just look same! I told the problem .I dont force anybody to do my homework.I just ask... If you dont believe , I could send you a bunch of projects that I did before.. Rather that behaving like the lawyer of the CP , if you know the answer , you may help!You dont need to accuse me ..Got it ?
I found the problem , Although I change the name property , some how its name didnt change.. 2 more questions , how could I open a OpenFileDialog like in .Net ? And is there an Xml support in Visual Studio 6 ?
-
I wrote the VB.NET version! I know that both of the properties just look same! I told the problem .I dont force anybody to do my homework.I just ask... If you dont believe , I could send you a bunch of projects that I did before.. Rather that behaving like the lawyer of the CP , if you know the answer , you may help!You dont need to accuse me ..Got it ?
Bahadir Cambel wrote: Rather that behaving like the lawyer of the CP , if you know the answer , you may help!You dont need to accuse me ..Got it ? LOL. Lawyers are not THAT bad ... LOL
-
Bahadir Cambel wrote: Rather that behaving like the lawyer of the CP , if you know the answer , you may help!You dont need to accuse me ..Got it ? LOL. Lawyers are not THAT bad ... LOL
Yes , I like them all(a big lie ) , esp the woman ones :D
-
Hi , I have a homework to do in VB 6.0 but I couldnt even figure out TextBox's Text Property when I code ..it gives an error as "Argument Not Optional" I found text Property textBox1.Item.Text , but the error givenn..Why ? if I code , textBox1.Text it couldnt find such a property... If anybody could help me , I would be greatful..I need a Telephone Book in Vb 6.0.. if somebody has an old project like that...please forward to bcambel[at]gmail[dot]com I did the project in VB.NEt but teacher has refused it , and insist on me to do the project in VB , please hellppp..I am begging :D Anyways , thanks in advance!
If your teacher won't accept VB.NET and requires VB6, just leave the class, and find one where if you can't use a decent language, you can at least learn the latest version of a crappy one. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
If your teacher won't accept VB.NET and requires VB6, just leave the class, and find one where if you can't use a decent language, you can at least learn the latest version of a crappy one. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Christian Graus wrote: If your teacher won't accept VB.NET and requires VB6, just leave the class, and find one where if you can't use a decent language, you can at least learn the latest version of a crappy one. Christian, You never answered my question: "What significant capabilities does C# offer that VB.NET does not?" I could write an intelligent parsing algorithm to replace all the braces in your code and end up with the same programming language you so love to despise. Face it. C# is pretty wimpy all-in-all. At least as wimpy as VB.NET. Plus VB.NET does not try to parade itself as a Java look-alike. ROTFLMAO! If you want a challenge and real programming, hang out in the ATL or COM forums more often.
-
Christian Graus wrote: If your teacher won't accept VB.NET and requires VB6, just leave the class, and find one where if you can't use a decent language, you can at least learn the latest version of a crappy one. Christian, You never answered my question: "What significant capabilities does C# offer that VB.NET does not?" I could write an intelligent parsing algorithm to replace all the braces in your code and end up with the same programming language you so love to despise. Face it. C# is pretty wimpy all-in-all. At least as wimpy as VB.NET. Plus VB.NET does not try to parade itself as a Java look-alike. ROTFLMAO! If you want a challenge and real programming, hang out in the ATL or COM forums more often.
rwestgraham wrote: You never answered my question: "What significant capabilities does C# offer that VB.NET does not?" You're asking the wrong question. I never claimed that this was the case, at all. VB.NET is crap, not because C# has more capabilities ( this would make C# crap, as C++ can do more ). It sucks because it is dragged down by legacy 'features' that Microsoft were forced to provide to keep the VB6 monkeys happy. For example, any language that auto generates return values for you is creating far more opportunities for hard to find bugs than any C++ switch statement could create. However, here's a list I keep on my desktop ( I didn't write it, but it covers most things I would mention, and I like how it's worded ) 1. The absence of the "using" statement for calling IDisposable creates resource-hungry programs. VB programmers simply do not call IDisposable, or do not call it in a reliable way. 2. "Unstructured error handling". Aka "On Error Goto". Aka bad code. 3. "On Error Resume Next". Aka "On Error F**k off". This is one of my favorites: in case of an error, resume the execution point on the next statement. Lots of fun here. 4. "On Error Goto 0" and "On Error Goto -1". I'm yet to find a VB programmer who can tell the difference between the two. 5. The "Mid" statement. No, not the function, the statement. Isn't it a work of a genius naming a statement and a function with the same name? 6. "Modules". Aka "I don't need any stinking classes". Aka "I won't ever need thread safety" 7. The "With" statement. Aka "I don't need any stinking methods. I manipulate an object outside the class definition and I call it information hiding". Aka the "data class" bad code smell. Aka "deriving a class is too much work". 8. "Option Compare Text". Aka "I don't need performance when comparing strings" 9. "Option Explicit Off". Aka "There's only one type, the powerful Object". Aka "I want to give away performance because I'm lazy typing variable declarations". Aka "I don't want a compiler checking the variable names for me. If I mistype a name, just create another one for me, pleeeease." 10. "Option Strict Off". Aka "What? Why can't I just assing this string variable to this integer variable?" 11. The hidden return variable. All functions have a hidden variable that is named with the same name as the function. Don't forget to assign to it. In any code path. If you forget, VB choses a default value for you and won't warn you. 12. BTW, there are no warnings. And this is mea
-
rwestgraham wrote: You never answered my question: "What significant capabilities does C# offer that VB.NET does not?" You're asking the wrong question. I never claimed that this was the case, at all. VB.NET is crap, not because C# has more capabilities ( this would make C# crap, as C++ can do more ). It sucks because it is dragged down by legacy 'features' that Microsoft were forced to provide to keep the VB6 monkeys happy. For example, any language that auto generates return values for you is creating far more opportunities for hard to find bugs than any C++ switch statement could create. However, here's a list I keep on my desktop ( I didn't write it, but it covers most things I would mention, and I like how it's worded ) 1. The absence of the "using" statement for calling IDisposable creates resource-hungry programs. VB programmers simply do not call IDisposable, or do not call it in a reliable way. 2. "Unstructured error handling". Aka "On Error Goto". Aka bad code. 3. "On Error Resume Next". Aka "On Error F**k off". This is one of my favorites: in case of an error, resume the execution point on the next statement. Lots of fun here. 4. "On Error Goto 0" and "On Error Goto -1". I'm yet to find a VB programmer who can tell the difference between the two. 5. The "Mid" statement. No, not the function, the statement. Isn't it a work of a genius naming a statement and a function with the same name? 6. "Modules". Aka "I don't need any stinking classes". Aka "I won't ever need thread safety" 7. The "With" statement. Aka "I don't need any stinking methods. I manipulate an object outside the class definition and I call it information hiding". Aka the "data class" bad code smell. Aka "deriving a class is too much work". 8. "Option Compare Text". Aka "I don't need performance when comparing strings" 9. "Option Explicit Off". Aka "There's only one type, the powerful Object". Aka "I want to give away performance because I'm lazy typing variable declarations". Aka "I don't want a compiler checking the variable names for me. If I mistype a name, just create another one for me, pleeeease." 10. "Option Strict Off". Aka "What? Why can't I just assing this string variable to this integer variable?" 11. The hidden return variable. All functions have a hidden variable that is named with the same name as the function. Don't forget to assign to it. In any code path. If you forget, VB choses a default value for you and won't warn you. 12. BTW, there are no warnings. And this is mea
Christian Graus wrote: 1. The absence of the "using" statement for calling IDisposable creates resource-hungry programs. VB programmers simply do not call IDisposable, or do not call it in a reliable way. VB.NET class can fully implement the IDisposable interface. It is very simple to do. The next section of your "complaints" are all deprecated features. I use structured error handling only in VB.NET. All languages contain "features" that can lead to poor practices. This is hardly unique to VB. I don't think you understand the context of using the With Statement at all. It is not used for manipulating class objects outside of the class definition. Rather it is a way to reduce the number of dot redirections that have to be interpreted by the compiler. Using With actually results in more efficient code because it eliminates unneccessary redirection evaluations when you plan to perform a number of operations on the same object. It does not break any rules of encapsulation as you seem to infer. It simply reduces the compiler overhead. The "hidden return variable". I don't think you understand how this is actually used in practice. If you carry over VB6 practices, you never have to worry about any default values because VB6 required you to explicitly return a function value using this "hidden variable". If you use the NET syntax or explicitly returning a value using a Return statement the hidden varaiable is ignored. In either usage, the argument that this mystery varaible lurking around can result in hidden bugs just does not wash, because whether you use the VB6 syntax, or the Net Return syntax - and you have to use one or another, the possibility of this mystery varaible returning spurious results is just not a practical consideration. No warnings? Well this might actually mean something. However, the vast majority of C++ code I have seen written either simply ignored warnings, or added compiler switches to suppress them. I would consider this a valid point, except that I've seen little evidence that the majority of developers actually act on warnings. So why bother? REM - Come on. This is really reaching to just to find a list of faults. REM has been held over from the ancient days of Basic. I know of no one who actually uses it in any of the higher Vb releases. I mean what's the point? Why type REM when you can simply type a '. Array Covariance - exists in C# as well. What is unique about this to VB.NET? Writing multi-threaded code correc
-
Christian Graus wrote: 1. The absence of the "using" statement for calling IDisposable creates resource-hungry programs. VB programmers simply do not call IDisposable, or do not call it in a reliable way. VB.NET class can fully implement the IDisposable interface. It is very simple to do. The next section of your "complaints" are all deprecated features. I use structured error handling only in VB.NET. All languages contain "features" that can lead to poor practices. This is hardly unique to VB. I don't think you understand the context of using the With Statement at all. It is not used for manipulating class objects outside of the class definition. Rather it is a way to reduce the number of dot redirections that have to be interpreted by the compiler. Using With actually results in more efficient code because it eliminates unneccessary redirection evaluations when you plan to perform a number of operations on the same object. It does not break any rules of encapsulation as you seem to infer. It simply reduces the compiler overhead. The "hidden return variable". I don't think you understand how this is actually used in practice. If you carry over VB6 practices, you never have to worry about any default values because VB6 required you to explicitly return a function value using this "hidden variable". If you use the NET syntax or explicitly returning a value using a Return statement the hidden varaiable is ignored. In either usage, the argument that this mystery varaible lurking around can result in hidden bugs just does not wash, because whether you use the VB6 syntax, or the Net Return syntax - and you have to use one or another, the possibility of this mystery varaible returning spurious results is just not a practical consideration. No warnings? Well this might actually mean something. However, the vast majority of C++ code I have seen written either simply ignored warnings, or added compiler switches to suppress them. I would consider this a valid point, except that I've seen little evidence that the majority of developers actually act on warnings. So why bother? REM - Come on. This is really reaching to just to find a list of faults. REM has been held over from the ancient days of Basic. I know of no one who actually uses it in any of the higher Vb releases. I mean what's the point? Why type REM when you can simply type a '. Array Covariance - exists in C# as well. What is unique about this to VB.NET? Writing multi-threaded code correc
rwestgraham wrote: VB.NET class can fully implement the IDisposable interface. It is very simple to do. So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. rwestgraham wrote: The next section of your "complaints" are all deprecated features. I use structured error handling only in VB.NET. All languages contain "features" that can lead to poor practices. This is hardly unique to VB. Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. C++ has similar problems, for the same reason - C compatibility. That's where C# is better, it has no older language it needs to pander to. Name the 'features' unique to C# that can cause similar problems ? rwestgraham wrote: Writing multi-threaded code correctly requires advanced abilities that are beyond the skills of most programmers period Perhaps. So what ? rwestgraham wrote: Ignorance is by no means defined by using one language as opposed to another. Ignorance is ubiquitous, period. Did you read my comment ? I agree, and in C#/VB.NET the only dividing line is that most VB.NET programmers got there via VB6, which used to be the answer to the question 'what's the easiest way to write code for Windows'. The people coming to C# tend to be VB6 users who are real programmers ( not scared of a new language ), and people who come from C++, who asked 'what's the BEST way to write code for Windows'. rwestgraham wrote: If you don't want to use VB, don't use VB. I guess my real question is what do you get from constantly bashing VB? Initially, because VB6 was crap. Since then, I've sufered at the hands of VB.NET monkeys, and it amuses me that people would choose a language full of 'features' that lead to bad code, over a new language that doesn't have these issues. I come into this forum to help people ( I know enough about the .NET framework that often I can ). Sometimes, my attitude towards VB comes through in my responses, but I'm not here trolling or anything. rwestgraham wrote: Doe sthis provide some kind of "validation" or something? Not at all. I have my validaion, I've seen what
-
rwestgraham wrote: VB.NET class can fully implement the IDisposable interface. It is very simple to do. So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. rwestgraham wrote: The next section of your "complaints" are all deprecated features. I use structured error handling only in VB.NET. All languages contain "features" that can lead to poor practices. This is hardly unique to VB. Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. C++ has similar problems, for the same reason - C compatibility. That's where C# is better, it has no older language it needs to pander to. Name the 'features' unique to C# that can cause similar problems ? rwestgraham wrote: Writing multi-threaded code correctly requires advanced abilities that are beyond the skills of most programmers period Perhaps. So what ? rwestgraham wrote: Ignorance is by no means defined by using one language as opposed to another. Ignorance is ubiquitous, period. Did you read my comment ? I agree, and in C#/VB.NET the only dividing line is that most VB.NET programmers got there via VB6, which used to be the answer to the question 'what's the easiest way to write code for Windows'. The people coming to C# tend to be VB6 users who are real programmers ( not scared of a new language ), and people who come from C++, who asked 'what's the BEST way to write code for Windows'. rwestgraham wrote: If you don't want to use VB, don't use VB. I guess my real question is what do you get from constantly bashing VB? Initially, because VB6 was crap. Since then, I've sufered at the hands of VB.NET monkeys, and it amuses me that people would choose a language full of 'features' that lead to bad code, over a new language that doesn't have these issues. I come into this forum to help people ( I know enough about the .NET framework that often I can ). Sometimes, my attitude towards VB comes through in my responses, but I'm not here trolling or anything. rwestgraham wrote: Doe sthis provide some kind of "validation" or something? Not at all. I have my validaion, I've seen what
Normally, I'd just sit back watch the pretty fireworks... :) You're both really good at what you do. But in either case, I'm probably going to regret doing this... Christian Graus wrote: So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. Actually, we do have it, in 2005. A bunch of the language changes made for 2005 were to fill in the gaps and align the language features more with C#'s features. This in NO WAY means that I think C# is better than VB.NET or the other way around! Just because a language has some bad features doesn't mean you should get lazy and use them. In my view, there's no excuse for writing bad code because you didn't recognize a bad feature. If you don't keep up with modern features and practices, you shouldn't be writing code in the first place. I hate hearing these idiots (mostly MVP's too! :confused:) who demand that VB6 be supported because of the installed base of code! If you're an MVP in VB6, great! Go make some money supporting the old crap instead of upgrading it. Christian Graus wrote: Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. Damn complainers! :mad: Throw them some Depends before they piss themselves! I'm an old VB5/6 guy too, and I was soooooooooo happy when VB.NET came out with some real error handling. I don't use any of that old crap anymore. But, really, most of what you listed is deprecated crap that only the whiney idiots would use anyway. It's those idiots who refuse to upgrade their skills that are cranking out crappy code. Yes, I know what On Error Goto 0 and -1 mean, and HELL NO, I've never used them... Christian Graus wrote: You're barking up the wrong tree here. If I pursue a conversation like this, it's because I'm interested to see if any VBer can explain issues like magic return values ( you dodged that one ), and because it makes me laugh. I'll go a long way in search of a one liner. I love this one! "Magic return variables" have never caused me a problem. Either you understand that they're there and deal with them or you don't. In order to deal with them, you have to write proper code anyway. I for one, don't EVER leave a return va
-
Normally, I'd just sit back watch the pretty fireworks... :) You're both really good at what you do. But in either case, I'm probably going to regret doing this... Christian Graus wrote: So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. Actually, we do have it, in 2005. A bunch of the language changes made for 2005 were to fill in the gaps and align the language features more with C#'s features. This in NO WAY means that I think C# is better than VB.NET or the other way around! Just because a language has some bad features doesn't mean you should get lazy and use them. In my view, there's no excuse for writing bad code because you didn't recognize a bad feature. If you don't keep up with modern features and practices, you shouldn't be writing code in the first place. I hate hearing these idiots (mostly MVP's too! :confused:) who demand that VB6 be supported because of the installed base of code! If you're an MVP in VB6, great! Go make some money supporting the old crap instead of upgrading it. Christian Graus wrote: Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. Damn complainers! :mad: Throw them some Depends before they piss themselves! I'm an old VB5/6 guy too, and I was soooooooooo happy when VB.NET came out with some real error handling. I don't use any of that old crap anymore. But, really, most of what you listed is deprecated crap that only the whiney idiots would use anyway. It's those idiots who refuse to upgrade their skills that are cranking out crappy code. Yes, I know what On Error Goto 0 and -1 mean, and HELL NO, I've never used them... Christian Graus wrote: You're barking up the wrong tree here. If I pursue a conversation like this, it's because I'm interested to see if any VBer can explain issues like magic return values ( you dodged that one ), and because it makes me laugh. I'll go a long way in search of a one liner. I love this one! "Magic return variables" have never caused me a problem. Either you understand that they're there and deal with them or you don't. In order to deal with them, you have to write proper code anyway. I for one, don't EVER leave a return va
first of all, good discussion you had with CG, I enjoyed it a whole bunch! :-D Dave Kreskowiak wrote: "I for one, don't EVER leave a return value to chance, in any language. I've always used the Return statement and I've always set a default value as one of my first statements in my methods/functions." More often than not I take advantage of the fact that the VB compiler returns the default value of a function's return type in cases where one is not provided. Why you ask? Well, it's just handy on occasions, especially during the dreaded task of UI development, where my focus is just to program against an interface, forgetting about all the implementation behind that interface. I know all I have to do is just add that one line of code you say you always add, but I just don't even worry about that, rather I just define the interface I want to work against and implement it later. I'll admit I have experienced some debugging issues as a result of doing so; that's why I wish the compiler would treat the issue as a warning, but not an error. Also, another area where I heavily use this behavior is when creating "abstract base forms". I'm sure you know that the form designer requires that the base form have a parameterless public constructor; otherwise, it blows up. Well, then how do you create an abstract base form to be used with the form designer? Well, you can't, at least I haven't been able to. So what I do is just create a non abstract base form with a series of virtual methods that don't return anything rather raise an exception when called directly, the intent being that the derived form needs to override them so that any template methods work OK. Again, I know, I know, I should just add that one line of code you add, but what can I say, I just don't, and in this case, why should I? So really, I have to disagree with you and CG. CG says it's just straight out bad, you say it's OK but you make sure never to fall to it, I say it's OK always, but that compiler should give a warning. Finally, I once asked CG the same question, that is, what's his problem with VB. At first I just couldn't understand, but then I tried to put myself in his position of having to go through the painful task of having to work on shitty VB code and then his feelings seemed quite clear, although his famous words "VB.NET is crap" always make the hairs on my arms stand up in fury :mad:. Thanks for the discussion :-D
-
rwestgraham wrote: VB.NET class can fully implement the IDisposable interface. It is very simple to do. So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. rwestgraham wrote: The next section of your "complaints" are all deprecated features. I use structured error handling only in VB.NET. All languages contain "features" that can lead to poor practices. This is hardly unique to VB. Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. C++ has similar problems, for the same reason - C compatibility. That's where C# is better, it has no older language it needs to pander to. Name the 'features' unique to C# that can cause similar problems ? rwestgraham wrote: Writing multi-threaded code correctly requires advanced abilities that are beyond the skills of most programmers period Perhaps. So what ? rwestgraham wrote: Ignorance is by no means defined by using one language as opposed to another. Ignorance is ubiquitous, period. Did you read my comment ? I agree, and in C#/VB.NET the only dividing line is that most VB.NET programmers got there via VB6, which used to be the answer to the question 'what's the easiest way to write code for Windows'. The people coming to C# tend to be VB6 users who are real programmers ( not scared of a new language ), and people who come from C++, who asked 'what's the BEST way to write code for Windows'. rwestgraham wrote: If you don't want to use VB, don't use VB. I guess my real question is what do you get from constantly bashing VB? Initially, because VB6 was crap. Since then, I've sufered at the hands of VB.NET monkeys, and it amuses me that people would choose a language full of 'features' that lead to bad code, over a new language that doesn't have these issues. I come into this forum to help people ( I know enough about the .NET framework that often I can ). Sometimes, my attitude towards VB comes through in my responses, but I'm not here trolling or anything. rwestgraham wrote: Doe sthis provide some kind of "validation" or something? Not at all. I have my validaion, I've seen what
Christian Graus wrote: So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. It is not something you can't do in VB.NET. You simply implement the IDisposable interface. So VB.NET does not have a convenience that C# has. Big Deal. In either case, the same functionality is available. In VB.NET you can implement the code to explicitly close for example database connections, same as in C#. In C# you could easily overlook whether someone included the "using" key word. In VB.NET you could also overlook whether someone explicitly called Dispose. I see no difference. If anything the VB approach is clearer, because you explicitly call Dispose at the actual time the object is going out of scope. In C# you have to declare "using" when the object is created. In C# "using" can also refer to an alias for a namespace. But in VB.NET you only have one issue to look for: Did the code call Dispose when the object went out of scope? How can you really say this is a "feature" in C#? It is an opportunity to write confusing, bad code. VB.NET does not suffer from this "feature". It is quite clear what the code is doing - explicitly calling Dispose when the object goes out of scope. It is much more logical, much less prone to being overlooked. Christian Graus wrote: Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. It is the responsibility of the production teams to create and adhere to coding standards. Oner of those standards should be the use of structure error handling in VB.NET, which is the main area where a lot of deprecated features are still supported. The problem is not the presence of deprecated features. If the coding team does not have any coding standards, they will tend to produce shitty code, with or without deprecated features. Christian Graus wrote: If I pursue a conversation like this, it's because I'm interested to see if any VBer can explain issues like magic return values ( you dodged that one No you just did not bother to read my post other than to try to find areas to criticize. I provided a detailed explanation of why in practice the "magic return value" is a non-issue. I will not repeat myself.
-
Normally, I'd just sit back watch the pretty fireworks... :) You're both really good at what you do. But in either case, I'm probably going to regret doing this... Christian Graus wrote: So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. Actually, we do have it, in 2005. A bunch of the language changes made for 2005 were to fill in the gaps and align the language features more with C#'s features. This in NO WAY means that I think C# is better than VB.NET or the other way around! Just because a language has some bad features doesn't mean you should get lazy and use them. In my view, there's no excuse for writing bad code because you didn't recognize a bad feature. If you don't keep up with modern features and practices, you shouldn't be writing code in the first place. I hate hearing these idiots (mostly MVP's too! :confused:) who demand that VB6 be supported because of the installed base of code! If you're an MVP in VB6, great! Go make some money supporting the old crap instead of upgrading it. Christian Graus wrote: Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. Damn complainers! :mad: Throw them some Depends before they piss themselves! I'm an old VB5/6 guy too, and I was soooooooooo happy when VB.NET came out with some real error handling. I don't use any of that old crap anymore. But, really, most of what you listed is deprecated crap that only the whiney idiots would use anyway. It's those idiots who refuse to upgrade their skills that are cranking out crappy code. Yes, I know what On Error Goto 0 and -1 mean, and HELL NO, I've never used them... Christian Graus wrote: You're barking up the wrong tree here. If I pursue a conversation like this, it's because I'm interested to see if any VBer can explain issues like magic return values ( you dodged that one ), and because it makes me laugh. I'll go a long way in search of a one liner. I love this one! "Magic return variables" have never caused me a problem. Either you understand that they're there and deal with them or you don't. In order to deal with them, you have to write proper code anyway. I for one, don't EVER leave a return va
Dave Kreskowiak wrote: Just because a language has some bad features doesn't mean you should get lazy and use them. In my view, there's no excuse for writing bad code because you didn't recognize a bad feature. I agree. My point is that, in general, there are more people in VB land that are likely to use bad features, and C# is better *because* the bad features are not there. I've written good VB code, but I had to do it by building on VERY bads VB code, worse code than it would be possible to write in C#. Dave Kreskowiak wrote: It's those idiots who refuse to upgrade their skills that are cranking out crappy code. And in a world where you inherit projects from other people, the availability of those 'idiot features' are where the problem lies. Dave Kreskowiak wrote: I for one, don't EVER leave a return value to chance, in any language. I would also set a default return value in the first line of code. But it's just one more thing to keep in mind when you're trying to figure out why someone elses code just plain doesn't work. And it's stupid. Dave Kreskowiak wrote: In my humble opinion, code is code, good or bad. It doesn't matter what language it's written in. As a universal law, no matter how perfect, or bad, you think any language is, the universe will always generate an idiot, to use it the wrong way. I agree, totally. However, it's my experience that the universe generates more VB idiots, that code I've had to build on in VB is invariably terrible, code I've had to build on in C# and C++ is usually pretty decent. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Christian Graus wrote: So I *did* tell you something you can't do in C# ? It's sad, b/c I trust a C# programmer to dispose an object more than a VB programmer. The using keyword makes for nice code. You don't have it. Question answered. It is not something you can't do in VB.NET. You simply implement the IDisposable interface. So VB.NET does not have a convenience that C# has. Big Deal. In either case, the same functionality is available. In VB.NET you can implement the code to explicitly close for example database connections, same as in C#. In C# you could easily overlook whether someone included the "using" key word. In VB.NET you could also overlook whether someone explicitly called Dispose. I see no difference. If anything the VB approach is clearer, because you explicitly call Dispose at the actual time the object is going out of scope. In C# you have to declare "using" when the object is created. In C# "using" can also refer to an alias for a namespace. But in VB.NET you only have one issue to look for: Did the code call Dispose when the object went out of scope? How can you really say this is a "feature" in C#? It is an opportunity to write confusing, bad code. VB.NET does not suffer from this "feature". It is quite clear what the code is doing - explicitly calling Dispose when the object goes out of scope. It is much more logical, much less prone to being overlooked. Christian Graus wrote: Deprecated features that by and large are in VB because the VB6 crowd complained. Deprecated stuff that is in use today, I've seen he production code, on new VB.NET projects. It is the responsibility of the production teams to create and adhere to coding standards. Oner of those standards should be the use of structure error handling in VB.NET, which is the main area where a lot of deprecated features are still supported. The problem is not the presence of deprecated features. If the coding team does not have any coding standards, they will tend to produce shitty code, with or without deprecated features. Christian Graus wrote: If I pursue a conversation like this, it's because I'm interested to see if any VBer can explain issues like magic return values ( you dodged that one No you just did not bother to read my post other than to try to find areas to criticize. I provided a detailed explanation of why in practice the "magic return value" is a non-issue. I will not repeat myself.
rwestgraham wrote: If anything the VB approach is clearer, because you explicitly call Dispose at the actual time the object is going out of scope. In C# you have to declare "using" when the object is created. In C# "using" can also refer to an alias for a namespace. You're wrong. In C#, I can impliment IDisposable and call it myself. The using keyword is a piece of syntactic sugar ( as so much of C# seems to be ), that just happens to lower the risk, because you essentially declare that an item will need disposing at the moment you create it. rwestgraham wrote: I provided a detailed explanation of why in practice the "magic return value" is a non-issue. I went back and looked for it. I didn't see anything that wasn't crap. ANY bad feature is not a problem if the language is used competently. The stars have just aligned so that one language has more bad features than any other, and more incompetent users also. Do you ever have to work on other people VB code ? If so, you'll know what I mean. rwestgraham wrote: Sorry, but most of your reasons have been your opinion that all VB coders produce bad code. Sorry, but you can't accuse me of not reading what you say, and then come out with this. MOST VB programmers DO produce bad code. I've seen it. Most is a long was from all. rwestgraham wrote: It means I can quickly scan through a form's code and see what is doing what, because those End If and End Sub statements that you consider to be the hallmark of first grader's coding are in fact much easier to read than a page full of braces. I can't believe anyone who can read C++ would make such a claim. It's intolerably hard to read. I prefer this brace style if (VB == crap) { useCSharp(); } and with this style, the indenting and the lining up of braces makes it crystal clear what is going on. rwestgraham wrote: C# at least provides a structured IDE for coding. But spend a little time trying debug someone else's JavaScript code and you will quickly come to despise the brace syntax. LOL - someone else's code is always the problem. That's my point, too :-) rwestgraham wrote: Maybe I have a personal bias against C# because instead of pandering to a previous version, it panders to J programmers, which I generally despise. Who does it pander to ? Do you mean JScript, or J++, or what ? I admit, it l
-
rwestgraham wrote: If anything the VB approach is clearer, because you explicitly call Dispose at the actual time the object is going out of scope. In C# you have to declare "using" when the object is created. In C# "using" can also refer to an alias for a namespace. You're wrong. In C#, I can impliment IDisposable and call it myself. The using keyword is a piece of syntactic sugar ( as so much of C# seems to be ), that just happens to lower the risk, because you essentially declare that an item will need disposing at the moment you create it. rwestgraham wrote: I provided a detailed explanation of why in practice the "magic return value" is a non-issue. I went back and looked for it. I didn't see anything that wasn't crap. ANY bad feature is not a problem if the language is used competently. The stars have just aligned so that one language has more bad features than any other, and more incompetent users also. Do you ever have to work on other people VB code ? If so, you'll know what I mean. rwestgraham wrote: Sorry, but most of your reasons have been your opinion that all VB coders produce bad code. Sorry, but you can't accuse me of not reading what you say, and then come out with this. MOST VB programmers DO produce bad code. I've seen it. Most is a long was from all. rwestgraham wrote: It means I can quickly scan through a form's code and see what is doing what, because those End If and End Sub statements that you consider to be the hallmark of first grader's coding are in fact much easier to read than a page full of braces. I can't believe anyone who can read C++ would make such a claim. It's intolerably hard to read. I prefer this brace style if (VB == crap) { useCSharp(); } and with this style, the indenting and the lining up of braces makes it crystal clear what is going on. rwestgraham wrote: C# at least provides a structured IDE for coding. But spend a little time trying debug someone else's JavaScript code and you will quickly come to despise the brace syntax. LOL - someone else's code is always the problem. That's my point, too :-) rwestgraham wrote: Maybe I have a personal bias against C# because instead of pandering to a previous version, it panders to J programmers, which I generally despise. Who does it pander to ? Do you mean JScript, or J++, or what ? I admit, it l
Christian Graus wrote: You're wrong. In C#, I can impliment IDisposable and call it myself. The using keyword is a piece of syntactic sugar ( as so much of C# seems to be ), that just happens to lower the risk, because you essentially declare that an item will need disposing at the moment you create it. I can implement IDisposable In VB.NET and call it myself too. You've yet to justify your argument that this is a functionality that C# provides that is not available in VB.NET. Christian Graus wrote: I went back and looked for it. I didn't see anything that wasn't crap. No surprise there. It was an item from your list, not something you've actually used and understand anything about. As for the rest of your statements, those are your opinions and your preferences. I'd rather have to try to figure out someone else's bad VB code than someone else's bad C++ code anyday. Christian Graus wrote: I admit, it looks a hell of a lot like Java, which I for one can't figure out. It's no mystery. All C# really is: A Java like langauge because Microsoft wants to attract Java programmers and encourage them to use C#. C# is not some great advance in programming languages. C#, VB.NET - it's all NET. Same framework, same code that ultimately runs on the machine, just different coding syntax (and not that different. I can easily translate code from VB To C# and back the other way, because they are really essentially the same platform.) C++ is a different animal. But realistically VB.NET and C# are for most practical purposes one platform. If I need power programming I cannot get from VB.NET I switch to C++, not C# because I already know that I cannot really do anything in C# that I cannot do in VB.NET. Sorry if you like to believe differently, but there really is little difference between the two. Robert
-
Christian Graus wrote: You're wrong. In C#, I can impliment IDisposable and call it myself. The using keyword is a piece of syntactic sugar ( as so much of C# seems to be ), that just happens to lower the risk, because you essentially declare that an item will need disposing at the moment you create it. I can implement IDisposable In VB.NET and call it myself too. You've yet to justify your argument that this is a functionality that C# provides that is not available in VB.NET. Christian Graus wrote: I went back and looked for it. I didn't see anything that wasn't crap. No surprise there. It was an item from your list, not something you've actually used and understand anything about. As for the rest of your statements, those are your opinions and your preferences. I'd rather have to try to figure out someone else's bad VB code than someone else's bad C++ code anyday. Christian Graus wrote: I admit, it looks a hell of a lot like Java, which I for one can't figure out. It's no mystery. All C# really is: A Java like langauge because Microsoft wants to attract Java programmers and encourage them to use C#. C# is not some great advance in programming languages. C#, VB.NET - it's all NET. Same framework, same code that ultimately runs on the machine, just different coding syntax (and not that different. I can easily translate code from VB To C# and back the other way, because they are really essentially the same platform.) C++ is a different animal. But realistically VB.NET and C# are for most practical purposes one platform. If I need power programming I cannot get from VB.NET I switch to C++, not C# because I already know that I cannot really do anything in C# that I cannot do in VB.NET. Sorry if you like to believe differently, but there really is little difference between the two. Robert
rwestgraham wrote: I can implement IDisposable In VB.NET and call it myself too. You've yet to justify your argument that this is a functionality that C# provides that is not available in VB.NET. That's because you're being obtuse. I've made my position clear. Seriously, do you really not get it ? VB programmers are by and large clueless when it comes to issues like memory management, and so a syntax that doesn't require them to remember to clean up after themselves is more useful to VB than it is to C#, but only C# has it. rwestgraham wrote: No surprise there. It was an item from your list, not something you've actually used and understand anything about. Wrong. I've used VB.NET, and I've seen plenty of code that relies on magic return values. rwestgraham wrote: I'd rather have to try to figure out someone else's bad VB code than someone else's bad C++ code anyday. Perhaps. How does that change the fact that in my real world experience, the VB code is far more likely to be terrible ? Here's a for instance. You're asked to quote on extending a website, but you can't see the source code first. You quote, based on the assumption that the project is well laid out. It arrives, it's in VB.NET, and it's a total disaster, there is obviously no grasp of even the most basic software engineering principles in the past of this project. Your workload doubles, because you're having to do things in multiple places, and you're trying to refactor as well to make the code a bit easier to work on. This has happened to me several times in VB.NET, never in C#. rwestgraham wrote: All C# really is: A Java like langauge because Microsoft wants to attract Java programmers and encourage them to use C#. That's a bit of an over simpliciation, I think, but it has a grain of truth to it. They marketed it as an evolution of C++ more than anything though. rwestgraham wrote: C# is not some great advance in programming languages. I never said it was. Without ASP.NET, I'd regard it as a solution looking for a problem. rwestgraham wrote: C#, VB.NET - it's all NET. Yeah, and it's all 1's and 0's at the end of the day. Anything else is just frameworks to manage complexity and help humans get it right. rwestgraham wrote: If I need power programming I cannot get from VB.NET I switch to C++, not C# bec
-
rwestgraham wrote: I can implement IDisposable In VB.NET and call it myself too. You've yet to justify your argument that this is a functionality that C# provides that is not available in VB.NET. That's because you're being obtuse. I've made my position clear. Seriously, do you really not get it ? VB programmers are by and large clueless when it comes to issues like memory management, and so a syntax that doesn't require them to remember to clean up after themselves is more useful to VB than it is to C#, but only C# has it. rwestgraham wrote: No surprise there. It was an item from your list, not something you've actually used and understand anything about. Wrong. I've used VB.NET, and I've seen plenty of code that relies on magic return values. rwestgraham wrote: I'd rather have to try to figure out someone else's bad VB code than someone else's bad C++ code anyday. Perhaps. How does that change the fact that in my real world experience, the VB code is far more likely to be terrible ? Here's a for instance. You're asked to quote on extending a website, but you can't see the source code first. You quote, based on the assumption that the project is well laid out. It arrives, it's in VB.NET, and it's a total disaster, there is obviously no grasp of even the most basic software engineering principles in the past of this project. Your workload doubles, because you're having to do things in multiple places, and you're trying to refactor as well to make the code a bit easier to work on. This has happened to me several times in VB.NET, never in C#. rwestgraham wrote: All C# really is: A Java like langauge because Microsoft wants to attract Java programmers and encourage them to use C#. That's a bit of an over simpliciation, I think, but it has a grain of truth to it. They marketed it as an evolution of C++ more than anything though. rwestgraham wrote: C# is not some great advance in programming languages. I never said it was. Without ASP.NET, I'd regard it as a solution looking for a problem. rwestgraham wrote: C#, VB.NET - it's all NET. Yeah, and it's all 1's and 0's at the end of the day. Anything else is just frameworks to manage complexity and help humans get it right. rwestgraham wrote: If I need power programming I cannot get from VB.NET I switch to C++, not C# bec
Well, poorly written legacy code is an opportunity to get work. :-) The language it was written in is usually the least important consideration to me personally. I have three questions about any project: 1) Is there legacy code involved? 2) Was it written offshore? 3) What language is it in? There are much worse evils out there than VB itself. Robert :-)