Question Dim Noob as object If noob.idiot = true then MsgBox("HELP!", MsgBoxStyle.Critical)

[PhillD]

Dim Noob as object If noob.idiot = true then MsgBox("HELP!", MsgBoxStyle.Critical)

First a little about me, I have been a programmer for 15 years, started in MS Access & Macros and soon discovered VBA. Eventually that led to VB6 with Access Backend. I am completely self taught which is probally the issue here I finally need to take the plunge and learn a programming language Joke! (well kind of!). I’m making the transition to VB.NET and SQL Server and having a hard time.

First off, in VB6 it was perfectly ok to say me.backcolor = “red”, now in VB.NET it is not. We have to think in objects! Me.BackColor = Color.Red. While I understand the concept, I can’t help but ask why? I read somewhere that the eventual goal of programming languages was to be indistinguishable from the human language..Wait a minute! Not in VB.net it’s not, in my opinion it’s going backwards! You would never desribe your car color as color.red, would would say it’s red. Like I said, I understand the concept but it seems redundant. Also, I was told I would write less code in .NET, cough cough, errrm, no sorry that’s not right either. The lines of code are longer and the code overall is more complex.

The second problem I have is with the New keyword. Again, I understand the concept, or thought I did, until I had to write the following VB code that called a stored procedure.

Dim MyConn As SqlConnection
MyConn = New SqlConnection("Data Source=crysis;Initial Catalog=Phantom;Persist Security Info=True;User ID=sa;Password=*********;Pooling=False")
Dim SQLComm As SqlCommand
SQLComm = New SqlCommand("UserLoginSP", MyConn)
SQLComm.CommandType = CommandType.StoredProcedure

SQLComm.Parameters.Add(New SqlParameter("@userID", UserIDEdit.Text))
SQLComm.Parameters.Add(New SqlParameter("@UserPassword", PasswordEdit.Text))
SQLComm.Parameters.Add("@return", SqlDbType.Int)

There are 2 issues here.

If I declare MyConn as a SqlConnection why do I have to set it to a New SqlConnection

Shouldn’t it go something like
Dim MyConn As SqlConnection
MyConn.ConnectionString = "Data Source=crysis;Initial Catalog=Phantom;Persist Security Info=True;User ID=sa;Password=*********;Pooling=False")

That would make more sense to me. The second issue is defining the parameters. This one blows me away! First there is:
SQLComm.Parameters.Add(New SqlParameter("@userID", UserIDEdit.Text))
Why? Could I not just use
SQLComm.Parameters.Add("@userID", UserIDEdit.Text)
Second of all, you do not have to use New when defining the return parameter. Why?

I want to learn VB.NET and be able to write applications. However, with the inconsistencies, I am left wondering how I will ever write my own code without plagurizing everyone elses. It’s hard to learn something if it doesn’t make sense. So if there’s any hints or information you can give me where I might be going wrong, please help me.

Thanks

 

[JohnH]

We have to think in objects!

Yes, you do.

Me.BackColor =

When you type this you are presented with a list of colors, this list is associated with the Color structure (which defines the type for what we commonly refer to as a "color"). After "=" you can type red and the value "Color.Red" is placed in your code by intellisense. This, and similar cases, makes it a whole lot easier to code than to write arbitrary string values that is bound to fail (can you spell "DarkTurquoise"). A lot has been done since classic VB to help write better code faster and ensure better type safety.

Shouldn’t it go something like
Dim MyConn As SqlConnection
MyConn.ConnectionString

Here you haven't created a connection object. SqlConnection is not a value, it is a class and you have to create an object instance of this class to use it.

Dim MyConn As SqlConnection
MyConn = New SqlConnection("conn string")

While this is correct I think that coding style expands the code too much. It is the typical detached VB6 coding style where all variables were declared first, then later they were assigned, and later they were used. In some programming languages one is forced to assign something to a variable when it is declared, this is a good practice that helps to keep the code (and the programmer) focused. You also get less code that only describes the type of objects (more of this later).

Dim connection As New SqlConnection("conn string")

SQLComm.Parameters.Add(New SqlParameter("@UserPassword", PasswordEdit.Text))
SQLComm.Parameters.Add("@return", SqlDbType.Int)
econd of all, you do not have to use New when defining the return parameter. Why?

