10-4 Episode 9: Visual Basic 10

Wow. 

Nice video again.

Unfortunately I don't see the (all) new features as an improvements.

Ok, not having to use the line-continuation character is nice as well as the auto properties, but things like (multiline) lambas just make the code more difficult to read.
The same with 'anonymous types'...
Maybe it is because I haven't seen a good example where the features mentioned above are usefull.

But ofcourse it's up to the programmer to use it or not.

Love the new array and dictionary literal syntax!  Thanks for the video, Jason!

Good point. XML literals was a very good feature which I certainly hadn't seen before.

Two things,

You can initialize an array in VB9 on one line: Dim scores() as Integer = {42, 59, 72, 100}

You can't have default property values, but you can have a default value for the member variable that the property wraps.

Also, I fail to see the usefulness of automatic properties.  How is it different than just declaring the member variable as public?

Is VS2010 going to include the feature where all your tool windows may decide to randomly cascade all over the screen upon entering debug mode? Cause I must say, I need this feature. What else would I do with my spare time if I didn't have to sit there and re-position 300 tool windows?

Hey Jason, the video is excellent -- one small comment though... while I know you want to promote your future videos, a description of them probably doesn't belong here.  It'll hinder searching. 

And if that's the most I can find to nit-pick on, then you're doing great.

I agree that we need a better window management experience. I absolutely do need the layout to be context sensitive in that when I'm writing code debugging windows like the watch or the call stack are useless and should be kept out of site and when I run my program the design window, toolbox, and solution explorer probably aren't very useful. I think it's good that the VS team understands that different tool windows may need to be different places in context but we need a more explicit way of managing that. I would like to see named layouts and allow me to have more than just two. I work in multiple roles with VS and some roles and tasks need to emphasize a certain layout.

Another reason the Auto-Implemented Properties are useful is because databinding doesn't understand fields. If you want to use Binding in Windows Forms and WPF you have to explose the data as a property.

I'm totally waiting on multiline lambas and anonymous types... wish I had them yesterday! Is it too late to change the product to Visual Studio 2009?

1.) I think multiline lambdas are a good thing. You can make much more things like writing a function like CatchAndProtocolException.
I am building a try catch block around every function that is started directly from the GUI and catch the Exception whatever it is. Then I protocol it and give a message box. I am making software for special hardware where you can not test at home and if you ask 2 of the customers what happened before the error I am getting 3 completely different answers, so exceptions that are written to a protocol file with using the .pdb file to get the line number ist the only way to find some bugs.
Another Function could be ExecuteAndProtocol which takes a Message and a Lambda of the code. This can really be useful some time when my code contains more protocol entries then real code.

2.) I think the auto implementing properties was an invention of the C# guys. Making Public Variables is not good style. The programmer writing the external code does not need to know which property only gives back a variable and which does a calculation as long as the calculations are simple (I am always having trouble which some COM Servers that have read properties that do write operations and adding a watch changes the output of the program or some GUI that are doing IO operations with a timeout auf 10 seconds).
Is there a way to make an auto implementing property readonly or writeonly. I saw in a previous video that you also get a private variable with a leading _. This is the most important case that you have a private variable that you make readonly available to external code.
It would also be good if you could have an option to make the getter auto implementing and the setter not or the other way round.

3.) I think that you always should explicit declare a variable and not write code like "Dim counter=5"
In this case it should be easy to read, but if you have not 5, but another variable oder even a function you can not see very easy which type of variable you have. If you are using a function and then change the return type you maybe are maybe getting an error much later.

4.) Are there some of this features available when targeting the .NET Framework 2.0 or 3.5? The problem is that nearly everybody has .NET 2.0 because he will need it everywhere, but only few people are having .NET 3.5 and if .NET 4.0 is new it will be worse, so most of my programs will target .NET 2.0. In many cases the customer does not have the rights to install a new .NET Framework and often I would not do it even if it would be possible because it is a big change to the system and if the installer fails (which happens sometimes) the whole system of the customer would have to be reinstalled and if this happens on the server I have got a big problem.

P.S.: What VB really needs is a way to combine the "For To" with the "For Each" loop. I always start with a "For each" loop and end up with a "For To" loop because I need an Index (for example if I am taking data from one array/collection to the other). There should be a way in the "For Each" loop to get the current loop count.

1)
Dim x = True ? "Jason" : "Olson"

2)
Sub DoJob(str As String Where str.Length > 15) As Object
End Sub
- or -
Sub DoJob(ec As EntityCollection(Of c As Contact Where c.FirstName.StartsWith("a")) Where ec.Count > 26)
End Sub

I donno if the following 2 issues are in the right place anyway I think they're needed.
3)
Sub DoJob
   Dim tb As New TextBox
   Dim prop As Boolean = tb.HasProperty("Text") 'HasProperty should be an extension method then I can use the above
