Visual Studio cannot start debugging because the debug target is missing

This is why I so GD hate .Net.

Everything was working fine as I was working some code and then I get two types of error messages that are so Fing verbose they tell me nothing but that whoever wrote the damn messages gets high off abusing the English language because he thinks it makes him look smart.

The errors are:

Code:

---

"Visual Studio cannot start debugging because the debug target is missing.  Please build the project and retry, or set the Output Path and AssemblyName properties appropriately to point at the correct location for the target assembly."

---

Which tells me nothing because either recommended action solves nothing!

...and another talking about

Code:

---

"blah, blah, blah, the assembly manifest does not match the assembly reference, blah, blah, blah."

---

And people say how wonderfully better vb.Net is compared to vb6.

1. Please tell me what is so wonderful about a programming language that it can get so easily screwed up this way, where the previous language never had any issues at all?
2. Tell me how good can a newer language be when if you delete a button on a form, it can't hitch back up to the procedure that it is connected to?
3. Someone PLEEEASE explain to me how good a newer language can be when running certain operations in a form load procedure can throw "invisible" exceptions that don't get trapped?
4. Show me how a newer language can sample a point of color on a control with obj.Point(), where the newer one makes you have to do:

Code:

---

Function PickColor() As Color
        Dim rBT As New Rectangle(0, 0, 1, 1)
        Dim Bit As New Bitmap(rBT.Width, rBT.Height, Imaging.PixelFormat.Format64bppPArgb)
        Dim g As Graphics
        g = Graphics.FromImage(Bit)
        Using g
            g.CopyFromScreen(Cursor.Position, Point.Empty, rBT.Size)
        End Using
        Dim PixelColor As Color = Bit.GetPixel(0, 0)
        Return PixelColor
End Function

---

5. Someone please tell me why every time I set up my forms and code tabs all nice and where I want them, that the newer language forgets everything the next time I open the project, simply because I changed the name of the folder. How stupid can a language be if it can't see that all of the project's resources are all still contained within the same folder. Do I cease to function just because a room that used to be painted white is now painted blue?! J Fing C!

6. Please tell me how a "Cancel" button's click procedure event fires normally, with errors in it (variables that aren't declared yet, but also aren't referenced anywhere yet), but an "OK" button's click procedure won't fire at all when all that is in it is "Me.Close()"!

If this is someone's definition of a better, "new and improved" language, then I guess the concept of productivity is passe.

Believe me, I can keep adding more items till the RTB can't hold anymore characters, but it's late and I'm tired of having wasted 1 hour on a problem that shouldn't even exist.

I think you should just go back to VB6 so I never waste minutes of my life reading another post like this one.

1) I just backup my projects more often then I do in VB6. ;)

2) True but you can also hook up multiple controls of the same or different types to the same procedure, if you delete one of those controls vb.net will only remove that control from the Handles clause. IMO the Pros easily outweigh any Cons.

3) I believe that is only true in 64-bit mode which VB6 can't even do! FYI most apps don't need to be compiled as 64-bit unless they need to access huge amounts of ram, otherwise compile as 32-bit even when OS is 64-bit.

4) ? I don't know off-hand, but I doubt its impossible.

5) True but VB.net remembers bookmarks, what code windows were open and where you you were editing last, etc, etc, about all VB6 remembers & restores is which forms were left open. :rolleyes:
Renaming folders/projects isn't as easy (not impossible), but .net does way more then VB6 can, (just zip-up your project folders), IMO the Pros easily outweigh the Cons.

6) All I can suggest is you read up on vb.net and forget how things worked in VB6. :)

:duck: :duck: :duck:
If you can live with VB6's shortcomings then maybe you should just stick with it. I hated vb.net until 2010 came out, I gave it another chance (stuck with it for 2 weeks), after I got over the learning hump I was hooked, tho I still use VB6 its very-very rare, it just feels like I'm coding in notepad.

I think you just have bad luck. If you don't like the language, then go back to what you were comfortable with. You can ask a ton of questions that come from you having problems, but most of us here have not had those problems.

So, I'm gonna take the time real fast to take your post and answer your six points.

Quote:

---

1. Please tell me what is so wonderful about a programming language that it can get so easily screwed up this way, where the previous language never had any issues at all?

---

No true multithreading, no 64 bit compatibility, uses COM (older architecture).

Quote:

---

2. Tell me how good can a newer language be when if you delete a button on a form, it can't hitch back up to the procedure that it is connected to?

---

