getting rid of old vb6 code

Hi All.

My introduction to VB was through VB.Net but I am working with a lot
of code that was written by programmers with pre-dotnet experience. As
a result there are lots of function calls and "non-OOP aware" code.

Is there any program available that I can get to sweep through VB.Net
projects and flag these older VB functions/things ?

I don't want to have to learn pre-dotnet VB to just to know what I
should be getting rid of.

Thanks in advance (perhaps)
Chook.

re: getting rid of old vb6 code

You could remove the reference to the Microsoft.VisualBasic namespace and
see what breaks.

"chookeater" <chookeater55@hotmail.com> wrote in message
news:9f64df6.0312222038.188ca593@posting.google.co m...[color=blue]
> Hi All.
>
> My introduction to VB was through VB.Net but I am working with a lot
> of code that was written by programmers with pre-dotnet experience. As
> a result there are lots of function calls and "non-OOP aware" code.
>
> Is there any program available that I can get to sweep through VB.Net
> projects and flag these older VB functions/things ?
>
> I don't want to have to learn pre-dotnet VB to just to know what I
> should be getting rid of.
>
> Thanks in advance (perhaps)
> Chook.[/color]

re: getting rid of old vb6 code

Hi Scott,

What has the Microsoft.VisaualBasic namespace to do with non OOP
programming?

Cor

[color=blue]
> You could remove the reference to the Microsoft.VisualBasic namespace and
> see what breaks.[/color]
[color=blue][color=green]
> > My introduction to VB was through VB.Net but I am working with a lot
> > of code that was written by programmers with pre-dotnet experience. As
> > a result there are lots of function calls and "non-OOP aware" code.
> >
> > Is there any program available that I can get to sweep through VB.Net
> > projects and flag these older VB functions/things ?
> >
> > I don't want to have to learn pre-dotnet VB to just to know what I
> > should be getting rid of.[/color][/color]

re: getting rid of old vb6 code

* chookeater55@hotmail.com (chookeater) scripsit:[color=blue]
> My introduction to VB was through VB.Net but I am working with a lot
> of code that was written by programmers with pre-dotnet experience. As
> a result there are lots of function calls and "non-OOP aware" code.
>
> Is there any program available that I can get to sweep through VB.Net
> projects and flag these older VB functions/things ?
>
> I don't want to have to learn pre-dotnet VB to just to know what I
> should be getting rid of.[/color]

Maybe this tool will help you:

Micrososoft Visual Basic Code Advisor
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvb600/html/vb6_FixItRuleTool.asp>

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

"Cor" <non@non.com> wrote in message
news:OZvlAeTyDHA.3416@tk2msftngp13.phx.gbl...[color=blue]
> Hi Scott,
>
> What has the Microsoft.VisaualBasic namespace to do with non OOP
> programming?
>
> Cor
>[/color]

I know this is bound to open a can of worms here, but much of what is in
that namespace is throwbacks to the "old" VB 6.0 syntax. MsgBox() for
example.

The OP said he was looking for a way to get away from VB 6.0 functions and
get more to OOP techniques. If I take away the MsgBox() function, you are
left with the MessageBox class and its show method, which is the more OO
approach.

re: getting rid of old vb6 code

Hi Scott,

Something that is C style code is not OOP, C style keywords have nothing to
do with OOP

OOp is today the best way to get reusable uniform code

To archive that you can use things as overloading, inheriting, protecting,
etc.

But maybe am I wrong and is using

dim a as string = b.substring(0,2) instead of a MID function complete OOP.
But from that I see no benefit in reusable uniform code.

(I myself use mostly the C style code, but that is mainly because of the
zero indexer)

But please correct me if I am wrong?

Cor

re: getting rid of old vb6 code

I really don't know what "C style code" is supposed to mean, so I really
can't follow what you are trying to say in your post.


"Cor" <non@non.com> wrote in message
news:O6dLnNXyDHA.2712@TK2MSFTNGP11.phx.gbl...[color=blue]
> Hi Scott,
>
> Something that is C style code is not OOP, C style keywords have nothing[/color]
to[color=blue]
> do with OOP
>
> OOp is today the best way to get reusable uniform code
>
> To archive that you can use things as overloading, inheriting, protecting,
> etc.
>
> But maybe am I wrong and is using
>
> dim a as string = b.substring(0,2) instead of a MID function complete[/color]
OOP.[color=blue]
> But from that I see no benefit in reusable uniform code.
>
> (I myself use mostly the C style code, but that is mainly because of the
> zero indexer)
>
> But please correct me if I am wrong?
>
> Cor
>
>
>
>
>[/color]

re: getting rid of old vb6 code

Chook,
Here are two more items that may help.

1: Code Critics & Code Analyzers (Herfield's link is for a Code Critic that
runs on VB6). There are also Code Critics & Analyzers available for VB.NET,
such as http://www.fmsinc.com/reviews/tnanalyzer/sd1202.htm

2: Refactoring http://www.refactoring.com

Hope this helps
Jay