The second argument here is two different things, in the first line the second argument is the parameter value, in the second line it is the parameter type. Once upon a time you actually could do .Add(name, value) until they figured the parameter and the paramter value was two different things, and they changed this to .AddWithValue(name, value) (which infers the type from the value). You can also use the return value of the Add method (which returns the Paramter object created) and assign the value to that:

SQLComm.Parameters.Add("@UserPassword", SqlDbType.NVarChar).Value = PasswordEdit.Text

I read somewhere that the eventual goal of programming languages was to be indistinguishable from the human language..Wait a minute! Not in VB.net it’s not, in my opinion it’s going backwards!

It will take some time for you to think Object Oriented Programming style, but eventually you will find it logical, and you will also find VS today a whole lot more helpful in development than VB6, this goes for the visual designers (including various wizards) and the code editor. I see your forum profile states you're using ".Net 2.0" now, which indicated VB 2005, I recommed you use VB 2008 (or 2010 soon). Here something called "type inference" is introduced, which allow less type information to be written by you in code. (perhaps misinterpreted, but type information can also be informative to what the code does) Let's say you have a function that returns a Integer result, so instead of:

Dim result As Integer = Calculate(x, y)

you can then type this and compiler infers the result variable type to be Integer:

Dim result = Calculate(x, y)

Without type inference this variable would be considered the default 'catch all' type Object, which is less useful and easily causes type related errors in code.

VB.Net is probably the programming language that closest resembles English language, but it still requires syntax. Option Strict forces you to write type information in code (variable As type), but Option Infer helps you remove the type information without loosing it. You can also have Option Strict off (I don't recommend it) and not declare the type for your variables, but you'll see that intellisense offers no help for your coding when the variable is Object type. You have most likely already discovered that when you have a typed variable you can write "." and intellisense pops up a list of all members that you can use for that type. Here you only need to start writing the member name (or select it in list) and press space/enter/./= to complete the code.

Since your post had several references to manually written data access code I will also mention that today it is less common to write such code. Instead the visual part of development to a great deal can be used and VS writes the data access code for you way faster and without errors. You can easily find video tutorials and walk-throughs for VB.Net data access that teach how to do this.

 

[PhillD]

Thanks

Thanks for the Info. I am sure that over time the object oriented coding will become easier to understand, it's just that from where I came from, right now, it seems unnecessarily more complex. I am currently using VB2008 but it is referencing the .NET 2.0 architecture. That’s how it installed by default, should I change it to 3.5?

I have been using the MS video tutorials and Beginning Visual Basic 2008 by wrox to learn. The book completely threw me off because almost every line of code seems to be written from an OOP angle. Even the calls to the Message Box are different e.g. MessageBox.show(intNumber.ToString,”MessageHeader”)

Why would you need to convert a number to a string for displaying in a message box. Also why would you need MessageBox.show? If your calling a message box, you are going to show it? Like I said, as a noob, just seems completely redundant.

 

[JohnH]

hehe, the messagebox can only display string messages, so other type of data have to be converted to strings to display.. This is not something that has changed, and you can turn off Option Strict to allow code like MessageBox.Show(123), what happens then is that the integer is implicitly converted to string by compiler. There are controls that is designed to keep different types of data in its underlying storage (or references it), but either implicitly or explicitly it is always the string representation of the data you see visually. If you look at the graphics libraries there are methods to draw lines and shapes and strings, but not methods to draw numbers as such.

You can still use VB-runtime function MsgBox by the way, it calls the shared MessageBox.Show function anyway.

should I change it to 3.5?

VB 2008 use .Net 3.5 by default for new projects. Unless you have a reason to limit yourself to .Net 2.0 libraries you should take advantage of any improvements in development tools added in the later libraries. I think perhaps upgraded projects will be .Net 2.0.

 

[PhillD]

Are there any really good references sites/books you would recommend to someone like me? I think part of the issue is because I have been self taught, I learned how to make the language do what I needed it to but never how it did it. Maybe if I understood more about the how it all works, I would understand the syntax decisions.

 

[JohnH]

No, I don't, I use mostly MSDN Library which is really great and extensive and have all kinds of relevant articles, other websites also has much learning material. For structured learning you could take a look and/or ask in the Books - Reading List section of these forums.