Sub DoJob As Object Where Abc.HasProperty("asdf") (+ intellisense exposing that property, sorry for being rediculus lol)
I think it's about time to include these methods (HasProperty etc. in object and not wait for me to include all my extensions, it should be in .NET!).

4)
Entities (in Entity Framework) should be able to inherit from external classes providing functionality to override, overload and shadow fields (as for now entities can only implement interfaces, this is a big issue because interfaces can't actually do anything)!!!
5) - continuation of the above
entity fields should be able to be custom types (providing an IEntityConverter etc. (just saying) interface).
example:

Interface IEntityConverter(Of TSource, TTarget)
   Function Convert() As TTarget
   Function ConvertBack() As TSource
End Interface

Structure Phone : Implements IEntityConverter(Of String, Phone)
   Public ReadOnly Property Extension As String
   Public ReadOnly Property AreaCode As String
   Public Property Number As String
   Public Sub New (phone As String)
   Public Function Convert() As Phone Implements IEntityConverter(Of String, Phone).Convert
      Return Me
   End Function
   Public Function ConvertBack() As String Implements IEntityConverter(Of String, Phone).ConvertBack
      Return Number
   End Function
End Structure

'Usage:
Using data As New Entities
Dim p As Phone = (From c In data.Contacts Select c.Phone).First

notice that phone in the database is a plain string of course
same should be mapping to classes and interfaces

That's all I have for now (I have a lot but don't remember right now), I'd love to hear how fool (or not?) I am...

3.) I think that you always should explicit declare a variable and not write code like "Dim counter=5"

Are you sure?? sometimes I am sure about the result and I even write things relying on VB implicit:
Dim i As Integer = "45"
or
TextBox.ScrollBars = 3-2
TextBox.IsMultiLine = 5
I never had bugs with it and it's very useful, I would even tell u that this is one of the reasons I didn't leave VB after the un-implementing auto props flop in 2008 ver.

Oh, another cool example:
Sub Form_Load(sender As Form, e As EventArgs)
'now you have full intellisense, in cs you have to explicitly cast it.

But all this is in my humble opinion and experience I might be wrong.
thanks

Qoute:
Ok, not having to use the line-continuation character is nice as well as the auto properties, but things like (multiline) lambas just make the code more difficult to read.
The same with 'anonymous types'...
Maybe it is because I haven't seen a good example where the features mentioned above are usefull.

When u will want to use long inline delegates you will have big pain on writing everything in 1 line.
letting VB go a bit out the box regarding lines, about the readability, again, you're wrong there is End Function made just for you!

And I would tell Jason Rock! great vid, waiting for more!

Actually I think that in Wpf when you bind data it's binded to properties only (I am not definately sure).
Donno if applying attributes on properties will work on private fields as well as exposing properties with BrowsableAttribute for the desiner in a custom control.
these examles should be checked i am not sure they're even relevant.

But as Jason said, properties became a convention of encapsulation...

I also have pain with the 08 version regarding Code snippets and project templates, they are based in the Program Files folder instead of being in the Documents.

so everytime I reinstall my OS I have to play around with the snippets and the templates, it's a real pain (I edited many existing default  snippets and templates of VS).

I hope this is the right place to post about it after all not i started to talk about.., any referrals will be appreciated anyway.

Ok call this stupidity, ignorance, or that I am just a noob VB Programmer

Property FailingScore As Integer

Aren't I correct in assuming all you did here was just declare a variable named FailingScore? you just replaced Dim with Property

When I think of Properties, I think of working with Classes that use Get and Set while working within a Property/End Property.

So the question is, what is the difference here that I seem to not understand?

Are you sure?? sometimes I am sure about the result and I even write things relying on VB implicit:
Dim i As Integer = "45"
or
TextBox.ScrollBars = 3-2
TextBox.IsMultiLine = 5
I never had bugs with it and it's very useful, I would even tell u that this is one of the reasons I didn't leave VB after the un-implementing auto props flop in 2008 ver.

Oh, another cool example:
Sub Form_Load(sender As Form, e As EventArgs)
'now you have full intellisense, in cs you have to explicitly cast it.

But all this is in my humble opinion and experience I might be wrong.
thanks

1.) Why should I write things like i as Integer="45"
If 45 is a constant, than I could leave out the " and if it is a function that returns a string, then I always use Integer.Parse() because there can be an exception when converting. If I am sure there will be only an integer from the function I declare the return type as integer and parse it in the function itself.

2.) And you really think that anyone can read that code if you write TextBox.ScrollBars = 3-2 You maybe know that 3 means both scrollbars and 2 mean vertical, but if someone else has to debug your code 5 years later he will have enough problems following the meaning of the code itself so he can not look up a constant every time. If you want horizontal scollbars then write Scrollbars.Horizontal

3.) If you do not set things explicit you will end up where you were in the old VBA with option explicit off. You mistype a variable and it declarates a new one automatically. You write a function that has a syntax error, but dont bother you dont compile it so you will not notice it for a long time. Everything is also returned as Variant and you build super code and if you are debugging it you will notice that it will not work because a function takes only an integer or double and not a date.

