[RESOLVED] Private lines As New List(Of Line)

[treddie]

vb.net is SOOOOOOO annoying.

I am drawing a list of lines to a control. So, I declare:

  Private Lines As New List(Of Line)
  Private CopyOfLines as New List(Of Line)

In code, I have a custom Class called "Line".

I am wanting to reuse the list called "Lines" so I can start a new list while retaining the old list. So I copy it's contents to "CopyOfLines", then clear the contents of "Lines":

CopyOfLines = Lines
Lines.Clear

Problem is the contents of CopyOfLines ALSO gets cleared! Is there no way to break the connection of "CopyOfLines" to "Lines"? This seems so unnecessary. After all, if I say:

a=10
b=a
a=0

Then (b) will still = 10 while (a) = 0.

Why does vb.NET have to break such simple logic and turn it into a gargantuan issue? I wouldn't mind it as much if the MSDN library would make it possible to find references to "List (Of whatever)", but all I get are references to text in a textbox. It seems that every time I go to the MSDN, I get a convoluted, runaround explanation or simply no documentation of something someone has done in their own code? Where did THEY find the information?

(Now I know why only 19% of vb6 users went to vb.NET.)

[techgnome]

first you have to understand the difference between a REFERENCE variable and a VALUE variable. When you create a value variable.... like a number for instance... Dim x As Int32 ... you can assign a value to it.... 19 for instance.... you can then assign that value to another variable, y.... y = x .... because int32 is a value object, it's VALUE contents get COPIED to the new variable location (y) ... so now you have two variables that have nothing to do with each other and are independent of each other.

Reference variables work differently... they don't hold values, but rather the ADDRESS where the data is located. The List (Of T) (which is how you will find it in MSDN - that's how all of the generics classes are listed "As T") ... is one such object... so when you assigned Lines to CopyofLines... you transferred the address... but both variables still point to the same memory location ... so when you cleared Lines... it cleared the data in that location... which CopyofLines also pointed to - the result is that both get cleared out.

-tg

[treddie]

OK, I follow you there. ByVal and ByRef then come to mind. But if a variable such as List (Of T) is a REF variable, how do you tell .NET to copy the contents of the address over to a new address, so that another List (Of T) variable can have a copy of that info and at the same time be protected? I guess, in essence, "Copy ByVal".

[JuggaloBrotha]

The easiest way that I can think of is to do this:

CopyOfLines.Clear()
CopyOfLines.AddRange(Lines.ToArray)
Lines.Clear()

Otherwise this will work:

CopyOfLines.Clear()
For Counter As Integer = 0I To Lines.Count -1I
    CopyOfLines.Add(Lines(Counter))
Next Counter
Lines.Clear()

[treddie]

Thank you, JuggaloBrotha. That did the trick.

Earlier when I was looking into the properties and methods available, I ran into "AddRange" in the drop down list but could not get it to work. But that was because the documentation was unclear as to its usage. I was looking at "CopyTo" as well, but again it's all groping in the dark when the documentation can't give a simple definition and syntax.

Your approach worked. I wish there was an easier way to learn vb.NET then what MSDN has to offer. They ought to just get to the point.

Thanks again.

[jmcilhinney]

I wish there was an easier way to learn vb.NET then what MSDN has to offer. They ought to just get to the point.

MSDN is a reference library, not a tutorial. What you consider "getting to the point" is an incomplete reference for others. That said, this is the very first line in the MSDN topic for the List(Of T).AddRange method:

Adds the elements of the specified collection to the end of the List(Of T).

How is that not getting to the point? You don't even have to call ToArray as JB did because AddRange accepts an IEnumerable object and the existing List is already an IEnumerable.

list2.AddRange(list1)

[treddie]

jmcilhinney > First of all, "Howdie". I'm just frustrated with the vastly, over-verbose nature of MSDN and lack of ability to get to the basic descriptions before getting into the details. I'm not talking about tutorials, here. I was a fan of using reference libraries way back from ancient BASIC and assembly language up to vb6. Early vb up to v6 still worked in this regard although MS started venturing off into the usage of terms that was down-right unnecessary. At least at the end of vb6, it wasn't so bad. I learned vb5/6 mainly from the offline reference library.

Here's the overall problem with MSDN:

Let's say you've never heard of the term, "Integer". So you search for "Integer". What comes back amongst many other things is "Integer data type" and "Integer Type class". Then let's say you make the unfortunate choice, "about Integer Type class", expecting that you will at least be given a basic if brief explanation of what the Integer Type class is. Alas, what you get is,

"The following tables list the members exposed by the IntegerType type."

What is the point of a reference manual if it won't give you a brief description of what "Integer Type class" is, before jumping into the details about something you know nothing about? We're not talking about tutorials here, we're talking about the tried and true KISS method of documentation that USED to be the norm for reference manuals, but nowadays is thrown to the wind. So now, not finding out what "Integer Type class" is, you jump over to "Integer data type", to see if it can shed any light. Bingo...you come up with,

