Changed coding standards for VB.NET (Office97 et a

Topic

New Reply

I think I’m about to reorgainize my libraries of VBA code. I’ve read from time to time, various articles about VB.Net as it differes from, say VB6.

Although I’m still writing in VBA, it seems as if this might be a good time to clean up my act just in case I want to move to .NET down the road.

What basic, general, things can I clean up as I go, based on your (dear reader) experience?

1) ByVal or By ref are now required as explicit declarations for parameters to Function and Subroutine procedures
2) On Error no longer exists (hooray!)
3) other?

Reply | Quote

Replies

Our site gave up on the idea of converting- but as a large government site, the can afford to. They actually went from VB6 to C#- future releases of VS may well be dropping some VB features which were seen as compromises.

I’d suspect that much of the stuff you may be trying to do would be better rewritten as well- as there are a lot of new (and different) methods for doing the old things in new ways. I’ve had to wrestle with a lot of OO type of concepts, and a completely different way of doing things, but it has been worth it.

Removing “On error” is NOT an admission that code will always run error free. But the “try/catch” construct is a lot more flexible than to “On error”, and can be done at a top level, applying to many levels below, if just standard error conditions are expected.

Reply | Quote

> much of the stuff you may be trying to do would be better rewritten as well-

You’re right. Much of my stuff from over five years back (OK, over three years back), looks horrible. Back in the days when i thought it was smart to pass the name of an object, rather than the object itself.

I think that’s part of my thinking here – if I’m going to rationalise my library code, I may as well clean up as much as I can as I go. It’ll cost, but then working with shoddy library code is expensive, too.

Reply | Quote

Maybe, as a separate thread, you might like to post a simple routine, and have people suggest a way it may be written in VB .Net (or even C#- there’s talk that MS is throwing more support behind C#, despite the talk of .Net supporting all .Net languages)

Reply | Quote

> you might like to post a simple routine,

OK. I’ll do that.

I now have five libraries – UWord.dot, UPPT.PPT, UExcel.XLS, UAccess.MDB and (ta!da!) a general appliaction-independant UGen.BAS.

This last one would be the most suitable candidate; it contains my string-handling, array-handling, numeric hhandling routines; there should be something in there that appeals to the converted converters.

Reply | Quote

Be prepared for some shocks, Chris. A great deal of that is built in with VB.Net. You want to format a string? Format is a method of the string class. In fact, a lot of the functions used to manipulate values in VB/VBA have been recreated as methods of the object classes. Format, Split, Replace, Join, etc.

Reply | Quote

Be prepared for some shocks, Chris. A great deal of that is built in with VB.Net. You want to format a string? Format is a method of the string class. In fact, a lot of the functions used to manipulate values in VB/VBA have been recreated as methods of the object classes. Format, Split, Replace, Join, etc.

Reply | Quote

> you might like to post a simple routine,

OK. I’ll do that.

I now have five libraries – UWord.dot, UPPT.PPT, UExcel.XLS, UAccess.MDB and (ta!da!) a general appliaction-independant UGen.BAS.

This last one would be the most suitable candidate; it contains my string-handling, array-handling, numeric hhandling routines; there should be something in there that appeals to the converted converters.

Reply | Quote

It’s funny that all of the “serious” coders use C#, while VB is left for everyone else. I’ve used both (much more VB than C#) and I could go either way.

In the current version (2003), I find that I can write VB more productively. The intellisense is much more abundant and does not require fully qualified object names in order to pop up. Another small advantage of VB is the With block, which does not exist in C#.

The biggest advantage of C# now is the inline XML documentation feature (//

blah blah

, etc). This allows developers to include descriptions and helpful information within the code component, which will display in the object browser. Unfortunately, the current version of VB does not support this out of the box.

Studio 2005 will add that feature to VB, bringing it up to a par with C# (despite the few minor differences remaining).

Reply | Quote

We started coding in VB .Net- and then converted everything to C#. I’m not sure the reasons for the change- it was before I was directly involved. I did hear that there were some things which could be done in C# which could not be done in VB. And I’m sure there’s no truth to the rumour that the switch was made because C# programmers get paid more .

I used to get caught with the case sensitivity of C++, but I find that I’m almost always using the autocomplete (Ctrl + space)- which I now find to my chagrin was available in VB6 but which I never knew.

Reply | Quote