"chookeater" <chookeater55@hotmail.com> wrote in message
news:9f64df6.0312222038.188ca593@posting.google.co m...[color=blue]
> Hi All.
>
> My introduction to VB was through VB.Net but I am working with a lot
> of code that was written by programmers with pre-dotnet experience. As
> a result there are lots of function calls and "non-OOP aware" code.
>
> Is there any program available that I can get to sweep through VB.Net
> projects and flag these older VB functions/things ?
>
> I don't want to have to learn pre-dotnet VB to just to know what I
> should be getting rid of.
>
> Thanks in advance (perhaps)
> Chook.[/color]

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue]
> I know this is bound to open a can of worms here, but much of what is in
> that namespace is throwbacks to the "old" VB 6.0 syntax. MsgBox() for
> example.[/color]

I still don't know what's bad about 'MsgBox' and the other functions.
[color=blue]
> The OP said he was looking for a way to get away from VB 6.0 functions and
> get more to OOP techniques.[/color]

I think he wanted to get back from a bad application design using
various modules. Using 'MsgBox' isn't bad. Using the
non-object-oriented '+' operator isn't bad too.
[color=blue]
> If I take away the MsgBox() function, you are
> left with the MessageBox class and its show method, which is the more OO
> approach.[/color]

IMO there isn't any difference. The 'Show' method of the 'MessageBox'
is a static method too.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

* "Cor" <non@non.com> scripsit:[color=blue]
> Something that is C style code is not OOP, C style keywords have nothing to
> do with OOP[/color]

ACK. C was an OOP-less programming language...
[color=blue]
> OOp is today the best way to get reusable uniform code
>
> To archive that you can use things as overloading, inheriting, protecting,
> etc.
>
> But maybe am I wrong and is using
>
> dim a as string = b.substring(0,2) instead of a MID function complete OOP.
> But from that I see no benefit in reusable uniform code.[/color]

That's the main point. It doesn't matter if you use 'MsgBox' or
'MessageBox.Show' as it doesn't matter if you use 'Substring' or 'Mid'.
What matters, is the design, the architecture of the application. A
good class design which is CLS compliant.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue]
> I really don't know what "C style code" is supposed to mean, so I really
> can't follow what you are trying to say in your post.[/color]

My interpretation: Procedural programming.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

Hi Scott,

You got your answers from Herfried, I have nothing to add in this.

Cor

re: getting rid of old vb6 code

And what does this have to do with our prior posts about the
Microsoft.VisualBasic namespace?

"Cor" <non@non.com> wrote in message
news:ui1NOzXyDHA.2116@TK2MSFTNGP11.phx.gbl...[color=blue]
> Hi Scott,
>
> You got your answers from Herfried, I have nothing to add in this.
>
> Cor
>
>[/color]

re: getting rid of old vb6 code

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23DOfmoXyDHA.1680@TK2MSFTNGP12.phx.gbl...[color=blue]
> * "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=green]
> > I know this is bound to open a can of worms here, but much of what is in
> > that namespace is throwbacks to the "old" VB 6.0 syntax. MsgBox() for
> > example.[/color]
>
> I still don't know what's bad about 'MsgBox' and the other functions.[/color]

This is the "can of worms" I mentioned earlier because there are strong
opinions on both sides of the fence. When you use the MsgBox() function,
all that happens is that a call to the .show method of the MessagBox class
occurs. Why take the extra step with the function when you can go straight
to the functionality you want with the method.
[color=blue]
>[color=green]
> > The OP said he was looking for a way to get away from VB 6.0 functions[/color][/color]
and[color=blue][color=green]
> > get more to OOP techniques.[/color]
>
> I think he wanted to get back from a bad application design using
> various modules. Using 'MsgBox' isn't bad. Using the
> non-object-oriented '+' operator isn't bad too.[/color]

See above.
[color=blue]
>[color=green]
> > If I take away the MsgBox() function, you are
> > left with the MessageBox class and its show method, which is the more OO
> > approach.[/color]
>
> IMO there isn't any difference. The 'Show' method of the 'MessageBox'
> is a static method too.[/color]

But there is an extra processing step when using the MsgBox() function.

[color=blue]
>
> --
> Herfried K. Wagner [MVP]
> <http://www.mvps.org/dotnet>[/color]

re: getting rid of old vb6 code

Hi Scott,

With Removing the Microsoft.Visual.Basic namespace you are not making OOP
programs,

You are restricting yourself useless by only using a part of the .Net
framework.

Cor
[color=blue]
> And what does this have to do with our prior posts about the
> Microsoft.VisualBasic namespace?[/color]

re: getting rid of old vb6 code

"Scott M." <s-mar@BADSPAMsnet.net> schrieb[color=blue][color=green]
> > I still don't know what's bad about 'MsgBox' and the other
> > functions.[/color]
>
> This is the "can of worms" I mentioned earlier because there are
> strong opinions on both sides of the fence. When you use the
> MsgBox() function, all that happens is that a call to the .show
> method of the MessagBox class occurs. Why take the extra step with
> the function when you can go straight to the functionality you want
> with the method.[/color]


- I'm used to msgbox
- Messagebox.Show is more to type
- The overhead with Msgbox is unimportant (UI stuff; user won't notice it)

My 2 Euro-c.

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue][color=green][color=darkred]
>>> I know this is bound to open a can of worms here, but much of what is in
>>> that namespace is throwbacks to the "old" VB 6.0 syntax. MsgBox() for
>>> example.[/color]
>>
>> I still don't know what's bad about 'MsgBox' and the other functions.[/color]
>
> This is the "can of worms" I mentioned earlier because there are strong
> opinions on both sides of the fence. When you use the MsgBox() function,
> all that happens is that a call to the .show method of the MessagBox class
> occurs. Why take the extra step with the function when you can go straight
> to the functionality you want with the method.[/color]

