Learning Visual Studio Community Edition .NET ?

[Logit]

.
Greetings

First off .. if this is the wrong place for this thread, please advise. Thank you.

Request:

I am seeking online resources (free) that will teach a newbie like me how to use the Visual Studio Community Edition of .NET I need (at this starting point at least) a
"For Dummies" type version. Hopefully it won't take long for me to get up a little speed then I can move on to something more substantial.

Background:

Some years back (20 yrs ?) I dabbled in VB5. Most recently (the past two years or so) I've been concentrating on VBA in EXCEL and have become somewhat proficient with
it. The similarities between VB5 / VBA and this new .NET(VB) will hopefully make the learning curve shorter. Hopefully ?

Any suggestions you may have will be gratefully received !

Thank you so much.

[jmcilhinney]

Your probably not going to find a tutorial on how to use VS and particularly any specific edition of VS. You'll find tutorials on how to use VB and they will often include instructions on using IDE features, e.g. "select New Project from the File menu" or something like that. VS works in the same basic fashion as any other Windows software insofar as it uses menus and toolbars. I would suggest that you start by exploring those to see what is available.

You might try the Tutorial link in my signature below for a basic VB tutorial. Once you've created a project, the available menus and toolbars will change and you should have a further look around. Also check out the various tool windows around the edges of the IDE. At first, the number of tools that you actually use will be relatively small, so you can learn new things a bit at a time. We're here to help along the way.

One thing I would suggest that you make copious use of is the Help menu in VS. The documentation is vast and it is very helpful. You won't always find what you want or understand what you find but the best way to improve in that regard is to keep using it. Use it first and then use other sources if you need more. If you do that and end up posting here, you can always say that you tried the documentation and couldn't find what you needed or post what you did find but didn't understand for clarification.

[Logit]

.
Thank you sir. I truly appreciate your willingness to assist in this regard.

Your comments again sounds a lot like learning VBA ... precisely how I started there. Then I moved to the various VBA Forums ... learned a bunch from the postings of others and receiving answer to specific
questions/challenges I posted.

Lastly, I was able to start "paying it forward" by answering questions of others. Very rewarding.


I've been searching for VB .NET forums and haven't located much of those either. Most that do exist haven't been posted to in months or ... very, very infrequently. This one is by itself regarding
recently activity.

Thanks !

[jmcilhinney]

You might like to check this out as a primer at least:

https://docs.microsoft.com/en-us/vis...ual-studio-ide

I think that VS and even VB is just too big for one dedicated tour through the whole thing.

[Logit]

.
Thank you sir ! Took a glance at it. Looks promising.

Been playing with the first link you suggested. Exactly what I was looking for. The projects are really basic but the purpose here is to learn the new GUI and that's what is occurring.

Already noticed slight syntax variance from VB5 and VBA. My old mind is going to have an issue for awhile remembering what syntax to use since I've been concentrating on VBA for so long.
It will get better.

Thank you again friend.

[wes4dbt]

Visual Basic (.Net) is a lot different than VBA. Sure you have "If" statements and "Do" Loops. But it much more of an Object Oriented language. My first suggestion would be to make sure you set Option Strict to "On". It's in the Project Properties under "Compile". It will make it easier to spot data type errors.

[jmcilhinney]

My first suggestion would be to make sure you set Option Strict to "On". It's in the Project Properties under "Compile". It will make it easier to spot data type errors.

Good advice. You can also set it to On in the IDE Options so that it will be On for all future projects. Keep in mind, though, that some code examples, including those written for beginner tutorials, may be written with Option Strict Off and thus may fail to compile. If that happens, all you need to do is be explicit with your data type conversions. For instance, let's say that you want to get a number that the user has typed in at the console. With Option Strict Off, you can do this:

Dim number As Integer = Console.ReadLine()

With Option Strict On, that will fail to compile because Console.WriteLine returns a String and you cannot assign a String to an Integer variable. Instead of relying on the system to make the conversion implicitly, you need to make it explicit, e.g.

Dim number As Integer = CInt(Console.ReadLine())

That's still going to fail at run time if what the user enters can't be converted to an Integer but at least it makes you think about your data types and you're thus more likely to realise when you're using incompatible types.

[Logit]

.
Yes. Good suggestion. VB and VBA both have "Option Explicit" which has always been 'On' in my workbooks. You are absolutely correct, it makes coding A LOT easier !

I'll get it activated.

Ironically, that has always been my suggestion to newbies on the VBA forums, with an explanation as you have made here.

Thank you again !!!

[jmcilhinney]

VB.NET has Option Explicit and it is On by default. Option Strict is a bit different and is Off by default.

With Option Explicit On, you are forced to explicitly declare each variable with a Dim statement. With Option Explicit Off, you can simply introduce a variable name and it is implicitly declared. To be honest, you'll rarely find a VB.NET developer who ever even considers the possibility that Option Explicit is Off.

Option Strict is all about data types and casting and converting between them. I've never heard official word but I would expect that it was set Off because that meant that a lot of existing VB6 code could be upgraded without generating loads of compilation errors because of implicit conversions and late-binding. It may also have been to help beginners get to writing code more quickly. We do find that it can cause a lot of issues too though, allowing people to write code that doesn't make sense because they never really stop to think about data types.

VB.NET also has Option Infer these days, which does confuse some people. With Option Strict On, this line of code is illegal:

Dim myVar

That code requires that 'myVar' be implicitly typed as Object, but Option Strict On doesn't allow implicit typing. If you want that variable to be type Object then you have to specify that:

Dim myVar As Object