"Holds signed 32-bit (4-byte) integers ranging in value from
 -2,147,483,648 through 2,147,483,647."

Sounds a lot better, but what is an "Integer"? If you look at the MSDN in general, you can click on any blue-highlighted term to get vectored off into further reading. But when you look at the line I just mentioned,

"Holds signed 32-bit (4-byte) integers ranging in value from
 -2,147,483,648 through 2,147,483,647."

, there IS no highlighting for the word "integer". So we're back to square one again, what is an integer? So if I continue my search, I'll come to "integers". NOW, I get a concise, to-the-point definition of integer:

"Integers are whole numbers, including positive, zero, and negative. A variable holds 
integers if you declare it to be of type Integer. The Integer Data Type (Visual Basic) 
can hold integers from -2,147,483,648 through 2,147,483,647."

Not ONLY that, but the terms, "Integer Data Type (Visual Basic)" are HIGHLIGHTED, which conveniently vectors me back to my FIRST search point. Why wasn't the word "integer" highlighted in my EARLIER search to vector me HERE? The reason is that MSDN is sloppy and inconsistently written documentation for what could be an easily surf-able "document".

The next example is my real-world case:

Since I was unfamiliar with List(Of T), apparently a new feature of .NET (Since 2005?), there was no way to know that "T" was a generic term meant to mean many things.
So, forget about .AddRange at this point (or even T), and just search for "List". What are we dealing with here? A class? A data type? If it is a class, what type of class? So stopping off at "List class" to see what it says, you get,

"Provides control capability to render a list of items as either a static display 
or an interactive list."

Sounds like they are referring to text at this point, but not sure. So I check further and go to "about List class", and there, you get,

"Provides control capability to render a list of items as either a static display 
or an interactive list."

NO S--T! It just told me that the first time. No point in going further...all that remains are the details, "all members", "constructor", "events", "methods", "properties", which will go on about something I still don't have the definition for.

Now here is a conundrum. Even though "List class" MIGHT be what I am looking for, I still don't REALLY know. And if it is not what I am looking for, then it would have been nice to be told what it was so that I could store that info in the back of my mind for future reference. But for now, is it connected to "Of T"? there is no mention on the page that makes any kind of connection whatsoever, so I am left with a big question mark, that does not need to be there.

Next down in the index is "List control". Well, I know I'm not dealing with a control, so moving on I get to "List(Of T)". Hm...sounds WAY closer to what I was looking for...at least it has the form "List(Of...)". It's description reads,

"Represents a strongly typed list of objects that can be accessed by index. 
Provides methods to search, sort, and manipulate lists."

Since I am trying to draw lines, this description MIIIGGGHHT be suggestive of that since I do have a list of lines to be drawn, and those lines are described by a strongly typed structure. Although I'm not looking to search, sort or manipulate anything other than build a list of lines, or in my case COPY a list of lines. At this point the MSDN COULD have said far more successfully, "Represents a strongly typed list of objects (text, graphics, etc.) that can be accessed by index." That simple change would have boosted my confidence in this find from probably 30-40% up to 80-90%, and glued me to this find much more strongly. The whole point of successful and efficient surfing is the usage of words that will guide you quickly and efficiently through a universe of information, down from the most basic description into successively higher verbosity as the need requires. And if highlighting is used, then making sure that the document is covered in this respect. MSDN has the look and feel of a "Beta document", like a book that has yet to go through it's first rewrite.

But back to "List(Of T)". What is the "T"? And why was it not mentioned in the initial description? Remember, I am at the tip-top of the description "tree" if you will and MSDN does not even mention one word about the moniker "T"? So, have I reached my target yet, or no? How can I say for sure when "T" is not described? And there is no graduation between the initial definition and discussion about members, methods and properties.

So I look further down the index and find that there are no closer matches for "List(Of...)". So this MUST be it. So I go back up to the "List(Of T)" stuff and notice ".Addrange method". At first glance, I don't want to add anything, I want to COPY something. My first initial thought is that in order to use ".AddRange" I would have to know what range to add, if that idea would work anyway, and I don't want to have to worry about finding indexes or addresses or anything. So I keep it in the back of my thoughts and go down to, ".CopyTo method". This sounds closer to what I need:

 "Copies the List or a portion of it to an array."

But that sounds like it wants to take the contents of the "strongly typed" data structure and convert it over to a traditional array or something. All I want to do is copy a list form its original source to a new, INDEPENDENT source...a PERFECT COPY, not some conversion over to something else. In other words, ByVal not ByRef. Nothing else in the members list fits the bill. So I'm back to ".AddRange". Maybe there is a simple way to add the complete range, thereby not having to worry about indexes. MSDN says:

 "Adds the elements of the specified collection to the end of the List."

OK, good enough. If I'm going to have to copy over a range, what is the syntax? Now FINALLY, midway down the page I find an obscure reference to "Of T". Clearly, "T" stands for "Type". Why was this not in the very first, bare-bones description of "List(Of T) 10 minutes ago?! Hell! Why didn't they just say "List(Of [Type])?!