Reducing the "complexity" of the code for common tasks.
[color=blue][color=green][color=darkred]
>>> If I take away the MsgBox() function, you are
>>> left with the MessageBox class and its show method, which is the more OO
>>> approach.[/color]
>>
>> IMO there isn't any difference. The 'Show' method of the 'MessageBox'
>> is a static method too.[/color]
>
> But there is an extra processing step when using the MsgBox() function.[/color]

Who cares? That's some ns of processing.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue]
> And what does this have to do with our prior posts about the
> Microsoft.VisualBasic namespace?[/color]

You can use the methods without adding the name of the module they
reside in. Maybe that's what Cor means.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

* "Cor" <non@non.com> scripsit:[color=blue]
> With Removing the Microsoft.Visual.Basic namespace you are not making OOP
> programs,[/color]

ACK, you can still use modules, for example.
[color=blue]
> You are restricting yourself useless by only using a part of the .Net
> framework.[/color]

:-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

"Cor" <non@non.com> wrote in message
news:eqD62DYyDHA.1272@TK2MSFTNGP12.phx.gbl...[color=blue]
> Hi Scott,
>
> With Removing the Microsoft.Visual.Basic namespace you are not making OOP
> programs,
>
> You are restricting yourself useless by only using a part of the .Net
> framework.
>[/color]

Which is EXACTLY what the OP said he wanted to do: "Is there any program
available that I can get to sweep through VB.Net projects and flag these
older VB functions/things ?"

By disabling the Microsoft.VisualBasic namespace, you disable many of the
old VB 6 functions and therefore you are left with the new .NET object
methods (which, as I stated earlier are usually more efficient because there
is no extra step to invoke them).

re: getting rid of old vb6 code

This is the "can of worms" I anticipated:

You are entitled to you opinion, I'm trying to answer the OP.
[color=blue]
> Reducing the "complexity" of the code for common tasks.[/color]

IMHO it doesn't seem that complex to use an object method instead of a
function. In fact, it seems more intuitive. String objects will have
string methods, math objects will have math methods, numeric objects with
have numeric methods, data objects will have date methods AND the
intellisense will only show those methods that are applicable to that
particular object. If I use the old function approach, I open the door to
type mismatches and I have to remember the names of all those functions (no
intellisense).
[color=blue]
>[color=green][color=darkred]
> >>> If I take away the MsgBox() function, you are
> >>> left with the MessageBox class and its show method, which is the more[/color][/color][/color]
OO[color=blue][color=green][color=darkred]
> >>> approach.
> >>
> >> IMO there isn't any difference. The 'Show' method of the 'MessageBox'
> >> is a static method too.[/color]
> >
> > But there is an extra processing step when using the MsgBox() function.[/color]
>
> Who cares? That's some ns of processing.[/color]

Ok, maybe (or apparently) you don't, but those interested in performance
might.

re: getting rid of old vb6 code

[color=blue]
> - I'm used to msgbox
> - Messagebox.Show is more to type
> - The overhead with Msgbox is unimportant (UI stuff; user won't notice it)
>[/color]

Which is why MS put the Microsoft.VisualBasic namespace into the Framework.
If you want to use it, that's fine, go ahead. But removing this namespace
does what the OP had asked for and if you look at my other response, in most
cases, using the new method calls instead of the old function calls is not
only more efficient, but more intuitive and easier because of intellisense.

re: getting rid of old vb6 code

"Scott M." <s-mar@BADSPAMsnet.net> schrieb[color=blue]
>[color=green]
> > - I'm used to msgbox
> > - Messagebox.Show is more to type
> > - The overhead with Msgbox is unimportant (UI stuff; user won't
> > notice it)
> >[/color]
>
> Which is why MS put the Microsoft.VisualBasic namespace into the
> Framework. If you want to use it, that's fine, go ahead. But
> removing this namespace does what the OP had asked for and if you
> look at my other response, in most cases, using the new method calls
> instead of the old function calls is not only more efficient, but
> more intuitive and easier because of intellisense.[/color]


I didn't read the whole thread. I only gave my personal opinion on "Why take
the extra step with the function when you can go straight to the
functionality you want with the method."


--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue]
> Which is why MS put the Microsoft.VisualBasic namespace into the Framework.
> If you want to use it, that's fine, go ahead. But removing this namespace
> does what the OP had asked for and if you look at my other response, in most
> cases, using the new method calls instead of the old function calls is not
> only more efficient, but more intuitive and easier because of intellisense.[/color]

For common tasks I don't need intellisense. I don't need intellisense
for 'MsgBox', 'Strings.Left', etc.

:-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue]
> You are entitled to you opinion, I'm trying to answer the OP.
>[color=green]
>> Reducing the "complexity" of the code for common tasks.[/color]
>
> IMHO it doesn't seem that complex to use an object method instead of a
> function. In fact, it seems more intuitive. String objects will have[/color]