If you want it to be some other type then you must specify that. The thing that confuses some people is that, with Option Infer On, code like this is allowed, even with Option Strict On:

Dim myVar = Console.ReadLine()

The reason that that is allowed is that the type for the variable can be inferred from the expression used to initialise it. The Console.ReadLine method returns a String so the compiler knows that the variable can only be type String. Type inference only works when the variable is declared and initialised on the same line. For instance, this is not allowed:

Dim myVar
 
myVar = Console.ReadLine()

[passel]

... With Option Strict Off, you can do this:

Dim number As Integer = Console.WriteLine()

With Option Strict On, that will fail to compile because Console.WriteLine returns a String and you cannot assign a String to an Integer variable. Instead of relying on the system to make the conversion implicitly, you need to make it explicit, e.g.

Dim number As Integer = CInt(Console.WriteLine())

That's still going to fail at run time if what the user enters can't be converted to an Integer but at least it makes you think about your data types and you're thus more likely to realise when you're using incompatible types.

Since WriteLine is not a Function, I think it will fail regardless. Subs don't return values.

And in the later post....

.... With Option String On, this line of code is illegal:

Dim myVar

...

Fast typing fingers obviously. I'm pretty sure you meant "With Option Infer On"..., or perhaps "Option Strict", I'm not sure now.

[Shaggy Hiker]

Option Infer being ON means that the IDE will attempt to figure out which type a variable should be, so you can often leave out the As clause. I've heard a few people say that it should be OFF (the default) for people starting out, such that they have to explicitly state which type they want a variable to be. I'm not so convinced of that. If you just declare a variable, you HAVE to give it a type, regardless of Option Infer:

Dim myVar As SomeType

Where Option Infer is useful is if you were to declare a variable and initialize it in the same line:

Dim myVar = SomeFunctionThatReturnsAValue()

In the latter case, the type of myVar will be set to whatever type the function returns. This can be pretty useful, because there are times when you don't know what type a function will return. In fact, Option Infer is there largely because, with LINQ and Lambdas, it is possible to have a method that returns no real type at all, but makes up an anonymous type just for that situation. But it is convenient when starting out, too. For example, if you were to write:

Dim myVar = CDec(someValue)

it wouldn't surprise you that myVar is type Decimal, because that's what CDec returns. So all you've done in that example is save a few keystrokes. On the other hand, if you were calling a more complicated method, you might not be quite sure what type it returned. Sure, you can usually look it up, but sometimes it's easier to just write out something like:

Dim myVar = SomeMysteriousFunction()

then hover the mouse over myVar and see what type it is. This isn't something done at runtime, this is done right away, so as soon as you type it, myVar has a type, and hovering the mouse over myVar will show the type.

You can decide for yourself which way you want Option Infer. Option Strict is just good. Option Infer is more a matter of opinion and taste.

[Logit]

.
Phew ! Perhaps I should stick with VB5 and only "Option Explicit". Certainly not as much to keep up with.



Microsoft doesn't understand how feeble my mind really is .....

[Shaggy Hiker]

One of the nice things about it is that you don't HAVE to learn anything. Sure, it would be better to have Option Strict ON, but if you don't....you'll survive. Your code will run a bit slower, but it is VERY unlikely that you will actually see that. Most programs spend the bulk of their time waiting for the meat bag at the keyboard to type a key. They can do a thousand things between keypresses even if you are a fast typist. So, if some function takes 0.1 ms rather than 0.05 ms, you never notice anyways, because we perceive both of those as INSTANTLY!! Option Strict OFF would also allow for a few bugs to creep into the code, but you'd just end up fixing those. It's not like you won't have bugs with Option Strict ON, you'll just have a few more and of a different type.

Option Infer has even less of an impact. Leave it on, turn it off, it's just a matter of preference.

The BIG difference between VB5 and .NET is the Object Oriented nature. You've used that to some extent already. A form is a class in either language. In something like Excel, you've used rows, ranges, cells, and so on, which are all classes, whether or not they are CALLED classes in the language. So, you've used it already, it's just that .NET is much more in-your-face about it. If you take to OO, it will be easy. If you find OO to be a difficult concept, then it will be hard. Only time will tell on that one.

[Logit]

Thank you for the encouragement !

(Perhaps this Geritol pill will help ...)

[wes4dbt]

Not to through fuel on a fire but if going to be working with data, like databases, then you'll find ADO .Net to be different from ADO and DAO that is used in VBA and VB6. I came from a VB6 background and was shocked how much different the two languages are. It was a lot of work but I'm glad I made the switch. I really feel it has made me a better programmer. The one thing for sure is don't go back to VB5. VB6 with sp6 (I thinks thats the last update) is about as far back as you can go.

[jmcilhinney]

Since WriteLine is not a Function, I think it will fail regardless. Subs don't return values.

And in the later post....
Fast typing fingers obviously. I'm pretty sure you meant "With Option Infer On"..., or perhaps "Option Strict", I'm not sure now.

Oops and oops! The first should have been "ReadLine" and the second should have been "Option Strict". Both fixed now. Damn autocorrect!

[jmcilhinney]

In fact, Option Infer is there largely because, with LINQ and Lambdas, it is possible to have a method that returns no real type at all, but makes up an anonymous type just for that situation.

Option Infer is there SPECIFICALLY because a LINQ query can return an anonymous type. It is convenient to use it elsewhere too but it is essential for use with anonymous types so it's no surprise that the two were introduced at the same time. That's also why it's on by default. Having Option Strict Off by default doesn't stop you doing anything, i.e. any code that will compile with Option Strict On will also compile with it Off. In the case of Option Infer, there is code that will compile with it On that will not compile with it Off.