|
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 meant to be "a productive language?"
13. REM. It'd be fun seeing a program entirely commented using exclusively REM.
14. "Array Covariance". I'm yet to know a VB programmer who can tell me what's this (BTW, I know).
15. The "Like" operator. The syntax is incompatible with the .NET Regex syntax. Answer quickly: should "x**y" match "xy" and "xay"? The answer is none. Can you explain why?
16. The "Concatenation Operator". Quoting MSDN: 'Also, there is a special case in that Nothing is treated in concatenation expressions as if it were the empty string literal ""'
17. I'm yet to find a VB programmer who can declare a char constant.
18. x!abc. Aka x("abc")
19. Copy-in/copy-out semantics when passing an argument passed to a reference parameter and the argument needs to be coerced to the right type. It sounds complicated, huh? Don't worry about, unless you're using multithreaded code.
rwestgraham wrote:
Face it. 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.
Actually, VB.NET -> C# converters are commercial products, so there's more to it than that. Even then, they tend to import the VisualBasic namespace and use stuff like the excrable Iif, instead of ()?: syntax. I have a major project that I won on the basis that I could convert it to C# from VB.NET. It took a half day with a commerical converter, and then hand fixing all the references to the VB namespace. I've also worked on several VB.NET web sites that had been begun by other people. These experiences confirmed what I suspected all along - the basic problem with VB is that most people who use it should not be let near a program of more than about 50 lines, they just have no idea about structure, design, or anything else. The website I worked on had stored procedures in the database, and DB calls in the middle and web tiers. Many methods were generated more than once, nothing was done efficiently, etc.
Yes, some people in VB can code, many people using C++ cannot. However, the VB people who are ignorant generally can get something that looks good enough to ship, and therein lies the danger.
The basic problem with VB.NET is that it was modified to keep the VB6 crowd happy, and that it bears the name of a 'language' whose name is beyond redemption, both because of bad design, and because of a high percentage of ignorant users.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
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 correctly requires advanced abilities that are beyond the skills of most programmers period. The first rule of multi-threaded code is that generally MT is not neccessary or advantageous, and often the drawbacks far outweight the advantages. I've written MT programs (in VB, wow what a concept) for IVR programs where you were requyired to support multiple callers on channels asynchronously. I've also written MT code in real time data collection systems for nuclear power plant instrumentation systems. Those are specialized applications. Anyone who is experienced in MT will tell you gthe first rule is "Don't MT in general". It is not a skill that most programmers really need to acquire in the first place.
etc, etc.
Ignorance is by no means defined by using one language as opposed to another. Ignorance is ubiquitous, period.
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? Doe sthis provide some kind of "validation" or something? Focus on writing really good code in whatever platform you prefer, and that should fill any sort of "validation" void you seem to feel.
Being a "C# programmer" seems to lead to some imaginary feeling of superiority over a "VB.NET programmer". It's all stereotypical and delusional. A good programmer is a good programmer, and that should provide enough personal satisfaction to eliminate the need to actively seek out opportunities to express some imaginary superiority over other programmers simply because they choose to use a different platform. 
Robert
|
|
|
|
|
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 sort of code the VB side of the world churns out.
rwestgraham wrote:
Focus on writing really good code in whatever platform you prefer, and that should fill any sort of "validation" void you seem to feel.
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.
rwestgraham wrote:
Being a "C# programmer" seems to lead to some imaginary feeling of superiority over a "VB.NET programmer".
No, it means I'm using the best tool for the job. That's all. There are bad C# coders, and good VB coders. The bad VB coders ( i.e. the majority ) would actually be better off in C#, where ( for example ) the using keyword makes it less likely they will leak memory, or the error raised when they don't return a value in one control path doesn't become a nightmare to debug, because it compiles and returns a magic value.
rwestgraham wrote:
A good programmer is a good programmer, and that should provide enough personal satisfaction to eliminate the need to actively seek out opportunities to express some imaginary superiority over other programmers simply because they choose to use a different platform.
Hey, if you write good code in VB, good for you. You're choosing to drag your own name down by associating yourself with a language that's responsible for a world of crappy code. You're also bypassing the Microsot fast lane, and choosing to make things hard for yourself in regards to the issues I already raised. I have more than enough work, even though I refuse VB work ( or I offer to convert to C#, as I've done a number of times now, and fixed the rest of the code over time ). The few who knock me back are just more work for you, but I definately prefer a language that understands things like not evaluating both sides of an or statement if the first is false ( yes, I know that can be done now, why could it not before ? ). On a personal level, VB's verbosity makes it look like the coding equivelant of See Spot Run, but that's just me. That's certainly not why I hate VB as much as I do, I hate it because it's given incompetent people a fast track to writing terrible code, and I really don't comprehend why anyone who has any idea about programming would choose to be slurred by it, when C# is better for all the reasons I stated.
So why do you use VB.NET instead of C# ? Was it just comfortable for you ? You said you use C++, don't you find the VB synax annoying ? Does it really feel like programming to you ?
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
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!  ) 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!  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 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.
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.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
first of all, good discussion you had with CG, I enjoyed it a whole bunch! 
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 sh*tty 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 .
Thanks for the discussion
|
|
|
|
|
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 sh*tty 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. You can re-read my original post.
Christian Graus wrote:
On a personal level, VB's verbosity makes it look like the coding equivelant of See Spot Run, but that's just me. ...when C# is better for all the reasons I stated.
Sorry, but most of your reasons have been your opinion that all VB coders produce bad code.
Christian Graus wrote:
So why do you use VB.NET instead of C# ? Was it just comfortable for you ? You said you use C++, don't you find the VB synax annoying ? Does it really feel like programming to you ?
In C++ I am programming objects, and the code should be clear.
In VB.NET I tend to be programming GUIs which have a lot of code and event handlers. I don't have a personal bias against the See Spot Run syntax. The See Spot Run syntax you seem to dislike is an advantage in my opinion. 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.
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.
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.
Robert
|
|
|
|
|
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 looks a hell of a lot like Java, which I for one can't figure out.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
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# because I already know that I cannot really do anything in C# that I cannot do in VB.NET.
Sure - I do the same with C# and C++. It's the same end result, but by adopting a C# only policy, I get to work on better quality legacy code, when I work on legacy code at all.
rwestgraham wrote:
Sorry if you like to believe differently, but there really is little difference between the two.
You are deliberately choosing to ignore the differences that I keep pointing out. Yes, they both compile to IL. I've heard it said that C# is faster, but I choose to disregard that, if I need speed, I need C++. But VB.NET has more idiot programmers, and more ways for them to shoot themselves ( and later me, if I need to maintain their code ) in the foot.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
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
|
|
|
|
|
There is a thread in this forum on creating autocomplete for a simple textbox on a form. However, I am attempting to use autocomplete in a ComboBoxColumn on a datagrid and cannot figure out which event to trap. I thought it was the KeyUp event but I noticed that VB.NET plugs in a NoKeyUpCombo code as part of the syntax for adding dynamic comboboxes in the datagrid. Has anyone ever attempted this functionality and do you have any code supporting your attempt? Do I need to disable the NoKeyUpCombo code to make it work? Here is a snippet of my code:
#Region " Constructor "
Public Sub New()
mcmSource = Nothing
mblnEditing = False
ColumnComboBox = New NoKeyUpCombo()
ColumnComboBox.DropDownStyle = ComboBoxStyle.DropDownList
AddHandler ColumnComboBox.Leave, AddressOf LeaveComboBox
AddHandler ColumnComboBox.SelectionChangeCommitted, AddressOf ComboStartEditing
End Sub
#End Region
Select Case i
Case 3 'Use a combobox for the Test Type.
Dim ComboTextCol As New DataGridComboBoxColumn
With ComboTextCol
.MappingName = "TestTypeID"
.HeaderText = "Test Type"
.Width = 100
.ColumnComboBox.DataSource = ds1frmDataEntry.Tables("PUATTestType").DefaultView
.ColumnComboBox.DisplayMember = "TestType"
.ColumnComboBox.ValueMember = "ID
.NullText = ""
tableStyle.PreferredRowHeight = .ColumnComboBox.Height
tableStyle.GridColumnStyles.Add(ComboTextCol)
End With
Case 5 'Use a combobox for the County.
Dim ComboTextCol As New DataGridComboBoxColumn
With ComboTextCol
.MappingName = "CountyID"
.HeaderText = "County"
.Width = 100
.ColumnComboBox.DataSource = ds1frmDataEntry.Tables("County").DefaultView
.ColumnComboBox.DisplayMember = "CountyName"
.ColumnComboBox.ValueMember = "CountyID"
.NullText = ""
tableStyle.PreferredRowHeight = .ColumnComboBox.Height
tableStyle.GridColumnStyles.Add(ComboTextCol)
End With
|
|
|
|
|
I have coded a combo box to auto complete based on a collection of names that I load. The combo box is working great in Windows XP, but when we run the same application in NT the events for the combo box don't seem to all work. Are there some events that do not work in NT but work on 2000 / XP? If so is there a compatibility list somewhere that we can refer to?
Any help or feedback is appreciated.
Lost in the vast sea of .NET
<a href="http://www.komputing.com/Pricelist.html">Visit my website at www.komputing.com</a>
|
|
|
|
|
No, all event should be working without any problems. Is the NT machine running NT 4.0 Service Pack 6a? Is the .NET Framework installed on this box the same version as the one the app was developed on? Any .NET Framework Service Packs installed on one, but not the other?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Yes, we've actually double checked the framework service packs and they are the same as the XP machine. The NT image is 4.0 SP6a with framework 1.1 and all the patches.
I've actually created a textbox where I write debug messages to and I can see how in XP the events fire in a different order than they do in NT. I've started an MSDN call to see if I can narrrow down why. 
Lost in the vast sea of .NET
<a href="http://www.komputing.com/Pricelist.html">Visit my website at www.komputing.com</a>
|
|
|
|
|
Wierd!
Good Luck! Let us know what MS comes up with!
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Microsoft has been working with us for a few days with the MSDN call. The information that has come out of their research is that service pack 6a along with framework 1.1 and the patch for 1.1 is not enough. The version of user32.dll (which contains the win32 ComboBox) is not up to date to function correctly. Microsoft’s security patch Q834852 (http://support.microsoft.com/default.aspx?scid=kb;en-us;834852 ) updates the user32.dll to correct the problem.
I'm not sure why a security patch fixes combobox functionality, but I guess the moral of the story is that ALL security patches need to be applied when testing a VB application.
What was wierd was that our application did not work on the NT system we created, but when we installed Office 2000 the VB application worked. Office 2000 updated the user32.dll. We worked with Microsoft to find a solution, other than installing Office, to make our VB app function correctly. The security patch is what they recommended.
Lost in the vast sea of .NET
<a href="http://www.komputing.com/Pricelist.html">Visit my website at www.komputing.com</a>
|
|
|
|
|
The controls are not specific to VB.NET. Most of the controls you find in the ToolBox are .NET managed code wrappers around the actual controls built into Windows. That's why the controls can look the same from application to application. If you used C# to write your app, the same thing would have happened.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi guys Im really really stuck with this and I need sum help
basically I want the track bar linked to the sound I dowloaded wen the sound is downloaded I can use the track bar to go a spefic point in the song how do I do this
Dim OpenFile As New OpenFileDialog()
' Configure the dialog
With OpenFile
.InitialDirectory = "G:\"
.Filter = "MP3 Files (*.mp3)/*.mp3/
.CheckFileExists = True
' Open the dialog
If .ShowDialog = DialogResult.OK Then
PlayMCI(.FileName)
End If
End With
End Sub
|
|
|
|
|
Not enough information. How are you playing the file? Are you using the Multimedia MCI control? P/Invoking functions directly? Which ones? ...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi AndyYie This is how I have decalred MCI sound
End Function
Public Function PlayMCI(ByVal filename As String, Optional ByVal ShowMsg As Boolean = False) As Boolean
If SoundFormat(filename) <> "NotSoundFile" Then
' close any previous commands that have opened the media
mciSendString("Close all", 0, 0, 0)
' and create the string which will open the new one
mciSendString("Open " & Chr(34) & filename & Chr(34) & " Type " & SoundFormat(filename) & _
" Alias Med", 0, 0, 0)
' Playthe(File)
mciSendString("Play Med", 0, 0, 0)
mciSendString("MCI_RECORD", 0, 0, 0)
End If
End Function ' Play MCI
Private Function SoundFormat(ByVal FullPath As String) As String
Dim Sound As New FileInfo(FullPath)
Dim FileExt As String = Sound.Extension.ToLower
Select Case FileExt
Case ".wav"
Return "Waveaudio"
Case ".mid"
Return "Sequencer"
Case ".mp3"
Return "MPEGVideo"
Case ".mpg"
Return "CDAudio"
Case ".wma"
Return "MPEGVideo"
Case ".mpeg"
Return "Windows Media Player"
Case Else
Return "NotSoundFile"
End Select
End Function ' SoundFormat
Hope this helps you to understand what Im doing
|
|
|
|
|
I've never gone through the MCI API functions, but it looks like you can probably get away with using the MCI Command STATUS WAVEAUDIO LENGTH to get the length of the media file. Use that as the maximum value for the TrackBar. You'll probably have to do some translating to get the time returned by STATUS into a more usable format, like converting the total time to total seconds.
In order to get the current position of the playback, you'll need to setup a timer and poll for the position status using the STATUS WAVEAUDIO POSITION command. This too will be returns in a time format. Convert it to seconds as before and you can use that to update the position of the TrackBar.
Same thing with seeking with the TrackBar. Convert the number of seconds returned by the position of the TrackBar into the appropriate time format, then use the SEEK WAVEAUDIO TO POSITION command to control where in the file to resume playing.
Sorry, I don't have any example code, 'cause liek I said, never played with it before.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Thanks Dave
Dnt wanna be a pain but I was wondering if you can give me a vb.net example of what you mean tat way I can understand it better
|
|
|
|
|
Hi David
What Ive managed to is. Thiis at the moment does nothing but when I fiddle with the trackBar a little noice disturbance is caused....
TrackBar1.Maximum = 100
TrackBar1.Minimum = 0
TrackBar1.TickFrequency = (mciSendString("Play Med", 0, 0, 0))
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