Sure, I fully agree. I was not sure if "complexity" was the right word,
that's why I put it between quotation marks.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue][color=green]
>> With Removing the Microsoft.Visual.Basic namespace you are not making OOP
>> programs,
>>
>> You are restricting yourself useless by only using a part of the .Net
>> framework.[/color]
>
> Which is EXACTLY what the OP said he wanted to do: "Is there any program
> available that I can get to sweep through VB.Net projects and flag these
> older VB functions/things ?"[/color]

Im my interpreation the OP wanted to get rid of VB6 code which has a
poor design. The methods provided in the 'Microsoft.VisualBasic'
namespace are not "old" and "out of date", they are valid part of/in
Visual Basic .NET code.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

> Im my interpreation the OP wanted to get rid of VB6 code which has a[color=blue]
> poor design. The methods provided in the 'Microsoft.VisualBasic'
> namespace are not "old" and "out of date", they are valid part of/in
> Visual Basic .NET code.[/color]

In my interpretation the OP wanted to get rid of VB 6 functions (he actually
said this) AND move to a more OO way of programming in general.

The "can of worms" I've been mentioning is that IMHO the
Microsoft.VisualBasic namespace DOES represent the "old" and "out of date"
way of doing things and that they are not the OO way to handle thier
functionality.

I believe that the only reason that they are in the Framework is to provide
a "crutch" to VB 6 developers so that when they migrate to VB.NET, they will
have some old "friends" that will still work.

Because of the fact that the "old" functions have "new" method calls that
are more efficient, there is (again IMHO) no reason to continue their use.

I work with a global insurance giant that recently disabled the use of this
namespace enterprise-wide as an attempt to come closer to a more OO and .NET
approach to application development.

re: getting rid of old vb6 code

But all developers are not you.

If you need a variable (x) to take on a date value that is 6 days from
today, you would have to already know about the old VB 6.0 DateAdd function
because you will not get any intellisense after typing:

Dim x as Date
x =

You would have to know how to complete that statement: x = DateAdd("d", 6,
Date())

But with the new, more object centric approach, you would type:

Dim x as Date
x.

And as soon as you type the ".", you get intellisense where you will see the
DateAdd function and a short description of it. So, for someone who didn't
have VB 6 experience, they could still get themself to:

x.DateAdd("d",6,Date())

Again, use the "old" way if you want. They are part of the framework, but
they are generally more processing intensive and less intuitive than the new
way.



"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23$3RBeZyDHA.2396@TK2MSFTNGP10.phx.gbl...[color=blue]
> * "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=green]
> > Which is why MS put the Microsoft.VisualBasic namespace into the[/color][/color]
Framework.[color=blue][color=green]
> > If you want to use it, that's fine, go ahead. But removing this[/color][/color]
namespace[color=blue][color=green]
> > does what the OP had asked for and if you look at my other response, in[/color][/color]
most[color=blue][color=green]
> > cases, using the new method calls instead of the old function calls is[/color][/color]
not[color=blue][color=green]
> > only more efficient, but more intuitive and easier because of[/color][/color]
intellisense.[color=blue]
>
> For common tasks I don't need intellisense. I don't need intellisense
> for 'MsgBox', 'Strings.Left', etc.
>
> :-)
>
> --
> Herfried K. Wagner [MVP]
> <http://www.mvps.org/dotnet>[/color]

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue][color=green]
>> Im my interpreation the OP wanted to get rid of VB6 code which has a
>> poor design. The methods provided in the 'Microsoft.VisualBasic'
>> namespace are not "old" and "out of date", they are valid part of/in
>> Visual Basic .NET code.[/color]
>
> In my interpretation the OP wanted to get rid of VB 6 functions (he actually
> said this) AND move to a more OO way of programming in general.
>
> The "can of worms" I've been mentioning is that IMHO the
> Microsoft.VisualBasic namespace DOES represent the "old" and "out of date"
> way of doing things and that they are not the OO way to handle thier
> functionality.[/color]

That's IMO one of the biggest misinterpretations ever done. Code
written using the functions contained in 'Microsoft VisualBasic' won't
reduce readability and maintainability of the code. In some cases, it
will increase intuitivity. And last bug not least, using the "old"
functions won't lead to more errors in the code.
[color=blue]
> I believe that the only reason that they are in the Framework is to provide
> a "crutch" to VB 6 developers so that when they migrate to VB.NET, they will
> have some old "friends" that will still work.[/color]

I believe that they are in the framework to make VB.NET a good (better)
RAD tool (than C#). They will never disappear and I am glad to see that
the RAD character of VB.NET (many "shortcuts") will be extended in the
next release of VB.NET ("Whidbey", 2004).

OOP is good and it has a lot of advantages over other concepts when
talking about /components/, /interfaces/ and large applications. OOP
mainly makes writing and maintainance of large applications with a
complex architecture easier. Nevertheless, procedural approaches still
are perfect inside the implementation of classes, they are not out of
date.
[color=blue]
> Because of the fact that the "old" functions have "new" method calls that
> are more efficient, there is (again IMHO) no reason to continue their use.[/color]

Who says that they are more efficient? Sometimes there isn't even a
replacement in the FCL. An interesting article on this topic can be
found here:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchMicrosoftVisualBasicNETInternals.asp>
[color=blue]
> I work with a global insurance giant that recently disabled the use of this
> namespace enterprise-wide as an attempt to come closer to a more OO and .NET
> approach to application development.[/color]

I don't see any advantages...

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue]
> But all developers are not you.[/color]