What a headache. It’s bad enough learning JavaScript to write client-side web page code, keeping straight the differences between VBA and VBScript in the Office and Classic ASP contexts. Now a good number of the code samples I read at Microsoft.com and elsewhere are in C#. Java anyone?

Reply | Quote

One of the nice things about VS.Net is that the help file contains examples in the several development languages, so you can look at the ones for the language you use.

Reply | Quote

One of the nice things about VS.Net is that the help file contains examples in the several development languages, so you can look at the ones for the language you use.

Reply | Quote

One of the reasons I still like COBOL is that it was essentially the same whether I was working on a program for the mainframe, the minicomputer, or a PC. Other languages share this universality, but not C# or VB, in any form that I’m aware of. (I believe COBOL programs were pretty similar on Unix boxes too-but I haven’t worked in it on one yet so I can’t say for sure.)

It’d really be nice to get back to something that just works for a change.

Reply | Quote

OUCH!

Reply | Quote

OUCH!

Reply | Quote

One of the reasons I still like COBOL is that it was essentially the same whether I was working on a program for the mainframe, the minicomputer, or a PC. Other languages share this universality, but not C# or VB, in any form that I’m aware of. (I believe COBOL programs were pretty similar on Unix boxes too-but I haven’t worked in it on one yet so I can’t say for sure.)

It’d really be nice to get back to something that just works for a change.

Reply | Quote

What a headache. It’s bad enough learning JavaScript to write client-side web page code, keeping straight the differences between VBA and VBScript in the Office and Classic ASP contexts. Now a good number of the code samples I read at Microsoft.com and elsewhere are in C#. Java anyone?

Reply | Quote

We started coding in VB .Net- and then converted everything to C#. I’m not sure the reasons for the change- it was before I was directly involved. I did hear that there were some things which could be done in C# which could not be done in VB. And I’m sure there’s no truth to the rumour that the switch was made because C# programmers get paid more .

I used to get caught with the case sensitivity of C++, but I find that I’m almost always using the autocomplete (Ctrl + space)- which I now find to my chagrin was available in VB6 but which I never knew.

Reply | Quote

I have found that making sure all my VB6 arrays are 0 based (ie. dim a_strThing(0 to 3) / dim a_strThing(3) … rather than dim a_strThing(1 to 4)). Because VB.NET doesn’t support anything but 0 based arrays, I found if you used anything but this, your program logic could go a bit haywire in places. This is just one little thing amongs the multitude of things that you can do to make life easier, but it is one thing that I found sped up “converting” code.

Incidentally, I “converted” a medium sized application from VB6 to .NET and I was surprised at how little I needed to initially change to get it working (although I have since changed a great deal to ‘optimise’ it for .NET).

J

Reply | Quote

I have found that making sure all my VB6 arrays are 0 based (ie. dim a_strThing(0 to 3) / dim a_strThing(3) … rather than dim a_strThing(1 to 4)). Because VB.NET doesn’t support anything but 0 based arrays, I found if you used anything but this, your program logic could go a bit haywire in places. This is just one little thing amongs the multitude of things that you can do to make life easier, but it is one thing that I found sped up “converting” code.

Incidentally, I “converted” a medium sized application from VB6 to .NET and I was surprised at how little I needed to initially change to get it working (although I have since changed a great deal to ‘optimise’ it for .NET).

J

Reply | Quote

It’s funny that all of the “serious” coders use C#, while VB is left for everyone else. I’ve used both (much more VB than C#) and I could go either way.

In the current version (2003), I find that I can write VB more productively. The intellisense is much more abundant and does not require fully qualified object names in order to pop up. Another small advantage of VB is the With block, which does not exist in C#.

The biggest advantage of C# now is the inline XML documentation feature (//

blah blah

, etc). This allows developers to include descriptions and helpful information within the code component, which will display in the object browser. Unfortunately, the current version of VB does not support this out of the box.

Studio 2005 will add that feature to VB, bringing it up to a par with C# (despite the few minor differences remaining).

Reply | Quote

