microsoft.visualbasic namespace obsolete?

[cj]

I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???

[Mike Hofer]

On Apr 23, 2:14 pm, cj <[e-mail]:

I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???

You'll get a lot of different opinions on this issue. Largely, what
you should do depends on what you plan to do in the future.

If you're planning to become a hard-core .NET developer, you should
definitely learn the .NET way of doing things. (This is especially
true if you want to learn other .NET languages.) The
Microsoft.VisualBasic namespace does include a lot of stuff that is
there to ensure that VB6 code is portable to .NET; we are encouraged
to move away from that namespace to the functionality provided by the
core System namespaces.

The real value of that depends on a number of factors. Is the code
going to be ported to other languages? Will it be used by other
systems? Is it a code library? Or is it a self-contained application
that's a one-shot and not likely going to be used anywhere else?
Practicality should always govern what you decide to do. However,
practicality does *not* mean that you should always have blinders on,
or suffer from a very narrow world view.

Plan for the future. My suggestion is that you keep at it, and move
away from the Microsoft.VisualBasic namespaces. The payoff is
worthwhile. The C# samples that are pervasive don't use that
namespace; you'll find that they're much easier to understand and port
to Visual Basic.NET if you know what they're doing. :) Further, the
pain customary to the learning period is short-lived; once you know
it, you *know* it, and you'll have much more value to everyone.

I hope I haven't overwhelmed you. (I tend to do that sometimes.)

Cheers!
Mike Hofer

[Mattias Sjögren]

>I am under the impression they are obsolete methods included for
backward compatibility.

They are not obsolete.

>Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

System.IO.File.GetLastWriteTime is the alternative - use whatever you
like best.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Herfried K. Wagner [MVP]]

"cj" <[e-mail];

>I am under the impression they are obsolete methods included for backward
compatibility.

That's a wrong impression.

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to learn
the new way of doing things but frequently I find the new way is longer
and seems more confusing.

There is no "new way". There is only more than one way. Take a look at the
classes in the 'System.IO' namespace, namely 'File'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Cor Ligthert [MVP]]

You mean that in the BeNeLux would exist in future only Netherlands way of
life, because the other countries are obsolete. In my idea are the Belgian
and Luxenburg cultures full part of it. Like the MicosoftVisual Basic
namespace is in the Net.

Cor

[Phill W.]

cj wrote:

I am under the impression they are obsolete methods included for
backward compatibility.

Not so.
Those in MS.VB./Compatibility/ should be used with caution - it contains
those things that we used to use all the time, but have now "grown out"
of, like fixed length strings. They are intended /only/ to get your
application migrated to .Net and from there, you can rewrite bits of it
as necessary.

is using filedatetime("c:\myfile.txt") still the accepted way of getting
the date c:\myfile.txt was last modified?

It's still there; it still works and it's not going anywhere.

Is there some ... method we are supposed to use now?

The FileInfo class wraps this up.

I try to avoid functions in microsoft.visualbasic ...