.... and all developers are not you too.

:-)
[color=blue]
> If you need a variable (x) to take on a date value that is 6 days from
> today, you would have to already know about the old VB 6.0 DateAdd function
> because you will not get any intellisense after typing:
>
> Dim x as Date
> x =
>
> You would have to know how to complete that statement: x = DateAdd("d", 6,
> Date())
>
> But with the new, more object centric approach, you would type:
>
> Dim x as Date
> x.
>
> And as soon as you type the ".", you get intellisense where you will see the
> DateAdd function and a short description of it. So, for someone who didn't
> have VB 6 experience, they could still get themself to:
>
> x.DateAdd("d",6,Date())
>
> Again, use the "old" way if you want. They are part of the framework, but
> they are generally more processing intensive and less intuitive than the new
> way.[/color]

ACK, that's a big advantage, but as long as some VB.NET methods provide
a good shortcut, I will prefer them (I won't use 'DateAdd'). But even
if I would use it I don't see a problem because it's very easy to
understand and read.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

> That's IMO one of the biggest misinterpretations ever done.

What is? That's what the OP said he wanted:

"Is there any program available that I can get to sweep through VB.Net
projects and flag these older VB functions/things?"
[color=blue]
> Code written using the functions contained in 'Microsoft VisualBasic'[/color]
won't[color=blue]
> reduce readability and maintainability of the code.[/color]

Sure it would, to the novice programmer. If I run across: Mid(blah blah),
would I intuitively know that Mid was a string function? No. But if I see a
string object with a method after it, I know that that method must be a
string method.
[color=blue]
> In some cases, it will increase intuitivity.[/color]

Maybe, but I can't think of any. Can you?
[color=blue]
> And last bug not least, using the "old" functions won't lead to more[/color]
errors in the code.

Sure they could. Again novice programmers could use a string function on a
date, a date function on a string, a math funciton on a date, etc. This
method approach will prevent type mismatches.
[color=blue][color=green]
> > Because of the fact that the "old" functions have "new" method calls[/color][/color]
that[color=blue][color=green]
> > are more efficient, there is (again IMHO) no reason to continue their[/color][/color]
use.[color=blue]
>
> Who says that they are more efficient? Sometimes there isn't even a
> replacement in the FCL. An interesting article on this topic can be
> found here:
>
>[/color]
<http://msdn.microsoft.com/library/de...-us/dv_vstecha
rt/html/vbtchMicrosoftVisualBasicNETInternals.asp>[color=blue]
>[/color]

If a function has to call a method then isn't it more effecient to just call
the method directly and not have to pass data an extra time? You are right,
sometimes there isn't a replacement, and so we are not talking about ALL VB
6.0 functions.

It's also interesting in that article you posted a link to that they discuss
the Microsoft.VisualBasic.Compatibility namespace and say that "The
compatibility classes should not be used for new development."

The compatability namespace and the VisualBaisc namespace have certain
similarities.

[color=blue][color=green]
> > I work with a global insurance giant that recently disabled the use of[/color][/color]
this[color=blue][color=green]
> > namespace enterprise-wide as an attempt to come closer to a more OO and[/color][/color]
..NET[color=blue][color=green]
> > approach to application development.[/color]
>
> I don't see any advantages...
>[/color]

Ok, we agree to disagree.

re: getting rid of old vb6 code

Thanks Scott.

Always the simple answers that are the best :-)

Removing the Namespace at least alerts me to code to avoid in future projects.

Thanks to all the others who responded as well.

Chook.

"Scott M." <s-mar@BADSPAMsnet.net> wrote in message news:<#CN2F#QyDHA.2452@tk2msftngp13.phx.gbl>...[color=blue]
> You could remove the reference to the Microsoft.VisualBasic namespace and
> see what breaks.
>
> "chookeater" <chookeater55@hotmail.com> wrote in message
> news:9f64df6.0312222038.188ca593@posting.google.co m...[color=green]
> > Hi All.
> >
> > My introduction to VB was through VB.Net but I am working with a lot
> > of code that was written by programmers with pre-dotnet experience. As
> > a result there are lots of function calls and "non-OOP aware" code.
> >
> > Is there any program available that I can get to sweep through VB.Net
> > projects and flag these older VB functions/things ?
> >
> > I don't want to have to learn pre-dotnet VB to just to know what I
> > should be getting rid of.
> >
> > Thanks in advance (perhaps)
> > Chook.[/color][/color]

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue][color=green]
>> That's IMO one of the biggest misinterpretations ever done.[/color]
>
> What is? That's what the OP said he wanted:
>
> "Is there any program available that I can get to sweep through VB.Net
> projects and flag these older VB functions/things?"[/color]

Do you want to flag all 'If's, 'Do's, 'With's etc. too? They are "old"
too.
[color=blue][color=green]
>> Code written using the functions contained in 'Microsoft VisualBasic'
>> won't reduce readability and maintainability of the code.[/color]
>
> Sure it would, to the novice programmer. If I run across: Mid(blah blah),
> would I intuitively know that Mid was a string function? No. But if I see a
> string object with a method after it, I know that that method must be a
> string method.[/color]