This is exactly what I am talking about. The MSDN is a slapped together, hodgepodge of contributions from a zillion tech writers who know nothing about concise tech-writing and it is obvious that there was no strict control of everything going into the master document. Yah, there's a structure to it, but that structure is violated time and time again. And the fact that I just brought this up shows an even more insidious point that only a good tech-writer would notice. The fact that in the middle of my search, I am forced to divert my search to mentally account for how inept this document is and that very thought going through my mind has pulled me away from what I came here to do...Find out what the hell List(Of T) is!

This is not about tutorials. You don't need a friggin tutorial here. You just need a concise set of definitions that follow an increasing and gradual increase in verbosity as you proceed. The "tutorial" builds in your head as you proceed through the rules and procedures in the definition that would be the basis for any tutorial anyway.

END OF PART 1

[treddie]

PART 2:

Now...back to "LIST(Of T)"....and syntax.

Now I am inundated with references to C#, C++, J# and JScript syntax along with VB syntax, yet my index filter is set specifically for only VB. You COULD say that it's not REALLY inconsistent, because I'm not in the right pane at that point, and I CAN go up to the Language Filter there and choose just VB. However, it IS inconsistent in that my initial index criteria was VB only, so why would I want to see all the other language syntaxs by default when the obvious INTENT was VB only?! The other language syntaxs should be off by default, not on.

Ahhh, where was I...Oh yes..."LIST(Of T)"....syntax.

Take a look at the Parameters. They list "collection" as the only parameter. But there are actually three: "instance", "collection" and "T". Yes, I know, the subject heading is specifically ".AddRange" and ITS sole parameter is "collection", but the ENTIRE syntax that INCORPORATES ".AddRange" requires two more. And to make the search as efficient as possible for the user, all three should be explained so that having to shoot back and forth between pages is eliminated.

And nowhere in the discussion so far about List(Of T) is any stressing at all of what can be included in the definition of a "list". It simply states list of "objects". Especially to a beginner this may be too vague and it does not need to be. Simply by adding a line or two about types of objects (without expounding far), such a definition could have opened up avenues for the user to explore other possibilities. Instead, the search stops there; the document is self-stopping instead of opening a dialogue with the reader to WANT to explore further.

A distinction is made between the terms "instance" and "collection". "Collection" is according to MSDN:

 "A Visual Basic Collection is an ordered set of items that can be referred to as a unit."

"Instance" is defined as:

"Represents derived classes known to be management instrumentation instance classes. These
derived classes inherit an implementation of IInstance that allows instances to be
published through the Published property."

How can anyone, especially a beginner make anything from that?! And whether or not the "collection" parameter can be of the same structure as the "instance" parameter? For, in the usage:

MyListOfLines.AddRange(YourListOfLines)

this is of the form:

instance.AddRange(collection)

and "instance" and "collection" have the same structure. They're identical...one is just a copy of the other (so long as MyListOfLines was cleared first).
The words:

 "Represents derived classes known to be management instrumentation instance classes."

are completely wordy in every respect for an introductory definition and completely unnecessary. As an old English teacher of mine used to say, "Innapropriate terminology".

The second line attempts a continuation of the definition of "instance", by invoking one of its properties, namely ".Published". But you can't introduce an extended property of something to expand its definition until you have rigidly defined its core meaning first. Otherwise, the extension has no context, and the definition fails. That's grade school stuff.

Surfing through MSDN is like driving through Washington DC. Did you know that DC is classed as the 2nd worst navigable city in the US (Number 1 is Detroit). Trust me...DC's bad. Never been to Detroit. In comparison, Los Angeles is a breeze. Las Vegas in some respects is worse than LA. I've lived in both. The key to why it is so bad in DC is the lack of logical descriptions for freeway off-ramps that match the descriptions in road maps and GPS maps, AND giving the driver ample time to make lane changes well in advance of ramp changes when moving at freeway speed.

MSDN-navigation and DC-navigation have a lot in common. No rigorous preparation. Just a haphazard framework.

I've studied Linear Geometry, Differential Equations, Astrodynamics, Numerical Analysis, Assembly Language, have a huge library of old NASA Apollo and Shuttle procedures and a host of other subjects. I'm no genius, but you don't need to be to understand technical subjects. You just need good, solid, well-written reference materials. MSDN has got to be one of the absolute worst pieces of technical writing I have ever read. HANDS DOWN.

[techgnome]

Your frustration is misguided... For starters, MSDN is a reference tool... not a teaching tool. There are thousands of pages spanning two languages and 5 framework versions (soon to be 6)... and that's the just the .NET area... that doesn't include C/C++, or the older VB documentation. I'm not sure what version of MSDN you had back in the days of VB6, but back then the documentation was horrid... worst I had ever seen. What's there now, is certainly a thousand times better. Could it be better? Sure, in some areas. How ever, I think your rant about Integer is a bit unfounded and extreme. Using MSDN as a sole means of learning about the basics of programming, it akin to learning how to be a trapeze artist with out using a net. If you're not starting off with a book or some kind of formalized instruction and learning the basics of comp sci... then you're asking for a world of hurt.

