is there an advantage (vb.net vs c#)

[mookie]

i havent tried c# yet but i know its similar. i ddint know if there was an advantage to using it over vb

[snarfblam]

The biggest difference is the syntax. C# is C style syntax and VB.Net is... well... what it is. People who are used to java, php, c++, c, half of everything out there, will prefer C# syntax.

 

The other differences: I don't know them all. I almost always use VB. I know that C# includes unsafe code, which allows you to use pointers. It has strict type checking, like option strict always being on (which most C# users and probably even most VB users think of as a good thing). I can't think of any other differences off the top of my head, but someone else will probably fill you in.

[Mike_R]

I code only in VB.Net due to the fact that I work with MS Excel. The MS Office Apps all utilize VBA natively, and works pretty well with VB.Net. C# does work with MS Office, but the coding is pretty ugly. :(

 

That said, I think it's well worth learning C#, at least being good enough to read it. I just find it advantageous to be able to read C# code then I see it being discussed. I also have some C# books and although I usually read VB.Net, some topics I'll switch to the C# book to get another perspective.

 

My point is that adding some modest C# ability is a not a bad thing. If you want to persue this route, I would get a good intro C# book. I personally think that Jesse Liberty's "Programming C#" is just a fantastic book. I'd go with that.

 

I would not drop any money on a C# IDE. You should probably check out #Develop or download MSFT's C# 2005 Beta. I don't have personal experience with #Develop, but it does have a good reputation, I believe. I use the C# 2005 Beta and find it excellent.

 

Guys like you are me are not likely to flip over to C# completely. (Well, actually, I would really consider it, but my VBA use makes it kind of impossible for me.) If by reading a C# book over time and experimenting with the C# Beta (or #Develop's IDE) then, well, of course you may reach the day when you say, "wow, you know what, I think I prefer C#!". But that will take a while...

 

I think it's easiest/best to master VB.Net and then switch over later, not earlier. But having a good C# book and a free C# IDE to be able to kick around some code can still a very good thing to have in the mean time...

 

-- Mike

Edited February 28, 2005 by Mike_R

[coldfusion244]

I know that C# includes unsafe code' date=' which allows you to use pointers.[/quote']

 

It has pointers... kinda... you first have to mark the code as unsafe. Then you have to tell the compilier to not choke on unsafe marked code. Finally you can only use pointers that are of intrinsic types to C#. That means if you make a class of... say... humans, you cannot make a pointer of type human. If you want speed and pointers, go C++.

 

As mentioned before, you learn the syntax to other common languages such as c,c++,php, etc. As for speed, etc, it's all MSIL, so that really wouldn't play a role. As for DirectX programming, I know TPG has commented a few times on how it's easier to use C# for DX programming. That's all i know...

[snarfblam]

I wasn't trying to imply that c# had the same pointer funtionability as c++ but I suppose that I should have mentioned that. I also should have mentioned the speed issue, but I'm tired, its 12:30 at night. Glad you cleared it up for anyone who reads this thread.

[Tygur]

VB is crippled. I like it, but it just feels more dumbed down than it has to be. For example, it stubbornly refuses to deal with unsigned types, while C# doesn't have a problem with them at all.

[Mike_R]

Oh no, let's not start a flame war about this... if we want to we can do that in a separate thread. I think that Mookie just needs some advice here, really.

 

Switching over to a language just so that you can use Unsigned types really isn't a good enough reason, honest.

[Tygur]

Oh no, let's not start a flame war about this... if we want to we can do that in a separate thread. I think that Mookie just needs some advice here, really.

 

Switching over to a language just so that you can use Unsigned types really isn't a good enough reason, honest.

I didn't think I was starting a flame war. I was just stating my opinion. The unsigned types was just an example. I said I liked VB.NET. I use it all the time. It just feels dumbed down to me. Sometimes, when I feel like it, I'll switch over to C#, and I might even later switch back to VB.NET. It depends on my mood and what i'm doing.

[Mike_R]

Sure no prob... I was just worried, with a thread like this it can head that way fast. :(

 

To say that "VB is crippled" is just completely innacurate. "Feels dumbed down" is fair enough, I guess. C#'s syntax is its greatest asset: terse, concise.

[Tygur]

Sure no prob... I was just worried, with a thread like this it can head that way fast. :(

 

To say that "VB is crippled" is just completely innacurate. "Feels dumbed down" is fair enough, I guess. C#'s syntax is its greatest asset: terse, concise.

Well, in my opinion, its refusal to deal with unsigned types does cripple it. There's just no reason to have such a restriction. The .NET Framework on which it's built handles them just fine. There are other things I don't like too, but that's all that comes to mind right now. There used to be no bit-shifting operator, but that was fixed in VB.NET 2003.

[Mike_R]

Unsigned Types are not CLS-Compliant, and VB.Net is designed to only create verifiably-safe code. This is the reason for the restriction. (They're fine if use Privately, however, so I can see your point...)

 

We could go at this hammer-and-tongs, but I think that such a "discussion" is probably best in Random Thoughts... not in General where someone is just looking for some appropriate help/advice on the topic...

Edited February 28, 2005 by Mike_R

[Tygur]

Unsigned Types are not CLS-Compliant' date=' and VB.Net is designed to only create verifiably-safe code. This is the reason for the restriction. (They're fine if use Privately, however, so I can see your point...)[/quote']

I'm sorry. I can't help commenting here. It looks to me like the reason why they aren't CLS Compliant is just because they aren't supported by VB, and not the other way around.

 

The whole purpose of CLS Compliance is to allow your code to be accessed by more languages. The rules are designed to be more restrictive so more languages can work with the code. For example, names that only differ in case (upper or lower) aren't CLS Compliant, because certain languages (VB.NET) can't handle that. That's why it doesn't matter what you do privately. Other languages can't access that anyway. If VB.NET is designed only for CLS Compliant code, then that means it's only designed to have the absolutely most common features (meaning only features everyone else has), which is even worse than I thought. In that case, I'd better jump off while I still can.

[thenerd]

Aren't both languaged compiled the same way or something that makes them able to do the exact same things?

[Tygur]

Aren't both languaged compiled the same way or something that makes them able to do the exact same things?

Well, they both compile to the same IL Code, but you're still limited by language features. While the .NET Framework won't choke if you declare two public members of a class and call them SomeThing and SOMETHING (notice that they differ only in case), VB.NET will still have problems with it.

[snarfblam]

As far as Cls compliance goes, vb.net does have jagged arrays and perhaps some other non cls-compliant features. Perhaps the unsigned integers were not implemented in vb.net is because 99.99% of users will never need or want unsigned integers. Well... honestly I have found myself irratated by the lack of support for unsigned integers, but I achieved what I wanted easily enough without them.

 

The features left out of VB.Net never stop you from doing what you want to do and at worst they usually only make it a little more difficult, and for a lot of people their project on a whole will be easier because the syntax is meant to be easier.

 

Things like this should not be a deciding factor between languages. It does not cripple a language. These features are left out because they dont need to be there. They arent necessary. And microsoft has a sometimes unfortunate tendancy to leave advanced features out that they think will only confuse VB users.

 

Mookie, if you stick with VB, im sure you'll find a way to manage without unsafe code and (gasp!) unsigned integers.

[Mike_R]

C# advantages: (1) Terse/concise language, (2) Use of Pointers in certain situations is useful. (3) The Ref/Out parameter enforced within both the Procedure and within the Caller is a very nice mechanism that I wish VB.Net had. (4) The Using Block is also nice (even if infrequently used) and is also unavailable in VB.Net. (5) Use of Unsigned Types, although, I don't really know why/where they are useful, myself, to be honest.

 

However, Tygur, allowing C# (or any language) to be able to distinguish variable or procedure names by case is just an accident waiting to happen. Naming Convention guidelines always regard it as a huge no-no to name two variables, two procedures or a procedure-variable pairing the same, differing only by case. So why not simply enforce this at compile time? It's a nice error-catcher, believe me.

 

I personally think that C# had a real opportunity here to break from C/C++ tradition and blew it. IntelliSense in the C# 2003 is badly hampered by this. For example, if you type "messagebox." you will get no IntelliSense. Nor for "Messagebox." You need to type the case exactly correct: "MessageBox." and then you'll get the drop-down. No hassles like this in VB.Net. (Note this is corrected in C# 2005.)

 

The biggest advantage that VB.Net has is that the IDE is vastly superior in the 2003 version. I don't have experience with #Develop, so maybe it's different there, but I view the VS C# 2003 IDE as almost completely crippled.

 

That said, this difference is narrowing substantially in the 2005 version. Many of the differences between C# and VB.Net are going away, but the biggest improvement for C# is the IDE. The C# 2005 IDE is almost as good as the VB.Net 2003 version. It's still "lags" a bit on keeping the Task Manager errors in synch, but it's almost right... I think they'll probably make sure that they get it to 100% at VB.Net's level before releasing it as a final version.

 

VB.Net's advantages over C# are many, and I think that C# programmers would be shocked to know how much better some things are in "VB Land":

 

(1) It's a non-case sensitive language, so spelling conflicts are resolved at compile-time.

 

(2) Has a built in WithEvents/Handles mechanism that is significantly better than simple AddHandler. In short, it is a bi-directional mechanism, a hand-shake between the variable (or control) and the Event Handler. VB.Net also has AddHandler and Delegates, so it has everything C# has here, but for 95% of the time the WithEvents/Handles pairing is just much, much nicer. All events are available in the Drop-Down boxes, selecting one automatically creates the correct procedure stub for you.

 

(3) Implementing Interfaces in VB.Net is a dream. Simply state 'Implements IMyInterface' and all your required stubs simply drop in automatically. It's hard to appreciate how easy and nice this is if you've never seen it.

 

(4) C# lacks a With.. EndWith with block. This is a curious omission in my opinion. I guess this falls under the "not invented here syndrome", but I am pleased to see that C# guys are much more open to "outside ideas" than was the previous C/C++ community. There are a number of C# blogs and sites arguing for With.. EndWith. Given how easy this would be to do, I don't have a clue why it doesn't seem slated for 2005. I guess maybe the old-school C/C++ guys are in charge after all?

 

(5) C# Lack a 'MyClass' Equivalent. In VB.Net, we have 'Me' (which is equivalent to 'this' in C#) and 'MyBase' (which is 'base' in C#). However, C# does not have an equivalent to 'MyClass', which is a sort of override-blocking mechanism. It can be achieved in C# by creating a core non-overridable procedure that is called by the overridable procedure and then calling the non-overridable one, but this is a hassle. 'MyClass' really does have a purpose, even if needed infrequently. You don't *have* to have this, of course, but lacking it is not an advantage.

 

I find this one particularly odd, since this concept is not only supported by the CIL but actually has a direct representation. In short, a call to Me.SomeProcedure in IL is basically 'CallVirt SomeProcedure'. CallVert here means that if the 'SomeProcedure' is overridden then the overridden version would be called. A call to MyClass.SomeProcedure is the same, but ignores any overrides, should it exist. So how is this represented in the IL? Easy: use 'Call' instead of 'CallVert'. That is, instead of 'CallVert SomeMethod' it's just 'Call SomeMethod'. However, C# lacks this concept.

 

(6) The Switch statement in C# is archaic looking to a VB-programmer. I suppose one could argue that it's more flexible, but the "flow-through" strategy and use of break or goto's looks like something from the stone ages. The Switch statement also cannot handle groups of values on one line (without resorting to flow-through and/or goto's). Try to do something like this in C#:

Select Case i
    Case Is < 5
       ' Do Something
    Case Is 10, 15, 20, Is > 25
       ' Do Something
    Case Else
       ' Do Something
End Select

Use of multiple values or sets of evaluated values in one line can really clean up your code immensely.

 

(7) C# lacks a project-wide 'Imports' ('using' in C#) statement. I'm a bit on the fence on this one. I guess overall, it makes things a lot easier. It does make particular documents a bit less portable though, because the Imports statement is not within the Document itself. A bit of a toss-up here, I'm not sure which is better.

 

(8) C# cannot handle Properties that take a parameter. I guess this is open to debate (as is everything else I've listed!) but I think that C# is taking too strict an interpretation of "Property" here. I do "get" the mentality, I do: a Property is a surrogate for a Field, period. The Property may have some coding going on, but if you start adding Arguments, then it's a Function (er, Method), right?

 

Well, personally I don't think it's so clear cut. Take a look at the following post: See Post #3 Here.

 

In this situation, the coder had a simple Property:

Overloads ReadOnly Property Weight() As Double
   ' Returns the Default value of Weight in Kilograms.
   Get
       Return Weight(WeightUnit.Kilograms)
   End Get
End Property

Now he wishes to extend it's capabilities to be able to report in Pounds, Grams or Kilograms. Does this suddenly become a "Method"? Is the 'Units As WeightUnit' parameter really making this into a function like one would consider Sum() or Max() to be a function? I would argue "no", it is still a property. I feel that a parameter that is merely aiding in determining the return format, or type, or units is not sufficient to no-longer consider this a property.

 

But the point is that I can make this decision as a VB.Net coder. As a C# coder, this decision is made for me.

 

(9) C# code is a bear to use if interacting with MS Office Applications. VB.Net code is more "legacy aware". I guess you could say that C# code is "legacy-aware", but it has a different legacy: C/C++. But for anything regarding MS Office, C# is very tough. Doable, but the coding is just very ugly. Much, much less terse than VB.Net code.

 

This differential will go away eventually, whenever MSFT re-does the Office suite on .Net, but this will not go away at all with the Framework 2.0. Moving Office to .Net properly will be a long while in coming...

 

(10) Related to this is that if one is using Late Binding then VB.Net is a dream compared to C#. To effect Late Binding in C#, one has to be a Master of Reflection. I suppose that the "Masters" out there would prefer to execute their own Reflection code directly, but for the 99% of the rest of us, using VB's Late Binding mechanisms and letting VB do all the Reflection for us in the background is uniquely valuable.

 

 

I realize that this is a very long reply... My point (believe it or not) is not to try to prove that VB.Net is better than C#. But my point is that I think there is a heck of a lot going on in VB.Net that C# guys don't have a clue about, and would likely drool to have it if they knew what they were missing.

 

The flip-side is, I'd love for someone to explain to me the *real* advantages to working with:

 

(1) Unsigned Types

(2) Pointer Operations

 

I know that "for some algorithms" the use of direct pointers can be of real value. I would guess that this might occur if trying to implement a complex linked list implementation like a splay tree (or any sort of complex tree/trie or complex data structure)? But I'm just guessing...

 

I don't really don't understand the big deal with Unsigned Types, I personally don't have a problem using Int64 if I don't have enough positive values within my Int32, but I guess using Unsigned might be helpful in certain bit operations?

 

 

But let's step back for a minute and ask ourselves: why do C# programmers really love their language? I mean, come-on guys, what's the real reason?

 

Answer: "It's the syntax, stupid". VB.Net "feels dumbed down", as Tygur put it. Other remarks along these lines I've heard include "VB code gives me gas." LOL :p

 

There's nothing a VB.Net programmer can say to this. The truth is that VB is a less-symbolic language and so is much less concise. By using words instead of symbols, VB is easier for the beginner to read and so is more approachable by novice programmers. The result is that the C# guys see dumbed-down code, frequently being used by inexperienced programmers. The resulting bias on the part of C# programmers is understandable.

 

But, Tygur, syntax aside, to take the next step and conclude that VB.Net itself is somehow "crippled" really could not be farther from the truth.

 

-- Mike

Edited March 1, 2005 by Mike_R

[Mike_R]

Oh, Mookie, I apologize for such an overwhelmingly long reply... I do not feel that these issues are all that relevant, honest.

 

I would stick to what I advised in Post #3: That is, I would stick to VB.Net for now, but learning C# on the sideis really not a bad idea in my opinion. And, yes, you may eventually come to like C# more. :)

Edited March 1, 2005 by Mike_R

[coldfusion244]

Ok Mike!

 

Unisgned Types:

 

Basically never use them, I only used one (unsigned char, 8-bits) and that was because I had to program an lcd display (2x20) using rs232 port. It had an 8-bit command register, so I wanted to initalize the variable without using a sign bit. Example, unsigned char 0xCC is not the same as a char [signed] 0xCC. That and why use a 64-bit double and take up 2 registers when you can use an unsigned long and only take up 1 register. Much faster operation, I am saying this with references to ASM in mind. If you had a 64 bit number and only had 32-bit registers, you'd need 2 registers to store the information. If you had to divide 2 64-bit numbers, it's just not fun to do at the ASM level. So basically it is like optimizing your code (for me anyway).

 

Pointers:

 

Pointers allow for highspeed memory management. It's especially useful when you have classes of objects. Example boing you have a pointer to a memory location of type array. You start pointed at the first value of type integer. You know a 32-bit integer is 4 bytes, so if you wanted to go to the next value you could add 4 to the current pointer location and have the value. No function call to find the next one, just a point to a specific place in memory. From ASM, we find that moving a pointer into a register and accessing the memory from that pointer is faster, since the fastest accessable information is that stored in the registers. So having a pointer in EAX to a memory location could be accessed like [EAX] and would not have to go through finding the variable and then finding it's location and finalyl grabbing it. It would know exactly where to get it. Another advantage is when you want to edit some information. Say you have 2 objects of type a that had many functions and member variables. If you had a function that compared them and returned the correct one, it would be much faster to change the memory address of the pointer and not return anything [even though that wouldn't be good practice from my experience] than return the whole object of type a as teh result. Your basically working with 32-bit data (integers/longs) than with say an object that takes 512 byets of data.

 

This is all said with the knowledge that I have. I do not know about the inner workings (very well) of .net, or the compiliers for that matter. Take the information as you will, and if i'm wrong about somethign please let me know. But as I understand it, that's how it works.

 

On a side note, I drove through plainsboro tonight, my friend lives in the quail ridge apartments near scott's road [or is it scott's corner]... small world..

[Tygur]

That VB is "crippled" and "feels dumbed down" is totally my opinion. That simply reflects how I perceive it. I like unsigned types for their ability to prevent negative values from being passed around in cases when they would be invalid. It decreases the need to throw Exceptions for invalid arguments.

 

 

I never give two variables names that differ only in case. But I might do something like this, which will never work in VB:

public class MyClass {
   private class SomeThing {
   }
   private SomeThing something;
}

 

 

I found it interesting that you said the using block was infrequently used in C#. Once I found out about it, I thought it was the coolest thing, and I used it all the time. It was way better than:

DisposableClass whatever = new DisposableClass();
try {
   whatever.DoStuff();
} finally {
   whatever.Dispose;
}

...and I immediately wished for an equivalent in VB, because I was getting tired of using Try..Finally blocks. It's too much to type, and I do it too often. That actually is another complaint I have for VB.NET that I had forgotten to mention.

 

 

You are right that VB does have its own advantages, such as Select Case over C#'s switch. But most of the advantages you listed aren't really language features, but differences in how Microsoft built the IDE. Such advantages disappear once you use a different IDE. For example, C# is much easier in SharpDevelop than VB.NET, but I think they're improving that. This difference is important for me, because I'm trying to move away from Visual Studio, due to its cost.

 

 

With all that said, I think I might actually be using VB.NET more often than C# at the moment, but that might change.

[Mike_R]

Ok, Coldfusion, thank you for that description, I think I have a better feel (somewhat). On the Method Functions, I'm with you 100%. That makes sense.

 

On Array's I don't quite fallow... Isn't any index in the Array of Int's found by: ArrayAddress + IntexPos*4? Is this math avoided when directly using Pointers? I don't quite see how things go faster... I've heard it described just as you did before, so I know you're right, it's just not sinking into my thick skull.

 

As for Unsigned Types, it really does not seem to be that big of a deal, then. I never really thought that being able to use the high-bit as a positive value could really be that important...

 

Thanks for the run-down...

 

 

On a side note' date=' I drove through plainsboro tonight, my friend lives in the quail ridge apartments near scott's road [or is it scott's corner']... small world..

Dude, you drove right past my Appt! I'm in the Ravens Crest Appt's right next to Quail Ridge on Scott's Corner Rd. Next time you're in town, let me know, we could grab lunch or something...

 

 

Ok, Tygur, that example you give regarding a case-sensitive name-conflict situation is excellent. Yes, you are right: VB could not do this. VB can name a Variable the same as a Type, but not when the Type is Nested at the same level like this. I'm not sure that this is great practice anyway, more standard would be to name a private variable with a leading underscore:

public class MyClass {
   private class SomeThing {
   }
   private SomeThing _something;
}

I found it interesting that you said the using block was infrequently used in C#. Once I found out about it' date=' I thought it was the coolest thing, and I used it all the time.[/quote'] Oh, I guess it depends on what you're using of-course. But it's not *that* frequent a feature. I find this roughly equivalent to VB.Net's With..EndWith block (which does not effect a Dispose call, of course). The truth is that VB could use the Using Block and C# could use the With..EndWith block.

 

 

You are right that VB does have its own advantages' date=' such as Select Case over C#'s switch. But most of the advantages you listed aren't really language features, but differences in how Microsoft built the IDE. [/quote'] Actually, that post begins with a discussion of some length regarding IDE advantages of VB.Net vs C# in VS 2003, but this was really an illustration of the problems that C# brings upon itself by being case-sensitive. Case-sensitivity is the principal reson why IntelliSense is so hampered in the VS C# 2003 IDE. But I do recognize (and noted in the post) that this difference will be largely erased in VS 2005.

 

However, of the 11 points I listed, only #3 is an IDE Implementation issue. (Ok, I suppose that #8 could be viewed that way as well, I'm not quite sure how to think about that one, but it's not a major feature anyway.)

 

#2 is "sort of" an IDE issue, but my point on the WithEvents/Handles mechanism is not really the usage of drop-down's to pick your Event (which is nice), but really that this is a bi-directional hand-shake. When I can read through code and see that a procedure has the words 'Handles TextBox.Changed' this is just a beautiful thing. I realize that properly naming one's procs makes this less essential, but there is nothing like seeing 'Handles' as a guarantee from the compiler that this procedure in fact handles the event designated.

 

The other 8 are in fact language issues.

 

 

With all that said' date=' I think I might actually be using VB.NET more often than C# at the moment, but that might change.[/quote'] Yeah, I would consider changing to C# myself, but I do too much VBA stuff. Heck, it's all I do. But if one is not tied to VBA then I don't see why not. I actually prefer C#'s language syntax, although I honestly do wish that it had some of the features of VB.Net that I listed above. Although, I do think that the biggest issue is the VS C# IDE itself, which, thankfully, is due to a huge overhaul in the next verson...

 

Of the features that C# has, I really wish that VB had the ByRef/Out parameter enforcement that C# has. This is a very nice handshake-enforcement that C# has and VB.Net does not. Who knows, maybe someone will invent "V#" using all the best features from both languages? :p

Edited March 1, 2005 by Mike_R

[IngisKahn]

Declaring variables (esp. parameters) like A a; is a very common and standard thing to do.

Also note that Patterns and Practices dictates that properties should be implemented like this:

[CS]int property;

public int Property{ ... }[/CS]

[Tygur]

However, of the 11 points I listed, only #3 is an IDE Implementation issue. (Ok, I suppose that #8 could be viewed that way as well, I'm not quite sure how to think about that one, but it's not a major feature anyway.)

 

#2 is "sort of" an IDE issue, but my point on the WithEvents/Handles mechanism is not really the usage of drop-down's to pick your Event (which is nice), but really that this is a bi-directional hand-shake. When I can read through code and see that a procedure has the words 'Handles TextBox.Changed' this is just a beautiful thing. I realize that properly naming one's procs makes this less essential, but there is nothing like seeing 'Handles' as a guarantee from the compiler that this procedure in fact handles the event designated.

 

The other 8 are in fact language issues.

You're right. I stand corrected. Most of them are language issues. I'm not sure why I thought most were IDE issues.

[Mike_R]

Declaring variables (esp. parameters) like A a; is a very common and standard thing to do.

Also note that Patterns and Practices dictates that properties should be implemented like this:

[CS]int property;

public int Property{ ... }[/CS]

Huh, ok, I had thought that this was a no-no, even in C#. So the use of the leading underscore ("_") for private variables is only a VB convention then?

 

Declaring variables (esp. parameters) like A a; is a very common and standard thing to do.

You know' date=' you can do that in VB6/VBA as well. But doing this in VB.Net it's a little more dicey. It is [i']legal[/i] to to this in VB.Net:

Sub MySub(textBox As TextBox)
  ' ...
End Sub

But what happens is that the TextBox class definition then becomes unreachable because the 'textBox' variable definition is the local definition (and VB doesn't distinguish case). Mostly, it's fine, really, as the Static members are available on both the 'textBox' and on the 'TextBox', but the truth is, I started finding this a little confusing and have kind of stayed away from this in VB. Certainly less of a problem in C#, esp. if it is common usage and so people get used to looking for it.

Edited March 1, 2005 by Mike_R

[Tygur]

You know' date=' you can do that in VB6/VBA as well. But doing this in VB.Net it's a little more dicey. It is [i']legal[/i] to to this in VB.Net:

Sub MySub(textBox As TextBox)
  ' ...
End Sub

But what happens is that the TextBox class definition then becomes unreachable because the 'textBox' variable definition is the local definition (and VB doesn't distinguish case). Mostly, it's fine, really, as the Static members are available on both the 'textBox' and on the 'TextBox', but the truth is, I started finding this a little confusing and have kind of stayed away from this in VB. Certainly less of a problem in C#, esp. if it is common usage and so people get used to looking for it.

 

I'm a little lost. Putting this code in a form results in an extra TextBox being added to it. But unless I misread your post, you seem to be saying it's not supposed to work. Giving a variable the same name as a class doesn't limit anything, as far as I can tell. You just can't declare both the variable and the class at the same level.

Protected Overrides Sub OnLoad(ByVal e As EventArgs)
   Dim TB As TextBox
   CreateTextBox(TB)
   Controls.Add(TB)
   MyBase.OnLoad(e)
End Sub
Sub CreateTextBox(ByRef TextBox As TextBox)
  TextBox = New TextBox()
End Sub

[IngisKahn]

So the use of the leading underscore ("_") for private variables is only a VB convention then?

 

I hope not. P&P has pretty much declared that all underscores are evil. Property casing is the only problem VB has with P&P and the consensus is to use MyPropertyName since it goes along with the VB class syntax (Me, MyBase, etc.)