No, absolutely not. Calling a 'String' object's method isn't more
intuitive for a "beginner" who isn't familiar with object oriented
programming. IMO it's impossible to be a good OO programmer without
having good knowledge in procedural programming, which is a basis.
[color=blue][color=green]
>> In some cases, it will increase intuitivity.[/color]
>
> Maybe, but I can't think of any. Can you?[/color]

'Strings.Left', 'Strings.Right', for example. There is no direct and
descriptive replacement available in the string class.
[color=blue][color=green]
>> And last bug not least, using the "old" functions won't lead to more
>> errors in the code.[/color]
>
> Sure they could. Again novice programmers could use a string function on a
> date, a date function on a string, a math funciton on a date, etc. This
> method approach will prevent type mismatches.[/color]

You can still pass wrong datatypes to methods of objects. I think
that's not a big problem.
[color=blue][color=green][color=darkred]
>>> Because of the fact that the "old" functions have "new" method calls
>>> that
>>> are more efficient, there is (again IMHO) no reason to continue their
>>> use.[/color]
>>
>> Who says that they are more efficient? Sometimes there isn't even a
>> replacement in the FCL. An interesting article on this topic can be
>> found here:
>>[/color]
> <http://msdn.microsoft.com/library/de...-us/dv_vstecha
> rt/html/vbtchMicrosoftVisualBasicNETInternals.asp>
>
> If a function has to call a method then isn't it more effecient to just call
> the method directly and not have to pass data an extra time? You are right,
> sometimes there isn't a replacement, and so we are not talking about ALL VB
> 6.0 functions.[/color]

ACK.
[color=blue]
> It's also interesting in that article you posted a link to that they discuss
> the Microsoft.VisualBasic.Compatibility namespace and say that "The
> compatibility classes should not be used for new development."[/color]

I wouldn't use the /compatibility/ classes which reside in the Microsoft
Visual Basic .NET Compatibility Library, as the documentation states
that it may not be included in a future release.
[color=blue]
> The compatability namespace and the VisualBaisc namespace have certain
> similarities.[/color]

Let's see it from an other point of view: Microsoft made a strict
distinction between the compatibility library and the VB.NET
class/method library.
[color=blue][color=green][color=darkred]
>>> approach to application development.[/color]
>>
>> I don't see any advantages...[/color]
>
> Ok, we agree to disagree.[/color]

:-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

> Do you want to flag all 'If's, 'Do's, 'With's etc. too? They are "old"[color=blue]
> too.[/color]

Well now, you are just being sarcastic. I know that you know that these are
language constructs and not functions.
[color=blue]
> No, absolutely not. Calling a 'String' object's method isn't more
> intuitive for a "beginner" who isn't familiar with object oriented
> programming. IMO it's impossible to be a good OO programmer without
> having good knowledge in procedural programming, which is a basis.
>[/color]

Would a beginner programmer know what the string methods are intuitively?
No. But if they type a "." next to a string object, intellisense will help
them to learn what the string methods are.
[color=blue][color=green][color=darkred]
> >> In some cases, it will increase intuitivity.[/color]
> >
> > Maybe, but I can't think of any. Can you?[/color]
>
> 'Strings.Left', 'Strings.Right', for example. There is no direct and
> descriptive replacement available in the string class.[/color]

It's true that there are no string method replacements for those, but that's
not an example of how the old Left() and Right() are more intuitive. I
still have to know of thier existance before I can use them. I wouldn't
just intuitively know that they exist.
[color=blue]
>[color=green][color=darkred]
> >> And last bug not least, using the "old" functions won't lead to more
> >> errors in the code.[/color]
> >
> > Sure they could. Again novice programmers could use a string function[/color][/color]
on a[color=blue][color=green]
> > date, a date function on a string, a math funciton on a date, etc. This
> > method approach will prevent type mismatches.[/color]
>
> You can still pass wrong datatypes to methods of objects. I think
> that's not a big problem.[/color]

Yes, but I'm taling about using a date function when you should have been
using a string function, not passing a date when you should have passed a
string. Intelisense will help the user in either the old or new way to pass
the right data into the function/method, but with the older functions, the
programmer has to somehow now the categories of functions. With methods,
there's no possibilty of that.

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue][color=green]
>> Do you want to flag all 'If's, 'Do's, 'With's etc. too? They are "old"
>> too.[/color]
>
> Well now, you are just being sarcastic. I know that you know that these are
> language constructs and not functions.[/color]

Yep -- I was a little bit sarcastic.
[color=blue][color=green]
>> No, absolutely not. Calling a 'String' object's method isn't more
>> intuitive for a "beginner" who isn't familiar with object oriented
>> programming. IMO it's impossible to be a good OO programmer without
>> having good knowledge in procedural programming, which is a basis.
>>[/color]
>
> Would a beginner programmer know what the string methods are intuitively?
> No. But if they type a "." next to a string object, intellisense will help
> them to learn what the string methods are.[/color]

Not every "beginner" uses the VS.NET IDE for writing his/her source
code.