Secondly, down at the bottom of EVERY MSDN page, there's a community feedback section. You can leave your own comments (similar to the way the pages work in the PHP online documentation) as well as rate the content of the page and let MS know what you liked (or not) about the page, and how it could be improved. If you've got an issue with something, I suggest you take it up with them, rather than blasting us for something out of our control.

-tg

BTW - List (of T) is what's known as a Generics class.... the "T" means type.... it's not an arbitrary letter.... List of Type .... So a List (Of String) is a list of strings.

[jmcilhinney]

I taught myself .NET programming using MSDN as my primary resource. I read it first every time and if I didn't understand what it said or needed more info I looked further afield. It was invaluable back then and the more I used it the more helpful it became. Now that I'm an experienced, professional developer I still find it useful because, thankfully, it's wasn't written for newbies alone. If I can learn from MSDN as a beginner and a professional then anyone can, unless you think I'm just way smarter than everyone else.

That's grade school stuff.

Speaking of grade school, isn't that where we learned what an integer is? Maybe you were away that day.

[SJWhiteley]

I think you are being a tad critical - I find it quite straightforward and to the point. True, there are a good few areas where a bit more explanation may be necessary, but is shows the usage of almost every object so you can experiment to see what it can do.

Your explanation of your frustration reads like this:

I need a lawn mower I think, what does a lawn mower do?

[It cuts grass]

Um, what's grass?

[The green stringy stuff sticking out of the lawn]

What's a lawn?

[The flat stuff in front of your house]

I don't have a house...


But don't feel too bad. As stated, it's a reference library not a teaching tool. In the same way that a dictionary is used (kind of a catch22 - if you don't know how to spell a word, how can you look it up in a dictionary? you don't know how to spell it...).

The MSDN library expects you to understand certain fundamentals (e.g. everything is an object, so there's no point in giving examples of an object whenever an 'object' is mentioned). If you don't know what an object is, you are going to struggle with pretty much every reference entry in MSDN.

Something that I've noticed is that a lot of people, when faced with C# tend to have an inability to translate to VB. There is only a minor syntax change from VB to C# for simple translation (you can almost just remove the semi-colons and it's now in VB). It's not too difficult, it'd behoove a VBer to learn the C# (C style) syntax.

As a side note - always remember, a poor woodworker always blames his tools. And: expertise in one field does not equate to expertise in another.

[Shaggy Hiker]

I, for one, thoroughly enjoyed your rant. I've felt that way at times about one thing or another, and do understand where you are coming from. I felt that the MSDN documentation started off quite poor, but was improved steadily over time until it became, largely, a good reference. There are still glitches in it, though, and I don't think it will really get better.

I hadn't really thought about it, but what you were saying about T made sense. I understood 'of T' because the concept had been kicked around C++ for the STL for at least a decade before it showed up in VB. If you didn't have that background, then, what has become standard, nomenclature for generics would not make all that much sense.

Still, when I was starting in VB, a paper reference was a good tool. Now, there are so many options, and so much information, that I wouldn't care to waste the shelf space on a thorough .NET reference, so MSDN is the best solution. Yet it is still just a reference, and not a basic tutorial on the jargon that changed from VB6 to .NET. Every field and focus has jargon. VB6 wasn't better or worse, it was just different.

As for substance, I don't think this question was answered by anyone earlier:

Problem is the contents of CopyOfLines ALSO gets cleared! Is there no way to break the connection of "CopyOfLines" to "Lines"? This seems so unnecessary. After all, if I say:

a=10
b=a
a=0

Then (b) will still = 10 while (a) = 0.

Why does vb.NET have to break such simple logic and turn it into a gargantuan issue

The answer is simply: Classes.

The major change between VB6 and .NET was the move to an Object Oriented (OO) model. Under true OO philosophy, everything is contained within a class or structure. True globals are not allowed. In fact, since the closest you can come to a true global in .NET is a variable declared as Public in a module, and a module is quietly turned into a class with all Shared members, you don't actually violate that rule in .NET, though it looks like you do. Of course, VB6 was quite different in this regard, though the syntax for globals was identical.

The issue with classes is that they can hold ANYTHING, and can be of any size at all. Would you like to have a class that holds an array of open database connections, each of which maintains a List of Datasets? You can do it (at least up to the number of connections you can hold open at any one time) in .NET. So what should happen when you have some MASSIVE class and you assign it to a different variable of the same type:

Dim A as New MassiveClass
Dim B as MassiveClass

B = A

If MassiveClass was just an integer, then B = A would copy the value of the integer from A into B. Is that what you would want to have happen with the horrid class I described above? Should B open all new connections and add in all new datasets? Perhaps the new datasets would be necessary, but the connections could be shared between the two objects. Perhaps A was at the limit for open DB connections, so if B even TRIED to open all new connections it would just fail, meaning B = A would result in B being Nothing, Invalid, or crashing the program.