Maybe, as a separate thread, you might like to post a simple routine, and have people suggest a way it may be written in VB .Net (or even C#- there’s talk that MS is throwing more support behind C#, despite the talk of .Net supporting all .Net languages)

Reply | Quote

> much of the stuff you may be trying to do would be better rewritten as well-

You’re right. Much of my stuff from over five years back (OK, over three years back), looks horrible. Back in the days when i thought it was smart to pass the name of an object, rather than the object itself.

I think that’s part of my thinking here – if I’m going to rationalise my library code, I may as well clean up as much as I can as I go. It’ll cost, but then working with shoddy library code is expensive, too.

Reply | Quote

Our site gave up on the idea of converting- but as a large government site, the can afford to. They actually went from VB6 to C#- future releases of VS may well be dropping some VB features which were seen as compromises.

I’d suspect that much of the stuff you may be trying to do would be better rewritten as well- as there are a lot of new (and different) methods for doing the old things in new ways. I’ve had to wrestle with a lot of OO type of concepts, and a completely different way of doing things, but it has been worth it.

Removing “On error” is NOT an admission that code will always run error free. But the “try/catch” construct is a lot more flexible than to “On error”, and can be done at a top level, applying to many levels below, if just standard error conditions are expected.

Reply | Quote

I’ll agree wholeheartedly with Geoff!

There are a number of new features and design patterns with .NET that make a direct conversion seem like it’s not always the best approach. It’s been so long since I’ve used VBA/VB6 that I’ve forgotten a lot of the differences. (I would have a very hard time going back to VBA/VB6/VBScript!)

You might check some of the Microsoft resources for more specific details: Converting Code from VBA to Visual Basic.NET.

From what I remember, the Do While-Wend/EndWhile construct is slated to be removed from future versions of VB. There are a number of other legacy practices that are supported by .NET but not necessarily the best method (OnError vs. Try/Catch).

One good thing to note with .NET – when creating new code, the IDE automatically adds ByVal as the default for parameters. This saves a few keystrokes, assuming most of your parameters are ByVal.

Hope this helps!

Reply | Quote

> the Do While-Wend/EndWhile construct is slated to be removed

Interesting. I’ve never liked that. I much prefer the (to me) simpler-looking While-Wend.
I’m relieved to hear that ther’s at least one thing i won’t have to worry about.

Reply | Quote

> the Do While-Wend/EndWhile construct is slated to be removed

Interesting. I’ve never liked that. I much prefer the (to me) simpler-looking While-Wend.
I’m relieved to hear that ther’s at least one thing i won’t have to worry about.

Reply | Quote

I’ll agree wholeheartedly with Geoff!

There are a number of new features and design patterns with .NET that make a direct conversion seem like it’s not always the best approach. It’s been so long since I’ve used VBA/VB6 that I’ve forgotten a lot of the differences. (I would have a very hard time going back to VBA/VB6/VBScript!)

You might check some of the Microsoft resources for more specific details: Converting Code from VBA to Visual Basic.NET.

From what I remember, the Do While-Wend/EndWhile construct is slated to be removed from future versions of VB. There are a number of other legacy practices that are supported by .NET but not necessarily the best method (OnError vs. Try/Catch).

One good thing to note with .NET – when creating new code, the IDE automatically adds ByVal as the default for parameters. This saves a few keystrokes, assuming most of your parameters are ByVal.

Hope this helps!

Reply | Quote

Get used to working with objects because everything is an object in .Net, so even a string variable has methods and properties. Your code will need to be converted and the best conversion involves heavy use of classes because VB.Net finally supports inheritance and allows overloaded constructors. I love it, but I’m still on a learning curve trying to convert stuff to .Net while maintaining Access XP apps as well. There’s a lot of legacy support in .Net, but I recommend you not rely on it. There are entirely different ways of doing things in .Net that are worth learning.

Reply | Quote

Get used to working with objects because everything is an object in .Net, so even a string variable has methods and properties. Your code will need to be converted and the best conversion involves heavy use of classes because VB.Net finally supports inheritance and allows overloaded constructors. I love it, but I’m still on a learning curve trying to convert stuff to .Net while maintaining Access XP apps as well. There’s a lot of legacy support in .Net, but I recommend you not rely on it. There are entirely different ways of doing things in .Net that are worth learning.

Reply | Quote

On Error was not removed.

Reply | Quote

True, Howard, but Try Catch is the construction of choice. On Error is there primarily for easy code migration.

Reply | Quote

True, Howard, but Try Catch is the construction of choice. On Error is there primarily for easy code migration.

Reply | Quote

On Error was not removed.

Reply | Quote