;-)
[color=blue][color=green][color=darkred]
>>>> In some cases, it will increase intuitivity.
>>>
>>> Maybe, but I can't think of any. Can you?[/color]
>>
>> 'Strings.Left', 'Strings.Right', for example. There is no direct and
>> descriptive replacement available in the string class.[/color]
>
> It's true that there are no string method replacements for those, but that's
> not an example of how the old Left() and Right() are more intuitive. I
> still have to know of thier existance before I can use them. I wouldn't
> just intuitively know that they exist.[/color]

The same with the methods of the 'String' class... Without getting the
information somewhere, I don't know it.
[color=blue][color=green]
>> You can still pass wrong datatypes to methods of objects. I think
>> that's not a big problem.[/color]
>
> Yes, but I'm taling about using a date function when you should have been
> using a string function, not passing a date when you should have passed a
> string. Intelisense will help the user in either the old or new way to pass
> the right data into the function/method, but with the older functions, the
> programmer has to somehow now the categories of functions. With methods,
> there's no possibilty of that.[/color]

As mentioned previously, I agree with you for most cases. The methods
of the classes are better, but sometimes there doesn't exist an 1:1
equivalent and VB.NET's function is more intuitive. It would be nice if
the "missing" methods would be added to the classes contained in the
FCL, so they can be removed from the VB.NET Runtime Library.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

> >> No, absolutely not. Calling a 'String' object's method isn't more[color=blue][color=green][color=darkred]
> >> intuitive for a "beginner" who isn't familiar with object oriented
> >> programming. IMO it's impossible to be a good OO programmer without
> >> having good knowledge in procedural programming, which is a basis.
> >>[/color]
> >
> > Would a beginner programmer know what the string methods are[/color][/color]
intuitively?[color=blue][color=green]
> > No. But if they type a "." next to a string object, intellisense will[/color][/color]
help[color=blue][color=green]
> > them to learn what the string methods are.[/color]
>
> Not every "beginner" uses the VS.NET IDE for writing his/her source
> code.
>[/color]

Even more of a case for organizing old functions into object methods! Less
chaotic!
[color=blue][color=green]
> > It's true that there are no string method replacements for those, but[/color][/color]
that's[color=blue][color=green]
> > not an example of how the old Left() and Right() are more intuitive. I
> > still have to know of thier existance before I can use them. I wouldn't
> > just intuitively know that they exist.[/color]
>
> The same with the methods of the 'String' class... Without getting the
> information somewhere, I don't know it.[/color]

You want the information somewhere? Type a dot "." after your object.
[color=blue]
> As mentioned previously, I agree with you for most cases. The methods
> of the classes are better, but sometimes there doesn't exist an 1:1
> equivalent and VB.NET's function is more intuitive. It would be nice if
> the "missing" methods would be added to the classes contained in the
> FCL, so they can be removed from the VB.NET Runtime Library.[/color]

And on that point we agree! Good night.

re: getting rid of old vb6 code

* "Scott M." <s-mar@BADSPAMsnet.net> scripsit:[color=blue][color=green]
>> The same with the methods of the 'String' class... Without getting the
>> information somewhere, I don't know it.[/color]
>
> You want the information somewhere? Type a dot "." after your object.[/color]

Type 'Strings' and a ".", then...

;->
[color=blue]
> And on that point we agree! Good night.[/color]

Good night.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

Hi Scott,

From who do you have this information, some own made?
[color=blue]
>
> By disabling the Microsoft.VisualBasic namespace, you disable many of the
> old VB 6 functions and therefore you are left with the new .NET object
> methods (which, as I stated earlier are usually more efficient because[/color]
there[color=blue]
> is no extra step to invoke them).[/color]

It is not true the are sometimes more efficient some time less efficient.

Why I don't know but probably because they have to carry some extra with
them.

The Find of a string is twice as fast as the Instring.

Cor

re: getting rid of old vb6 code

Hi Scott,

My problem with this kind of answers from you is (and this is not the first
time) that you give the OP the idea that by removing the classic VB
functions he starts writing OOP.

That is not, when he does only what you say, he is is making JavaScript
look-alike VB programs.

Because I have seen in other groups that you probably come from that
direction, it is possible that you have that misunderstanding.

This is not to flame; in opposite of that, it is just to get a better
understanding why you are always post this kind of messages.

Cor


[color=blue]
> IMHO it doesn't seem that complex to use an object method instead of a
> function. In fact, it seems more intuitive. String objects will have
> string methods, math objects will have math methods, numeric objects with
> have numeric methods, data objects will have date methods AND the
> intellisense will only show those methods that are applicable to that
> particular object. If I use the old function approach, I open the door to
> type mismatches and I have to remember the names of all those functions[/color]
(no[color=blue]
> intellisense).[/color]

re: getting rid of old vb6 code

* "Cor" <non@non.com> scripsit:[color=blue]
> My problem with this kind of answers from you is (and this is not the first
> time) that you give the OP the idea that by removing the classic VB
> functions he starts writing OOP.[/color]

Full ACK. Writing good OO code doesn't depend on using procedures or
don't using them inside the implementation. Far more important is the
application's class design, methods, good encapsulation etc. By
avioding the use of VB.NET's procedures, an application's design isn't
improved.