That's just an example, though it touches on key points. What you are expecting in your question is called a deep copy. As long as your data types are simple little things like numbers, then a deep copy is obvious and intuitive. However, once you start adding classes, your classes can be of any size and behavior. A deep copy can't even be performed in these cases, since the compiler can't always know how to do the copying. Sometimes it can, but not always. Another example would be a class that contained a form that was shown to the user, and was supplied to the class as an argument to the constructor, or created new if none was supplied. Should a copy pass over the existing form such that the same form is shown by both classes, or should the compiler create a new form for the new class? The compiler can't know what is best, nor can it be expected to study the class and figure out whether or not it knows what is best.

By default, every OO language uses shallow copies, so that just addresses of objects are copied. This also limits the amount of stack space needed for functions that take objects as arguments. Whether you declare those arguments ByVal or ByRef, you are just getting a four byte address, not a copy of the whole object stuffed onto the stack. What that address actually IS will be different uner ByVal or ByRef, but in both cases you just get an address. To perform a deep copy, you have to tell the compiler how to do so for each object that you want to copy. In C++ that would mean a copy constructor that tells the compiler "when I am copying an object, create the copy in this fashion." .NET doesn't include copy constructors, so you need to add a method that performs the Copy for you. There is an interface that you can implement that gives you a stub of a Copy function, but whether you use the interface or not, you will still be responsible for directing how the compiler performs the copy.

And that's why A = B doesn't work the same for classes as it does for simple numbers.

As a last point, I would rather dispute your suggestion that only 19% of VB6 users moved to .NET. I used to love VB6, but as soon as I became marginally capable with .NET, I switched over and would never willingly go back. Lots of people on this forum hold the same view. While I also realize that there are several people who don't want to switch, I would say that 19% may have been true in 2002, but is totally false by now.

[Atheist]

Let's say you've never heard of the term, "Integer". So you search for "Integer". What comes back amongst many other things is "Integer data type" and "Integer Type class". Then let's say you make the unfortunate choice, "about Integer Type class", expecting that you will at least be given a basic if brief explanation of what the Integer Type class is. Alas, what you get is,

"The following tables list the members exposed by the IntegerType type."

What is the point of a reference manual if it won't give you a brief description of what "Integer Type class" is, before jumping into the details about something you know nothing about?
... So now, not finding out what "Integer Type class" is, you jump over to "Integer data type", to see if it can shed any light. Bingo...you come up with,

"Holds signed 32-bit (4-byte) integers ranging in value from
 -2,147,483,648 through 2,147,483,647."

Sounds a lot better, but what is an "Integer"? If you look at the MSDN in general, you can click on any blue-highlighted term to get vectored off into further reading. But when you look at the line I just mentioned,

"Holds signed 32-bit (4-byte) integers ranging in value from
 -2,147,483,648 through 2,147,483,647."

, there IS no highlighting for the word "integer". So we're back to square one again, what is an integer? So if I continue my search, I'll come to "integers". NOW, I get a concise, to-the-point definition of integer:

"Integers are whole numbers, including positive, zero, and negative. A variable holds 
integers if you declare it to be of type Integer. The Integer Data Type (Visual Basic) 
can hold integers from -2,147,483,648 through 2,147,483,647."

Not ONLY that, but the terms, "Integer Data Type (Visual Basic)" are HIGHLIGHTED, which conveniently vectors me back to my FIRST search point. Why wasn't the word "integer" highlighted in my EARLIER search to vector me HERE? The reason is that MSDN is sloppy and inconsistently written documentation for what could be an easily surf-able "document".

I tried simply searching for "Integer" and the first 3 results returned all state:
Integer variables are stored as signed 32-bit (4-byte) integers ranging in value from -2,147,483,648 through 2,147,483,647.
An integer is not just a common datatype in modern programming languages, it has a meaning "outside of programming" aswell. You could search google for "define integer", or you could search for Integer on wikipedia and find yourself a good definition of it. Do you really expect MSDN to act as a dictionary aswell, providing definitions for all words written in it?
And as has been said, MSDN is a reference library, not a beginners guide. If a developer does not know what an integer datatype is, perhaps it is time to buy a beginners book or follow some online tutorial.

The next example is my real-world case:

Since I was unfamiliar with List(Of T), apparently a new feature of .NET (Since 2005?), there was no way to know that "T" was a generic term meant to mean many things.
So, forget about .AddRange at this point (or even T), and just search for "List". What are we dealing with here? A class? A data type? If it is a class, what type of class? So stopping off at "List class" to see what it says, you get,

"Provides control capability to render a list of items as either a static display 
or an interactive list."

Sounds like they are referring to text at this point, but not sure. So I check further and go to "about List class", and there, you get,

"Provides control capability to render a list of items as either a static display 
or an interactive list."