Some people try to go as far as removing the MS.VB from Visual Basic,
but since the compiler /itself/ makes use of some of the stuff in here
(try creating a VB.Net program that doesn't depend on this assembly!),
it's a pretty pointless exercise.

... because I want to learn the new way of doing things but frequently I
find the new way is longer and seems more confusing.

Agreed.
Anyone found the "new" way of 'ReDim'ing an array?

HTH,
Phill W.

[cj]

Thanks to everyone for your responses. I'm glad microsoft.visualbasic
is still acceptable, I'll stay away from the Compatibility namespace and
thanks for the tip on system.io.file.

cj wrote:

I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???

[=?Utf-8?B?RGF2aWQgQW50b24=?=]

"Anyone found the "new" way of 'ReDim'ing an array?"

Actually, you can use Array.Resize (the behavior is identical to ReDim
Preserve, but it's limited to single dimension arrays). But ReDim Preserve
still works fine.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"Phill W." wrote:

cj wrote:

I am under the impression they are obsolete methods included for
backward compatibility.

Not so.
Those in MS.VB./Compatibility/ should be used with caution - it contains
those things that we used to use all the time, but have now "grown out"
of, like fixed length strings. They are intended /only/ to get your
application migrated to .Net and from there, you can rewrite bits of it
as necessary.

is using filedatetime("c:\myfile.txt") still the accepted way of getting
the date c:\myfile.txt was last modified?

It's still there; it still works and it's not going anywhere.

Is there some ... method we are supposed to use now?

The FileInfo class wraps this up.

I try to avoid functions in microsoft.visualbasic ...

Some people try to go as far as removing the MS.VB from Visual Basic,
but since the compiler /itself/ makes use of some of the stuff in here
(try creating a VB.Net program that doesn't depend on this assembly!),
it's a pretty pointless exercise.

... because I want to learn the new way of doing things but frequently I
find the new way is longer and seems more confusing.

Agreed.
Anyone found the "new" way of 'ReDim'ing an array?

HTH,
Phill W.

[=?Utf-8?B?RGF2aWQgQW50b24=?=]

You will find some opposition with people who insist on 'pure' .NET
approaches. Some very useful parts have no equivalent in the rest of the
framework, such as the Financial class.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"cj" wrote:

Thanks to everyone for your responses. I'm glad microsoft.visualbasic
is still acceptable, I'll stay away from the Compatibility namespace and
thanks for the tip on system.io.file.

cj wrote:

I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???

[Cor Ligthert [MVP]]

Phill,

I had not the idea that many people are still using the Microsoft
VisualBasic Compatiblility namespace.
It is a temporary namespace, however not containing the members from the
Microsoft Visual Basic namespace we are talking about at the moment. I for
sure would not advice to use that Compatibility namespace withouth the
conversion software.

Cor
"Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kschreef in bericht
news:f0**********@south.jnrs.ja.net...

cj wrote:

>I am under the impression they are obsolete methods included for backward
compatibility.

Not so.
Those in MS.VB./Compatibility/ should be used with caution - it contains
those things that we used to use all the time, but have now "grown out"
of, like fixed length strings. They are intended /only/ to get your
application migrated to .Net and from there, you can rewrite bits of it as
necessary.

>is using filedatetime("c:\myfile.txt") still the accepted way of getting
the date c:\myfile.txt was last modified?

It's still there; it still works and it's not going anywhere.

>Is there some ... method we are supposed to use now?

The FileInfo class wraps this up.

>I try to avoid functions in microsoft.visualbasic ...

Some people try to go as far as removing the MS.VB from Visual Basic, but
since the compiler /itself/ makes use of some of the stuff in here (try
creating a VB.Net program that doesn't depend on this assembly!), it's a
pretty pointless exercise.

>... because I want to learn the new way of doing things but frequently I
find the new way is longer and seems more confusing.

Agreed.
Anyone found the "new" way of 'ReDim'ing an array?

HTH,
Phill W.

[Cor Ligthert [MVP]]

David,

Pure Net approaches needs the Microsoft Visual Basic Namespace the same as
the System.namespace.

That it is possible to work seperately on namespaces is one of the
advantages from .Net

Nobody will tell it there will be more namespaces in Net.

Cor

"David Anton" <Da********@discussions.microsoft.comschreef in bericht
news:47**********************************@microsof t.com...

You will find some opposition with people who insist on 'pure' .NET
approaches. Some very useful parts have no equivalent in the rest of the
framework, such as the Financial class.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"cj" wrote:

>Thanks to everyone for your responses. I'm glad microsoft.visualbasic
is still acceptable, I'll stay away from the Compatibility namespace and
thanks for the tip on system.io.file.

cj wrote:

I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the
date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???

[=?Utf-8?B?RGF2aWQgQW50b24=?=]

I don't have a problem with Microsoft.VisualBasic (especially from VB code),
but I'm just indicating the type of respone that some people will give you if
you use it.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"Cor Ligthert [MVP]" wrote:

David,

Pure Net approaches needs the Microsoft Visual Basic Namespace the same as
the System.namespace.

That it is possible to work seperately on namespaces is one of the
advantages from .Net

Nobody will tell it there will be more namespaces in Net.

Cor

"David Anton" <Da********@discussions.microsoft.comschreef in bericht
news:47**********************************@microsof t.com...

You will find some opposition with people who insist on 'pure' .NET
approaches. Some very useful parts have no equivalent in the rest of the
framework, such as the Financial class.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"cj" wrote:

Thanks to everyone for your responses. I'm glad microsoft.visualbasic
is still acceptable, I'll stay away from the Compatibility namespace and
thanks for the tip on system.io.file.

cj wrote:
I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the
date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???

[cj]

Cor, he didn't recommend using the compatibility namespace, just said it
was ok to use microsoft.visualbasic.
Cor Ligthert [MVP] wrote:

Phill,

I had not the idea that many people are still using the Microsoft
VisualBasic Compatiblility namespace.
It is a temporary namespace, however not containing the members from the
Microsoft Visual Basic namespace we are talking about at the moment. I for
sure would not advice to use that Compatibility namespace withouth the
conversion software.

Cor
"Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kschreef in bericht
news:f0**********@south.jnrs.ja.net...

>cj wrote:

>>I am under the impression they are obsolete methods included for backward
compatibility.

Not so.
Those in MS.VB./Compatibility/ should be used with caution - it contains
those things that we used to use all the time, but have now "grown out"
of, like fixed length strings. They are intended /only/ to get your
application migrated to .Net and from there, you can rewrite bits of it as
necessary.

>>is using filedatetime("c:\myfile.txt") still the accepted way of getting
the date c:\myfile.txt was last modified?

It's still there; it still works and it's not going anywhere.

>>Is there some ... method we are supposed to use now?

The FileInfo class wraps this up.

>>I try to avoid functions in microsoft.visualbasic ...

Some people try to go as far as removing the MS.VB from Visual Basic, but
since the compiler /itself/ makes use of some of the stuff in here (try
creating a VB.Net program that doesn't depend on this assembly!), it's a
pretty pointless exercise.

>>... because I want to learn the new way of doing things but frequently I
find the new way is longer and seems more confusing.

Agreed.
Anyone found the "new" way of 'ReDim'ing an array?

HTH,
Phill W.

[Cor Ligthert [MVP]]

Sorry David,

Now I know again I know were you stend for,

Cor

"David Anton" <Da********@discussions.microsoft.comschreef in bericht
news:0B**********************************@microsof t.com...

>I don't have a problem with Microsoft.VisualBasic (especially from VB
code),
but I'm just indicating the type of respone that some people will give you
if
you use it.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"Cor Ligthert [MVP]" wrote:

>David,

Pure Net approaches needs the Microsoft Visual Basic Namespace the same
as
the System.namespace.

That it is possible to work seperately on namespaces is one of the
advantages from .Net

Nobody will tell it there will be more namespaces in Net.

Cor

"David Anton" <Da********@discussions.microsoft.comschreef in bericht
news:47**********************************@microso ft.com...

You will find some opposition with people who insist on 'pure' .NET
approaches. Some very useful parts have no equivalent in the rest of
the
framework, such as the Financial class.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"cj" wrote:

Thanks to everyone for your responses. I'm glad microsoft.visualbasic
is still acceptable, I'll stay away from the Compatibility namespace
and
thanks for the tip on system.io.file.

cj wrote:
I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the
date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than
filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way
is
longer and seems more confusing. Like my example filedatetime().
It'll
do what I need now but should I look for something else???

[Vayse]

Reading this post made me think of chocolate and beer. I'm not sure why!

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

You mean that in the BeNeLux would exist in future only Netherlands way of
life, because the other countries are obsolete. In my idea are the Belgian
and Luxenburg cultures full part of it. Like the MicosoftVisual Basic
namespace is in the Net.

Cor

[Phill W.]

David Anton wrote:

"Anyone found the "new" way of 'ReDim'ing an array?"

Actually, you can use Array.Resize (the behavior is identical to ReDim
Preserve, but it's limited to single dimension arrays). But ReDim Preserve
still works fine.

Ah! Finally!

New to /'2005/ though, and I'm still trudging around with '2003.

Maybe one day ...

Many Thanks,
Phill W.

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

Phill W. wrote:

David Anton wrote:

>"Anyone found the "new" way of 'ReDim'ing an array?"

Actually, you can use Array.Resize (the behavior is identical to ReDim
Preserve, but it's limited to single dimension arrays). But ReDim
Preserve still works fine.

Ah! Finally!

New to /'2005/ though, and I'm still trudging around with '2003.

Maybe one day ...

Many Thanks,
Phill W.

You can easily do the same in framework 1. Just create a new array and
use Array.Copy to copy the values from the old array. That's how
Array.Resize does it.

--
Göran Andersson
_____
http://www.guffa.com