But I understand Scott -- he loves OOP and he loves /only/ OOP.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

re: getting rid of old vb6 code

"Cor" <non@non.com> wrote in message
news:eshTrVfyDHA.1804@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi Scott,
>
> From who do you have this information, some own made?
>[color=green]
> >
> > By disabling the Microsoft.VisualBasic namespace, you disable many of[/color][/color]
the[color=blue][color=green]
> > old VB 6 functions and therefore you are left with the new .NET object
> > methods (which, as I stated earlier are usually more efficient because[/color]
> there[color=green]
> > is no extra step to invoke them).[/color]
>
> It is not true the are sometimes more efficient some time less efficient.
>
> Why I don't know but probably because they have to carry some extra with
> them.
>
> The Find of a string is twice as fast as the Instring.[/color]

That's my point exactly!

re: getting rid of old vb6 code

> My problem with this kind of answers from you is (and this is not the
first[color=blue]
> time) that you give the OP the idea that by removing the classic VB
> functions he starts writing OOP.[/color]

Cor,

Yes, we've had these discussions before, but I think what you are missing is
that I NEVER said that by removing the classic functions, you are writing
OOP.

The OP asked:

"Is there any program available that I can get to sweep through VB.Net
projects and flag these older VB functions/things?"

Where is the request for OOP in that statement? What I supplied was an
answer to the OP about how old VB functions could be flagged and then
(presumably) replaced.

I appreciate your opinion, but it seems that each time this question comes
up, you take my answer to be something it was never intended to be.

re: getting rid of old vb6 code

Hi Scott,

I told you why I am acting like this. I told you I almost never use
Microsoft.Visual basic functions

However, sometimes I get the idea that when this kind of questions comes in
this newsgroup, that you are the first one who wants to tell not to use
those functions.

I think in some cases they are very good and nowhere is written that they
are old.
I do not like them, but that is my own decision.

It is not important because I think all is clear, but this was the start of
the message from the OP.
[color=blue]
>My introduction to VB was through VB.Net but I am working with a lot
>of code that was written by programmers with pre-dotnet experience. As
>a result there are lots of function calls and "non-OOP aware" code.[/color]

In my opinion is he pointing on "non-OOP aware" code.

I think it had been better to ask what he did mean with that sentence than
directly telling that he should get rid with the Microsoft.VisualBasic
namespace.

That the name is Microsoft instead of System does not mean it is not in the
Net, it is even a part of the Linux Mono code as Tom Shelton told us.

However, marry Christmas,

No hard feeling at all, just wanted to clear this more.

Cor

re: getting rid of old vb6 code

> I told you why I am acting like this. I told you I almost never use[color=blue]
> Microsoft.Visual basic functions[/color]

Ok, fine. As I told Herfried, the decision to not use them was IMHO.
[color=blue]
> However, sometimes I get the idea that when this kind of questions comes[/color]
in[color=blue]
> this newsgroup, that you are the first one who wants to tell not to use
> those functions.[/color]

That may be true. I don't see any advantage at all to using them, so IMHO I
suggest not to. But in this case I was responding (as I said) to the OP who
wanted a way to flag the "old" VB 6.0 functions and this will certainly do
the trick. The OP already responded to me yesterday that this was what he
was looking for.

"Thanks Scott.

Always the simple answers that are the best :-)

Removing the Namespace at least alerts me to code to avoid in future
projects.

Thanks to all the others who responded as well.

Chook."
[color=blue]
> I think in some cases they are very good and nowhere is written that they[/color]
are old.

They've been around for approaching 10 years or more! Now that, in and of
itself does not make them bad. But there are new (and in my opinion more
intuitive and more efficient ways to accomplish most of the "old"
functions). So, I think to use the terms "old" and "new" is appropriate.
[color=blue]
> I do not like them, but that is my own decision.[/color]

Again, ok. I'm not twisting anyone's arm. I'm simply pointing out that
there are newer (more efficient & more intuitive) ways to do these things.
By the way, I've yet to hear ANYONE supply an example of why the old
functions would be a better way to go (other than that they are familiar
with them, which for a newbie to VB.NET wouldn't be a good reason to use
them).
[color=blue]
> It is not important because I think all is clear, but this was the start[/color]
of the message from the OP.[color=blue]
>[color=green]
> >My introduction to VB was through VB.Net but I am working with a lot
> >of code that was written by programmers with pre-dotnet experience. As
> >a result there are lots of function calls and "non-OOP aware" code.[/color]
>
> In my opinion is he pointing on "non-OOP aware" code.
>
> I think it had been better to ask what he did mean with that sentence than
> directly telling that he should get rid with the Microsoft.VisualBasic
> namespace.[/color]

I see his question as trying to avoid 2 things "function calls" and "non-OOP
aware" code (that's exactly what he wrote). I answered the first of his 2
questions. That's all. I think the problem is that you interpreted my
answer as an answer to part 2 as well.

Again, the OP already responded that my answer was what he wanted, so I
think I interpreted the question correctly.

[color=blue]
> That the name is Microsoft instead of System does not mean it is not in[/color]
the Net, it is even a part of the Linux Mono code as Tom Shelton told us.

I've never made a statement saying that it wasn't.

MERRY CHRISTMAS TO ALL!!