NO S--T! It just told me that the first time. No point in going further...all that remains are the details, "all members", "constructor", "events", "methods", "properties", which will go on about something I still don't have the definition for.

Now here is a conundrum. Even though "List class" MIGHT be what I am looking for, I still don't REALLY know. And if it is not what I am looking for, then it would have been nice to be told what it was so that I could store that info in the back of my mind for future reference. But for now, is it connected to "Of T"? there is no mention on the page that makes any kind of connection whatsoever, so I am left with a big question mark, that does not need to be there.

If you want to know about the List(Of T) class, you should search for List(Of T), not just List. The documentation on the List class specifies that it is a ASP.NET Mobile Control. If thats what you're looking for, then keep reading. If not, you might want to refine your search.

Next down in the index is "List control". Well, I know I'm not dealing with a control, so moving on I get to "List(Of T)". Hm...sounds WAY closer to what I was looking for...at least it has the form "List(Of...)". It's description reads,

"Represents a strongly typed list of objects that can be accessed by index. 
Provides methods to search, sort, and manipulate lists."

Since I am trying to draw lines, this description MIIIGGGHHT be suggestive of that since I do have a list of lines to be drawn, and those lines are described by a strongly typed structure. Although I'm not looking to search, sort or manipulate anything other than build a list of lines, or in my case COPY a list of lines. At this point the MSDN COULD have said far more successfully, "Represents a strongly typed list of objects (text, graphics, etc.) that can be accessed by index."

But what is Text and Graphics in this case? The documentation states 'objects' because...well thats a term that covers all objects really. You can store anything in it.

That simple change would have boosted my confidence in this find from probably 30-40% up to 80-90%, and glued me to this find much more strongly. The whole point of successful and efficient surfing is the usage of words that will guide you quickly and efficiently through a universe of information, down from the most basic description into successively higher verbosity as the need requires.

I can certainly say that adding the parantheses "(text, graphics)" to the description as you described above will certainly cause more confusion.

But back to "List(Of T)". What is the "T"? And why was it not mentioned in the initial description? Remember, I am at the tip-top of the description "tree" if you will and MSDN does not even mention one word about the moniker "T"? So, have I reached my target yet, or no? How can I say for sure when "T" is not described? And there is no graduation between the initial definition and discussion about members, methods and properties.

What do you mean? You searched for "List" when you wanted to read about "List(Of T)", and you blame MSDN for the bad results? If you read the documentation for List(Of T) you'll find:

Type Parameters

T

The type of elements in the list.

And further down you find examples that demonstrate how you store strings in a List(Of T).

So I look further down the index and find that there are no closer matches for "List(Of...)". So this MUST be it. So I go back up to the "List(Of T)" stuff and notice ".Addrange method". At first glance, I don't want to add anything, I want to COPY something. My first initial thought is that in order to use ".AddRange" I would have to know what range to add, if that idea would work anyway, and I don't want to have to worry about finding indexes or addresses or anything. So I keep it in the back of my thoughts and go down to, ".CopyTo method". This sounds closer to what I need:

 "Copies the List or a portion of it to an array."

But that sounds like it wants to take the contents of the "strongly typed" data structure and convert it over to a traditional array or something.

The List(Of T) is strongly typed, because it lets you specify what type is should hold, and wont let you add anything of another type, nor can you retrieve anything of another type. Think of an array, if you declare a string array, wont that too be strongly typed? Nothing is being converted.

All I want to do is copy a list form its original source to a new, INDEPENDENT source...a PERFECT COPY, not some conversion over to something else. In other words, ByVal not ByRef. Nothing else in the members list fits the bill. So I'm back to ".AddRange". Maybe there is a simple way to add the complete range, thereby not having to worry about indexes. MSDN says:

 "Adds the elements of the specified collection to the end of the List."

OK, good enough. If I'm going to have to copy over a range, what is the syntax?

Are you saying the documentation does not provide information about how to use the AddRange method?

[Atheist]

Now FINALLY, midway down the page I find an obscure reference to "Of T". Clearly, "T" stands for "Type". Why was this not in the very first, bare-bones description of "List(Of T) 10 minutes ago?! Hell! Why didn't they just say "List(Of [Type])?!

Read what I posted on this a bit further up.

This is exactly what I am talking about. The MSDN is a slapped together, hodgepodge of contributions from a zillion tech writers who ..... pulled me away from what I came here to do...Find out what the hell List(Of T) is!

Please do tell how you would structure MSDN and how you would describe a List(Of T) if not as a strongly typed list of objects? And if you do not know what T is you can just, as with all class documentation (as, believe it or not, they DO follow a certain structure), scroll down a little bit to find parameter information.

[Atheist]

And as for the problem at hand, the List(Of T) provides a constructor that takes an IEnumerable(Of T) as paremeter. Which means that you can create a new List(Of T) and pass the original List(Of T) in its constructor, to create a copy of the original.