4.) I also write code like
If MessageHandled = True Then
  'Do Something
EndIf

It is not because I dont know that I can leave the = True out, but I think it is better readable.

It is a convention that you use properties for data access to other classes. It is good style to use Properties because you can simply change it.
If the Property is called FirstName then the variable is called _FirstName. If you see a variable if _ at the first character you know that it is a class member.
I also started to put a Me. in front of every thing I access in the current class like variables, properties (if used from internal code) or functions.

Take it easy brother, I just brought plain examples, forget about the specific data.

1) I would never use Dim integer = "45", I just meant that you don't need to explicitly convert anything, and yes, sometimes when you are sure that the String's value is actually an integer you don't have to pass it to another Parse function.

2) Enums in vb can be automatically used as plain integers so u can use it in some cases even to make some calculations and conditions according to the order of it, not only but I make the numbers in my enum according to the desired calculations I expect later, u can even use bit shift if you have very large enums with key values so u make the key values 8 16 32 and use bit shift etc. again, I just brought you examples to explain what I said but the examples are not the code, so chill about it.

3-4) I don't; Instead I write comments on every line.
And no, don't learn from me, this is just my taste, and if you really want to hear, sometimes I could write
Dim x As Integer
If x Then
Console.WriteLine("x <> 0") 'Will never reach this line since x = 0.

With the above example I mean 2 things, 1st, that integers can be evaluated as booleans, and 2nd, you can rely on the fact that integer is not nullable and bacomes automatically 0 when declaring the field.
Especially, this days that you can oficcially declare Dim x = 5 and the compiler automatically recognize it as integer and even provides full intellisense support.
I would agree with you concerning the readability issue, but I told you I am good with comments, besides I am not working with a group, so I am the one who decides about the coding conventions, and I do have strict conventions.

I would also say "Different strokes for different folks".

Personally, that's why I like VB, FLEXIBILITY!

Thanks for your post, would like further discussions

Best regards,
Shimmy Weitzhandler

I dont want to say that you write bad code, only that it is not good style in most cases if you write such code.

1.) Yes you can do it, but I dont think that it is a good idea. As I said before if I use Integer.Parse, then everyone can read in the stack trace what went wrong. In most cases I can put it to the user directly.

2.) I also did such things. For example in my own TCP message protocoll. The first byte defines the Type of the Message, the next 4 bytes the length and the rest is the data. The messagetype is an enum that is edited for each application individually. That is the reason why you can define an Enum as a byte, integer and so on and I think it would be a good idea to also allow other types because in some cases you need it. You often get some error or status codes that are not always integers, but also bytes, strings etc.

3) If you write a Console Application this is an option, but if you only have a GUI, than this would be a bad idea because the user will never notice it and you will work with wrong data. Making a message box everytime is also not good every time because if you use it in a timer that is executed every 100ms then it also be not really good
I prefer throwing an Exception. For example: Throw New ArgumentException("Error when doing action xyz: Variable x <> 0")
If the error comes because of wrong data from the user, then he will in most cases know what he did wrong.

4) I also use the 0 value als Null Value in some cases. For example when I am writing a performance database application and want to get the ID of a column like "select Person_ID from Person where Person_Firstname='John' and Person_Lastname='Doe'" and Person_ID is an identity(1,1) then can not be 0, but if I want to set the value to 0 I explicitely do it. "Dim x as Integer" means that I declare a variable x that has not a value yet. If I write "Dim x as Integer=0" then that means, that I set the initial value to 0. Both statements produce the same output, but it is clear what the convention is.

5) I am also working alone and defining the conventions myself, but you also have to think of the poor guy that will have to debug your code in 5 years when you are maybe having another job or maybe you are the poor guy and you dont have an idea what you did.

6) If I write Dim x = 5 then the compiler automatically makes an Integer, but maybe you wanted an UInteger to not allow negative values because it make no sense or an Int64 or maybe you want to have a double. Maybe you start with Dim x=3.14 and then change the 3.14 to 3. This will not only change the initial value, but also the full logic of the program if you write x=47.11 later and then you have problems because only 47 is saved.

7) In your example Both Toolbars = 3 and this is the same as Horizontal + Vertical, but I do not know if this was the intention of the person who defined the values. For example if you use the SerialPort Class with the Stopbits Enumeration. 0=0 Stopbits, 1=1 Stopbit, 2=2 Stopbits, but 3= 1,5 Stopbits.

Cool Jason. I love you when you turn your intelligence towards VB. You belong to us

I am disappointed by the loosening tendency that started with anonymous types and type inference. It continues to grow turning slowly vb.net into vbscript back again. Been there and hoped never to return but it seems it's all about fashion: you have to periodically change everything whether you need changes or not in order to sell news.