"I'm going to delete file.txt now Windows!" *deletes and recreates it* "WHY ISN'T MY TEXT BACK IN HERE, THIS OS SUCKS!"
That's kind of the same thought process. Visual Studio does keep a naming convention for the events it creates (which should be fairly obvious). However, if it sees that method exists, it's going to create a new one by default. Nothing stopping you from changing it to whatever you want. That's not a bug, it's supposed to do that.

Quote:

---

3. Someone PLEEEASE explain to me how good a newer language can be when running certain operations in a form load procedure can throw "invisible" exceptions that don't get trapped?

---

This is not a language problem, but an OS problem on x64. Please do some research on your problems. EDIT: Here's a fantastic write up of the problem you're describing.

Quote:

---

4. Show me how a newer language can sample a point of color on a control with obj.Point(), where the newer one makes you have to do:

---

Someone please show me how to do true multithreading in VB6 when in .NET I can do...

Code:

---

Dim th As New Thread(MethodName)
th.Start()

---

What's your point? It takes extra lines to do that one thing. So what? That's nitpicking. If you feel that bad, then just wrap that into a method call and then it becomes a single line of code for you to call anyway!

Quote:

---

5. Someone please tell me why every time I set up my forms and code tabs all nice and where I want them, that the newer language forgets everything the next time I open the project, simply because I changed the name of the folder. How stupid can a language be if it can't see that all of the project's resources are all still contained within the same folder. Do I cease to function just because a room that used to be painted white is now painted blue?! J Fing C!

---

If you changed the folder name within the environment, then no, you don't. However, if you changed it via Explorer, VS still is looking for that old folder. I've had several forms go boom boom randomly for all sorts of reasons (Designer file went corrupt/missing is a notorious one I've had happen a few times). Did I blame the language for an IDE mistake? No.

Quote:

---

6. Please tell me how a "Cancel" button's click procedure event fires normally, with errors in it (variables that aren't declared yet, but also aren't referenced anywhere yet), but an "OK" button's click procedure won't fire at all when all that is in it is "Me.Close()"!

---

No code, no answer. I can't magically answer a question when I can't see what you're talking about because it seems like your code is nto actually compiling and you are using a previously compiled version which Visual Studio will usually tell you it will if a compilation fails and even asks you if you want to use it.

I hope that clears the air with your silly questions. JMC appears to have given up on humanity for the time being.

Well, first off. Sorry for the rant. It was late, I was tired, and not in the mood to not be able to finish up a last bit of code before going to bed.

With that said, I still see things a certain way and I don't see that changing, so I do not think that .Net is for me. I used it this time only because I had to...I have the need for Unicode controls (which MS in their infinite stupidity did not create, even though under the hood, vb6 is thinking in Unicode!). So I had three options; stick with vb6 and create my own user control with Unicode support, stick with vb6 and get screwed by the ridiculously high cost of Unicode controls for vb6, (which cost way MORE than a standard Visual Studio itself!...Yah! I'll jump on that wagon...NOT!), or simply port this program over to .Net and be done with it. Time-wise, the latter was the quickest, most sensible approach.

But here is my take on the whole vb6 vs. vb.Net controversy. This is a long read, so I offer it as an attachment:

Attachment 98601

Quote:

---

Originally Posted by treddie

Well, first off. Sorry for the rant. It was late, I was tired, and not in the mood to not be able to finish up a last bit of code before going to bed.

With that said, I still see things a certain way and I don't see that changing, so I do not think that .Net is for me. I used it this time only because I had to...I have the need for Unicode controls (which MS in their infinite stupidity did not create, even though under the hood, vb6 is thinking in Unicode!). So I had three options; stick with vb6 and create my own user control with Unicode support, stick with vb6 and get screwed by the ridiculously high cost of Unicode controls for vb6, (which cost way MORE than a standard Visual Studio itself!...Yah! I'll jump on that wagon...NOT!), or simply port this program over to .Net and be done with it. Time-wise, the latter was the quickest, most sensible approach.

But here is my take on the whole vb6 vs. vb.Net controversy. This is a long read, so I offer it as an attachment:

Attachment 98601

---

Just so you know, I actually took the time to read your entire document. You have quite a few arguments that need to be addressed because you misunderstand several things not only about VB.net, but about .NET in general, and the differences that lie between VB6 and VB.net

Anything below this line is of my opinion and what I believe to be true. You may take it as you want, or however you feel is necessary. I am just going to express my opinion.