http://msdn.microsoft.com/en-us/library/fkbw11z0.aspx

Dim originalList As New List(Of String)
originalList.Add("Hello")
originalList.Add("World")
Dim newList As New List(Of String)(originalList)

[techgnome]

Athiest - the problem with looking up List (of T).... is that you have to know WHAT to search for.... if I was just starting out, I'm not sure I'd know to look for List (of T) either.... which is why I think we oft see people using ArrayList (or is it ListArray ??) because they don't know what to search for. Some of us do. We've been around the block a few times and know how to do effective searching... the problem is that the work "list" is such a generic term, as well as a commonly used word, that getting anything meaningful presents a problem. BUT that's a problem with searching in general, and not a fault of MSDN.

I'm serious about the feedback portion. MS added it to help entice the community to get involved in providing feedback on the strengths, weaknesses and gotchas in MSDN... I still have yet to see A SINGLE use of it. If you see something that could be better done, post a comment... leave the feedback, just make sure you do it in a constructive manner. Offer up how you would change it.... don't jsut say "this isn't clear, please improve it." Tell them HOW you would make it clearer. More likely to get action on it that way.

-tg

[Atheist]

Athiest - the problem with looking up List (of T).... is that you have to know WHAT to search for.... if I was just starting out, I'm not sure I'd know to look for List (of T) either.... which is why I think we oft see people using ArrayList (or is it ListArray ??) because they don't know what to search for. Some of us do. We've been around the block a few times and know how to do effective searching... the problem is that the work "list" is such a generic term, as well as a commonly used word, that getting anything meaningful presents a problem. BUT that's a problem with searching in general, and not a fault of MSDN.

Yeah, I understand that, but cant the same be said for all things?

"The problem with looking up <insert anything here> is that you have to know what to look for."

[techgnome]

True... but I think with programming concepts, it becomes a bit more so.... I mean, if I'm searching for a recipie for something, I can usually narrow it down some, even if I don't know quite what I'm looking for. But for programming terms... it becomes a bit more esoteric. Somethings are obvious... like searching for DataSets or DataTables.... things like Generic classes..... not so much.

-tg

[JuggaloBrotha]

As a last point, I would rather dispute your suggestion that only 19% of VB6 users moved to .NET. I used to love VB6, but as soon as I became marginally capable with .NET, I switched over and would never willingly go back. Lots of people on this forum hold the same view. While I also realize that there are several people who don't want to switch, I would say that 19% may have been true in 2002, but is totally false by now.

Just to touch on this point, when I started programming in .Net I technically was coming from vb6 and all I'll say is this: things I couldn't figure out in vb6 (which was a lot) come naturally in .Net, and not only vb.net but c# as well.

[jmcilhinney]

True... but I think with programming concepts, it becomes a bit more so.... I mean, if I'm searching for a recipie for something, I can usually narrow it down some, even if I don't know quite what I'm looking for. But for programming terms... it becomes a bit more esoteric. Somethings are obvious... like searching for DataSets or DataTables.... things like Generic classes..... not so much.

-tg

This is quite true, which is why noone should try to learn anything directly from a reference only. For example, as has been said, a dictionary is no use to you if you don't know how to spell a word but dictionaries are not intended to teach you how to spell. They are intended to provide you a pronunciation and definition of words that you already know how to spell. MSDN is a reference, not a tutorial. There are plenty of beginner tutorials on the web and in books that will teach you the basics. Once you have those basics, then you DO know what to look for on MSDN.

Having said that, this thread emerged simply because the OP doesn't understand how reference type objects work. If they had then they'd have known that assigning the value of one variable to another does not create a copy of the referenced object. It's not for the List(Of T) documentation to explain that. That's the sort of thing that most web- or book-based tutorials teach early on because it's so fundamental to .NET programming. Reference documentation doesn't teach you programming fundamentals. The day it does is the day it stops being good reference documentation.

[treddie]

Well, I certainly started up a fire storm, here!

First of all, my intention was not create animosity. Maybe I'm just too vocal about my opinions. Also, my integer example was a hypothetical one and not necessarily the best one, or described as clearly as it could have been had I had more time. But I was hoping that at least the jist of my argument would come through.

As a newcomer to .NET (and an avoider of C), I perhaps have a take on this that you guys can no longer appreciate due to the fact that your experience level is more advanced with programming in general than my own. For myself, I am somewhat familiar with classes, but probably still at the newbie level. Yes, going to a beginner's book on .NET is now probably the only way to go, but it used to be that documentation that came with a product was written so that it was "equally" accessible to beginners and advanced users alike. To make that possible, it boils down to structure, and in my opinion MSDN lacks the type of structure to be ameniable to both. For instance, with the lines I used earlier as an example:

"Represents derived classes known to be management instrumentation instance classes.
These derived classes inherit an implementation of IInstance that allows
instances to be published through the Published property."

You've got to admit, a real beginner is going to have a rough time with that one. With my experience level I can get through it, if I slow down and take a hard look at it, but it is like wading through legal-eze to get to the underlying point. With YOUR experience levels the structure of MSDN may actually be quite nice for you. My thought is that you guys are now, naturally removed from the naive basis you once used to have as beginners. So you can't percieve the MSDN the way a beginner or semi-beginner does. You also can not forget that you probably have the extra experience gained from knowing any version of C. And it appears to me that vb.NET is really C, but dressed in different clothes.

You may disagree with me, but I can clearly see in my own mind how much the MSDN can be re-structured so that any level of user can navigate far more successfully through it than is now possible. Right now, I think MSDN should be called "MSDN for Advanced Users".

Restating an earlier comment I made, in many cases you don't need a tutorial to proceed, you just need a concise set of definitions that follow an increasing and gradual increase in verbosity as you proceed. The "tutorial" builds in your head as you proceed through the rules and procedures in the definition that would be the basis for any tutorial anyway.

There was an ease to vb6 that does not carry over to .NET. THAT is a REALLY important point, because it allowed users such as myself to just jump in and get quick ideas running without a lot of programming overhead. And there are other minor points that add to the overhead such as having to use the convention "Math.Cos()" instead of just "Cos()". There alone you have twice as many characters to type in (not including what would be inside the parens). It would be nice if .NET could accept certain defaults to speed up work for "casual" programmers. It was nice to quickly work out ideas. Because I knew that if it ran too slow, I could always get the speed I needed by going with the API libraries. vb6 really was the "perfect" median between two worlds.

Anyway, it's just my take on the matter.

[Shaggy Hiker]

I loved VB6, as I said before, yet I would never willingly go back. I'm not actually convinced that VB6 was easier to learn than .NET, but there was a real difference, which was OO. If you learned object oriented programming from the start, then .NET would be quite simple, while VB6 would be awkward. I do think the documentation is not as good as what was available for VB5, and I have no opinion about the documentation for VB6, but the language was also considerably simpler. You could actually fit all the available functions in a book. It was a BIG book, to be sure, but it was one book. I can't imagine the size of the book needed for .NET. However, the documentation is written more for OO programmers, which will be tougher for people coming from a strict procedural background. Most tutorials that I have seen about OO concepts, approach the concept as if it was some, nearly insurmountable, hill. If the tutorials make it sound like a daunting concept, then there's little wonder that people approach it with trepedation.

You did start a firestorm, though, and it's a good one. People are waxing eloquent over philosophies. I've always enjoyed that kind of a discussion. There isn't any animosity, though, not from the people who have posted in this thread.

By the way, it was C++, not C. The former is OO, while the latter is not.

[jmcilhinney]

By the way, it was C++, not C. The former is OO, while the latter is not.

I also think that only a VB6 developer would ever say that VB.NET was more like C++ than VB6. C++ programmers would shudder at the thought.

Some people neglect to consider that VB.NET and C# are both brand new languages. VB.NET was never meant to be an evolution of VB6, any more than C# was meant to be an evolution of C++. They were both meant to be new languages that used the syntax of existing languages.

VB.NET is modern, 100% OO language that uses the verbose VB syntax for readability. It also introduces other VB-like features for simplicity, like default form instances, the application framework for WinForms and the My namespace. C# uses the terse C syntax but is much simpler to get to grips with than C++, making it far more productive, particularly for those new to it. Neither C# or VB.NET are meant to be anything other than what they are.

[treddie]

Well, for better or worse, it's certainly a paradigm shift of sorts.

No way around forgetting everything I learned about vb6, and start out like a new-born babe, wipe the slate clean and read up on vb.NET, I guess.

[JuggaloBrotha]

Well, for better or worse, it's certainly a paradigm shift of sorts.

No way around forgetting everything I learned about vb6, and start out like a new-born babe, wipe the slate clean and read up on vb.NET, I guess.

Don't feel bad, not only am I programming in Vb.net and C# but I've also got some clients where I'm programming in vba (a stripped down vb6). Try shifting between .Net and vba a few times a day.

The more you work in .Net, the easier it becomes.

[treddie]

No doubt you are all correct about .NET's abilities. And clearly for me, this is a new language structure (especially for me, who has not benefited from a background in any form of C). But what was most frustrating is that I am smack in the middle of a huge graphics program that was half completed in vb6, and I had tentatively scheduled in a Beta release date somewhere around early/mid 2010. Now, that target must slip by probably a good 3 months + to get my mind around .NET, and to be proficient enough to know different forms of optimization and some of the pitfalls. But...that's just the way it is. Time to stop wining and just get to it.

[Shaggy Hiker]

Oh, I don't know. A good rant can help, at times.

[techgnome]

so can a good cry and a big bottle of Jack.

-tg

[treddie]

Yes to both!

[JuggaloBrotha]

so can a good cry and a big bottle of Jack.

-tg

*crys*...*grabs bottle*..*wishes to have a gf to cuddle with*

oh wait, scratch that last one...

[treddie]

Last one ain't so bad.