The first thing you really need to understand is that VB.net is not a true continuation of VB6 (IMHO). VB.net is the successor to VB6, which has similar features of VB6, such as the more verbose syntax, but it has a much stronger flexible use case than VB6.

So let's get through this document one question at a time:

Quote:

---

1. What is the vb programmer confronted with in terms of tools and methods?

---

You compare the original VB syntax for a subroutine:

Code:

---

Private Sub Button1_Click()

---

That's very simple. However, what if I want to run the same code inside a different button? I can't just tack it on, can I? I have to make another routine and execute the same code (or if I were smart, I'd wrap the code into another subroutine and call the method from each button click handler). However, in .NET, I do not have to do that anymore!

Code:

---

Private Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click

---

Do you see the end of that statement?

Code:

---

Handles Button1.Click

---

That's...pretty powerful in itself! I can stack multiple buttons to one routine! Whoa! But..how do I know what button was clicked?

Code:

---

ByVal sender As Object

---

See that Sender? That's the BUTTON control that actually called this method. You say it's more verbose, but you now have more control over your own code this way. Instead of having 10 different buttonX_click routines, I can route everything through one and then just figure out which button actually was called with one line:

Code:

---

Dim btn As Button = CType(sender, Button)

---

Now I have the exact button that called this event. You call it more verbose, and that it's extra typing, but...the IDE will almost always generate that code for you if you just double click the button in the designer. So the excuse that it's more lines to type is out the window when the tools utilized in development actually do most of the heavy duty for you.

What you're asking .NET language developers to do is the following:

1. Break syntactical styles to satisfy an older language
2. Revert to an older language simply because VB6 programmers don't want to double click a button.

That is not going to happen. Look at C#! Look at F#! They all follow, generally speaking, the same type of syntax (just different in how it's declared). If you are honestly so worried about typing a ton of extra code (which the IDE does for you on its own), then write wrapper methods.

You also have to realize, your case statement about built-in functions being slower, is sometimes actually true. Some functions just pass through right to the API, but sometimes there's overhead/overloaded functions called which does involve an overhead surprisingly (or, really not surprisingly). I find it appalling and rather counter-intuitive that there are people that think like that! If you happen to actually look at a call stack of some functions, it can go several layers deep, and then that has to be unwound to get back to the calling method to give a return value/throw an exception/whatever it needs to do! It's not an easy task sometimes.

As for the following:

Quote:

---

...there is no function in vb.net that cannot be duplicated in some vb6

---

Show me a true, perfect multi-threading environment in VB6.


Unfortunately, my time has run out to answer your questions, but I shall return with another post to systematically answer every one of your questions. It's going to take me awhile to do it, but I shall do it so I can correct your misunderstandings you have of VB.net!

Hey, formlesstree4,

Thanks for your response.

I respect your opinions, and here is my take on your thoughts.

Quote:

---

VB.net is not a true continuation of VB6 (IMHO). VB.net is the successor to VB6, which has similar features of VB6, such as the more verbose syntax, but it has a much stronger flexible use case than VB6.

---

Response1:
I somewhat agree with you in that statement. I have never thought of vb.Net as a continuation of vb6, but I have also never thought of it as its successor any more than a truck is a successor to a car. They're just different animals. Unfortunately, they threw out the "simplicity layer" at the front end, and lost some of there market share with it. I see no logical reason why vb.Net could not have been a sort of context aware language, that just by recognizing how much verbosity the user includes, alerts the framework that he has chosen either a stripped down, less flexible usage of a method, or an "all-balls" approach.

Quote:

---

You compare the original VB syntax for a subroutine: Private Sub Button1_Click() That's very simple. However, what if I want to run the same code inside a different button? I can't just tack it on, can I?

---

We are both correct. In my original attachment, I stated,

Quote:

---

If it is to be modified by the user, there is no reason why that cannot be added as an ADDITIONAL feature to the "base", default syntax.

---

My Response1, above, is in keeping with that quote. By eliminating a dual-layer (or even multi-layer) approach to vb.Net, MS essentially created a socket wrench kit and eliminated the 1/2" and 9/16" sockets...The two most-used sockets in a tool kit.

To help newcomers migrate to this different form of vb (I'll just call it, vb.Netx, from now on), the Help System could have been organized by listing the stripped-down syntax first, followed by the verbose syntax, followed by a discussion on the merits of both, and when to use either. If I know I am only going to use an event procedure for only one control, I do not need to fuss with that deeper level of control, but such a Help System will always make the user aware that there is a deeper layer he can take advantage of, if necessary.

Quote:

---

the IDE will almost always generate that code for you if you just double click the button in the designer.

---

That is only true for the DEFAULT event for that control, as I stated in the attachment:

Quote:

---

... it is not always easy to create those extra terms when double-clicking a control will only create the default event for that control. Which means you have to go search down what the correct parameters are for the sub's definition for any other event for that control. In short, much more time is spent searching for additional terms that aren't really necessary in many practical situations.

---

That is especially true since, most controls have a LOT of associated events.

For instance, double-clicking a button will create the default button_Click() procedure. But what if I don't WANT the Click event handler? What if I wanted a MouseHover event instead? To make matters more complicated, and using mouse events as an example, the arguments are not always the same:

Code:

---

Private Sub Form1_Mouseup(ByVal sender As System.Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseUp
End Sub

Private Sub Form1_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.MouseEnter
End Sub

---

Therefore, your argument,

Quote:

---

1. Break syntactical styles to satisfy an older language
2. Revert to an older language simply because VB6 programmers don't want to double click a button.

---

does not hold. A multi-layer approach to syntax does not "break" style, but offers the user a practical choice, and double-clicking a control will only create the default event handler, but not the zillions of others.

Quote:

---

Some functions just pass through right to the API, but sometimes there's overhead/overloaded functions called which does involve an overhead surprisingly (or, really not surprisingly). I find it appalling and rather counter-intuitive that there are people that think like that! If you happen to actually look at a call stack of some functions, it can go several layers deep...

---

I completely agree. But there are times that even though, for example, drawing lines to a control with the Line method is dog slow compared to a pure API set of code, that is not really an issue when the graphics are simple. If on the other hand, I will be drawing THOUSANDS of lines to a control, then I am in trouble. But context is everything. If I need to build a really quick calculator with light graphics support (and I do a LOT of that), there should be no need for me to worry about the Paint event and the code that goes with it. BUT, I want to know that the language will allow me to go deeper when I require it (I occasionally build large apps that need that level of control. Traditionally for me, I then lean on the API rather than vb.Net because it seems to me to be about the same level of work involved). That puts the ultimate level of control in the user's hands where the language does not force him into one style or another. This is where vb.Net's "flexibility" becomes inflexible.

In your response to my statement, "...there is no function in vb.net that cannot be duplicated in some vb6" where you say,

Quote:

---

Show me a true, perfect multi-threading environment in VB6.

---

I refer you back to my attachment, where I state:

Quote:

---

There was absolutely no reason why many of those deficiencies could not have been corrected and optimized [in some vb(n)].

---

---------------
At any rate, I appreciate the debate...and your willingness to read the attachment, and your time. I piss people off some times, but one thing I can always say about the time you guys spend helping us all out with programming questions means you are all under-appreciated by some. But not me.

Quote:

---

Originally Posted by treddie

Hey, formlesstree4,

Thanks for your response.

I respect your opinions, and here is my take on your thoughts.



Response1:
I somewhat agree with you in that statement. I have never thought of vb.Net as a continuation of vb6, but I have also never thought of it as its successor any more than a truck is a successor to a car. They're just different animals. Unfortunately, they threw out the "simplicity layer" at the front end, and lost some of there market share with it. I see no logical reason why vb.Net could not have been a sort of context aware language, that just by recognizing how much verbosity the user includes, alerts the framework that he has chosen either a stripped down, less flexible usage of a method, or an "all-balls" approach.



We are both correct. In my original attachment, I stated,



My Response1, above, is in keeping with that quote. By eliminating a dual-layer (or even multi-layer) approach to vb.Net, MS essentially created a socket wrench kit and eliminated the 1/2" and 9/16" sockets...The two most-used sockets in a tool kit.

To help newcomers migrate to this different form of vb (I'll just call it, vb.Netx, from now on), the Help System could have been organized by listing the stripped-down syntax first, followed by the verbose syntax, followed by a discussion on the merits of both, and when to use either. If I know I am only going to use an event procedure for only one control, I do not need to fuss with that deeper level of control, but such a Help System will always make the user aware that there is a deeper layer he can take advantage of, if necessary.



That is only true for the DEFAULT event for that control, as I stated in the attachment:



That is especially true since, most controls have a LOT of associated events.

For instance, double-clicking a button will create the default button_Click() procedure. But what if I don't WANT the Click event handler? What if I wanted a MouseHover event instead? To make matters more complicated, and using mouse events as an example, the arguments are not always the same:

Code:

---

Private Sub Form1_Mouseup(ByVal sender As System.Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseUp
End Sub

Private Sub Form1_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.MouseEnter
End Sub

---

Therefore, your argument,



does not hold. A multi-layer approach to syntax does not "break" style, but offers the user a practical choice, and double-clicking a control will only create the default event handler, but not the zillions of others.



I completely agree. But there are times that even though, for example, drawing lines to a control with the Line method is dog slow compared to a pure API set of code, that is not really an issue when the graphics are simple. If on the other hand, I will be drawing THOUSANDS of lines to a control, then I am in trouble. But context is everything. If I need to build a really quick calculator with light graphics support (and I do a LOT of that), there should be no need for me to worry about the Paint event and the code that goes with it. BUT, I want to know that the language will allow me to go deeper when I require it (I occasionally build large apps that need that level of control. Traditionally for me, I then lean on the API rather than vb.Net because it seems to me to be about the same level of work involved). That puts the ultimate level of control in the user's hands where the language does not force him into one style or another. This is where vb.Net's "flexibility" becomes inflexible.

In your response to my statement, "...there is no function in vb.net that cannot be duplicated in some vb6" where you say,



I refer you back to my attachment, where I state:


---------------
At any rate, I appreciate the debate...and your willingness to read the attachment, and your time. I piss people off some times, but one thing I can always say about the time you guys spend helping us all out with programming questions means you are all under-appreciated by some. But not me.

---

To quickly tackle some of your issues you've had with the event generation; the Properties pane that appears when you select a control has a lightning bolt button that shows a list of all available events for the given control. You can double click said event and the IDE will generate it.

I remember reading a thorough rundown as to why VB6 was being dropped in favor of VB.net and if I do find it, I will link it to you here. It was a fantastic read.

Quote:

---

I completely agree. But there are times that even though, for example, drawing lines to a control with the Line method is dog slow compared to a pure API set of code, that is not really an issue when the graphics are simple. If on the other hand, I will be drawing THOUSANDS of lines to a control, then I am in trouble. But context is everything. If I need to build a really quick calculator with light graphics support (and I do a LOT of that), there should be no need for me to worry about the Paint event and the code that goes with it. BUT, I want to know that the language will allow me to go deeper when I require it (I occasionally build large apps that need that level of control. Traditionally for me, I then lean on the API rather than vb.Net because it seems to me to be about the same level of work involved). That puts the ultimate level of control in the user's hands where the language does not force him into one style or another. This is where vb.Net's "flexibility" becomes inflexible.

---

You have to realize the toolset you need, then. WinForm itself runs on GDI+ which is slow (Shaggy Hiker can tell you quite a few things about that and how XNA/WPF would be a far superior platform for graphical applications). But you say you need a few lines, then yes, doing it the way .NET has it is overly complex sometimes. But it's a standard that has to work for not only what you want to do, but what everyone else wishes to do and it has to do it in a concise, predictable, and fluid methodology.

Frankly, I think it makes sense. You don't want to have your code that draws to the form all over the place. Does that make it difficult sometimes? It can, yes. The Graphics object makes most of the drawing rather simplistic, though, and really is a time saver (especially some overloaded methods that take various different .NET structures, such as points, sizes, brushes, and colors).

Any language system has their own way of doing things. VB6 had some easy ways and some difficult ways of doing things. VB.net is the same way, but it's up to the programmer to use a tool that helps them out the most.



EDIT:

I also forgot to mention, in response to this:

Code:

---

Private Sub Form1_Mouseup(ByVal sender As System.Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseUp
End Sub

Private Sub Form1_MouseEnter(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.MouseEnter

---

Technically they are the same. System.Windows.Forms.MouseEventArgs inherits System.EventArgs, so System.Windows.Forms.MouseEventArgs can be cast as a System.EventArgs. This is a type of system where A is B, but B is not always A.

However, you wouldn't want to link a mouse up and mouse enter event together, that doesn't make any sense because you have -no- idea which type of event fired! (at least, I don't think you do).

Sorry for the delay in getting back. I'm totally slammed and will respond shortly.

Quote:

---

the Properties pane that appears when you select a control has a lightning bolt button that shows a list of all available events for the given control.

---

Well then, I can only chock that one up to inexperience. That IS a great feature.

Quote:

---

I remember reading a thorough rundown as to why VB6 was being dropped in favor of VB.net and if I do find it, I will link it to you here. It was a fantastic read.

---

I think I might remember that article. If we are talking about the same thing, it was from maybe 10 years ago, roughly, and he went into length about the obsolescence of the COM model.
Again, if it IS the same article, I feel that what he was talking about was more about what was under the hood and tried to make a connection between that and the new methods available. But a robust kernel shouldn't necessarily negate old methods, since "methods" are really nothing more than hidden procedures that make the method possible. I can place a flat table over an erector set frame, and it will act exactly like a table set over a tinker toy frame.
(OK...metal tinker toys! :)). But the analogy still holds in that how you construct the method is one thing, even though the end result is the same.

Many people state that vb6 should just be another tool in the tool set for a programmer if they find it useful. That WOULD be true if MS was still developing it and hadn't tried to axe it altogether. It will not be too long when it will not be compatible with a newer OS. Then it will be no tool at all.

In response to my part about the two mouse event procedures having different arguments,

Quote:

---

Technically they are the same. System.Windows.Forms.MouseEventArgs inherits System.EventArgs, so System.Windows.Forms.MouseEventArgs can be cast as a System.EventArgs. This is a type of system where A is B, but B is not always A.

---

When I played with that years ago, I could not get both syntax to work.

Quote:

---

Originally Posted by formlesstree4

You compare the original VB syntax for a subroutine:

Code:

---

Private Sub Button1_Click()

---

That's very simple. However, what if I want to run the same code inside a different button? I can't just tack it on, can I? I have to make another routine and execute the same code (or if I were smart, I'd wrap the code into another subroutine and call the method from each button click handler). However, in .NET, I do not have to do that anymore!

Code:

---

Private Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click

---

Do you see the end of that statement?

Code:

---

Handles Button1.Click

---

That's...pretty powerful in itself! I can stack multiple buttons to one routine! Whoa! But..how do I know what button was clicked?

Code:

---

ByVal sender As Object

---

See that Sender? That's the BUTTON control that actually called this method. You say it's more verbose, but you now have more control over your own code this way. Instead of having 10 different buttonX_click routines, I can route everything through one and then just figure out which button actually was called with one line:

Code:

---

Dim btn As Button = CType(sender, Button)

---

---

In VB6 there is the concept of Control Arrays that can do the same, I thought I should just mention it. =)

That's true, but only in a limited sense. You cannot group together different TYPES of controls in the same control array. At any rate, it still shouldn't matter. vb.Net still could have had control arrays without conflicting with vb.Nets approach to letting different types of controls exist under the same event. There are always more than one way to skin a cat, and having control arrays in vb.Net would not have been a haphazard thing at all...Just another tool. In fact, it would have made .Net more flexible, powerful and easier to migrate to. AND, there is no reason why control arrays could not have been expanded to INCLUDE different types of controls.

Quote:

---

Originally Posted by treddie

That's true, but only in a limited sense. You cannot group together different TYPES of controls in the same control array. At any rate, it still shouldn't matter. vb.Net still could have had control arrays without conflicting with vb.Nets approach to letting different types of controls exist under the same event. There are always more than one way to skin a cat, and having control arrays in vb.Net would not have been a haphazard thing at all...Just another tool. In fact, it would have made .Net more flexible, powerful and easier to migrate to. AND, there is no reason why control arrays could not have been expanded to INCLUDE different types of controls.

---

Control arrays existed in VB6 for a reason. That reason doesn't exist in VB.NET, therefore VB6-style control arrays don't exist. If you want an array of controls then you can create an array of controls, just like you can create an array of anything. No language other than VB6 (as far as I'm aware) has design-time support for control arrays and I've never once heard anyone lament that fact. I've never once thought "gee, I wish I could use a control array right now". Is it really a surprise that Microsoft didn't spend the time to add a feature to VS that noone but VB6 developers wanted and even they didn't need?

Hey jmcilhinney, thanks for coming back.

Quote:

---

Is it really a surprise that Microsoft didn't spend the time to add a feature to VS that noone but VB6 developers wanted and even they didn't need?

---

I used them and loved 'em when they were applicable. In fact, this last port-over I did had them. They were simple and quick, just like vb6 could do with so many things. But to say that no one but vb6 developers wanted control arrays, so MS didn't put them in vs is like saying that a fair portion of the 85% of your market share doesn't matter. But also, to me anyway, a language is not about what you don't need, it's about having the extras analogous to power windows that make life easier. Sure, you don't have to put them into a language. But then you don't need If/Else blocks either, when they can be programmed in assembly or added as a function in a dll. So why are they there? They are quick and effective.