Book I am reading says that Cstr() is best method for efficency and safety
however it doesnt compare that method of the .ToString() method.
Which is best.
Thanks
101  19091 
IMHO (and this has been debated for quite some time now), you should view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or .ToString
All date/time functions would be replaced with methods and properties of the
Date class
All string functions would be replaced with methods and properties of the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com... Book I am reading says that Cstr() is best method for efficency and safety
however it doesnt compare that method of the .ToString() method.
Which is best.
Thanks
both points of view are valid, however i use the vb string methods as the
compiler makes optimzations that can improve performance over the native .Net
methods, also i find the vb methods read better.
cheers
guy
"Scott M." wrote: IMHO (and this has been debated for quite some time now), you should view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or .ToString
All date/time functions would be replaced with methods and properties of the
Date class
All string functions would be replaced with methods and properties of the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com... Book I am reading says that Cstr() is best method for efficency and safety
however it doesnt compare that method of the .ToString() method.
Which is best.
Thanks
for my clarification
..ToString() = native .Net methods
CStr() = vb String methods?
from my understanding in the book I am reading Cstr() etc is the perfered
way however it doesnt address .ToString()
"guy" wrote: both points of view are valid, however i use the vb string methods as the
compiler makes optimzations that can improve performance over the native .Net
methods, also i find the vb methods read better.
cheers
guy
"Scott M." wrote:
IMHO (and this has been debated for quite some time now), you should view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or .ToString
All date/time functions would be replaced with methods and properties of the
Date class
All string functions would be replaced with methods and properties of the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com... Book I am reading says that Cstr() is best method for efficency and safety
however it doesnt compare that method of the .ToString() method.
Which is best.
Thanks
"guy" <gu*@discussions.microsoft.com> wrote in message
news:21**********************************@microsof t.com... both points of view are valid, however i use the vb string methods as the
compiler makes optimzations that can improve performance over the native
.Net
methods, also i find the vb methods read better.
The VB 6.0 way are not methods, they are functions. The .NET way are object
methods. The VB.NET compiler does NOT optimize the VB 6.0 functions to work
BETTER than the natvie .NET object methods.
To answer your question, ToString would be my suggestion, rather than
CStr(). ToString is a method of the Object Type, and since all classes
inherit from Object, all objects have this method.
cheers
guy
"Scott M." wrote:
IMHO (and this has been debated for quite some time now), you should view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a
type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties of
the
Date class
All string functions would be replaced with methods and properties of the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com... > Book I am reading says that Cstr() is best method for efficency and
> safety
> however it doesnt compare that method of the .ToString() method.
>
> Which is best.
>
> Thanks
>
>
I don't think that's true at all. First off, CStr,CBool, Etc. are all just
easier-to-read specialized wrappers around CType..... which in and of itself
is a special "VB" construct. The true "non-VB" casting operator is
DirectCast(...).
Contrary to what Scott M says you're SUPPOSED to use them. What's the point
of using VB if you're not going to use its special methods that make your
life easier? This is straight from the VB documentation:
"As a rule, you should use the Visual Basic type conversion functions in
preference to the .NET Framework methods such as ToString(), either on the
Convert class or on an individual type structure or class. The Visual Basic
functions are designed for optimal interaction with Visual Basic code, and
they also make your source code shorter and easier to read. In addition, the
..NET Framework conversion methods do not always produce the same results as
the Visual Basic functions, for example when converting Boolean to Integer.
For more information, see Troubleshooting Data Types."
In addition, although I'm a guy who always initializes strings and objects
as soon as possible rather than have them sit around until my algorithm uses
them- so I don't really care about the following- but, there's an advantage
to using VB's functions: they interpret "Nothing." You can't use the OO
methods on a string that is "Nothing" (s.ToUpper for instance won't work).
--
-C. Moya www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:O7**************@TK2MSFTNGP14.phx.gbl... IMHO (and this has been debated for quite some time now), you should view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties of
the Date class
All string functions would be replaced with methods and properties of the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com... Book I am reading says that Cstr() is best method for efficency and
safety
however it doesnt compare that method of the .ToString() method.
Which is best.
Thanks
>> You can't use the OO methods on a string that is "Nothing"
Why would you want to?
Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?
I'm guessing that On Error Resume Next is one of your friends too.
Bob Lehmann
"CMM" <cm*@nospam.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl... I don't think that's true at all. First off, CStr,CBool, Etc. are all just
easier-to-read specialized wrappers around CType..... which in and of
itself is a special "VB" construct. The true "non-VB" casting operator is
DirectCast(...).
Contrary to what Scott M says you're SUPPOSED to use them. What's the
point of using VB if you're not going to use its special methods that make your
life easier? This is straight from the VB documentation:
"As a rule, you should use the Visual Basic type conversion functions in
preference to the .NET Framework methods such as ToString(), either on the
Convert class or on an individual type structure or class. The Visual
Basic functions are designed for optimal interaction with Visual Basic code, and
they also make your source code shorter and easier to read. In addition,
the .NET Framework conversion methods do not always produce the same results
as the Visual Basic functions, for example when converting Boolean to
Integer. For more information, see Troubleshooting Data Types."
In addition, although I'm a guy who always initializes strings and objects
as soon as possible rather than have them sit around until my algorithm
uses them- so I don't really care about the following- but, there's an
advantage to using VB's functions: they interpret "Nothing." You can't use the OO
methods on a string that is "Nothing" (s.ToUpper for instance won't work).
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:O7**************@TK2MSFTNGP14.phx.gbl... IMHO (and this has been debated for quite some time now), you should
view all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a
type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties of
the Date class
All string functions would be replaced with methods and properties of
the String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com... Book I am reading says that Cstr() is best method for efficency and
safety
however it doesnt compare that method of the .ToString() method.
Which is best.
Thanks
Wow, what happened to put you in this mood?
Checking if a variable actually contains data before doing a convert to
upper case is simply too much code. If you can avoid that it makes the code
a lot better readable.
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:ep**************@TK2MSFTNGP12.phx.gbl... You can't use the OO methods on a string that is "Nothing"
Why would you want to?
Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?
I'm guessing that On Error Resume Next is one of your friends too.
Bob Lehmann
"CMM" <cm*@nospam.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl... I don't think that's true at all. First off, CStr,CBool, Etc. are all
just
easier-to-read specialized wrappers around CType..... which in and of
itself is a special "VB" construct. The true "non-VB" casting operator is
DirectCast(...).
Contrary to what Scott M says you're SUPPOSED to use them. What's the
point of using VB if you're not going to use its special methods that make your
life easier? This is straight from the VB documentation:
"As a rule, you should use the Visual Basic type conversion functions in
preference to the .NET Framework methods such as ToString(), either on
the
Convert class or on an individual type structure or class. The Visual
Basic functions are designed for optimal interaction with Visual Basic code,
and
they also make your source code shorter and easier to read. In addition,
the .NET Framework conversion methods do not always produce the same results
as the Visual Basic functions, for example when converting Boolean to
Integer. For more information, see Troubleshooting Data Types."
In addition, although I'm a guy who always initializes strings and
objects
as soon as possible rather than have them sit around until my algorithm
uses them- so I don't really care about the following- but, there's an
advantage to using VB's functions: they interpret "Nothing." You can't use the OO
methods on a string that is "Nothing" (s.ToUpper for instance won't
work).
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:O7**************@TK2MSFTNGP14.phx.gbl... > IMHO (and this has been debated for quite some time now), you should
view > all of the old "data-type" specific functions as legacy functions and
> no
> longer use them. Instead, use the more object-oriented methods of a type. >
> CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
> .ToString
> All date/time functions would be replaced with methods and properties
> of
> the Date class
> All string functions would be replaced with methods and properties of the > String class.
>
> et all.
>
>
> "Sean" <Se**@discussions.microsoft.com> wrote in message
> news:68**********************************@microsof t.com...
>> Book I am reading says that Cstr() is best method for efficency and
>> safety
>> however it doesnt compare that method of the .ToString() method.
>>
>> Which is best.
>>
>> Thanks
>>
>>
>
>
Give that man a Kewpie doll!
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:ep**************@TK2MSFTNGP12.phx.gbl... You can't use the OO methods on a string that is "Nothing"
Why would you want to?
Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?
I'm guessing that On Error Resume Next is one of your friends too.
Bob Lehmann
"CMM" <cm*@nospam.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl... I don't think that's true at all. First off, CStr,CBool, Etc. are all
just
easier-to-read specialized wrappers around CType..... which in and of
itself is a special "VB" construct. The true "non-VB" casting operator is
DirectCast(...).
Contrary to what Scott M says you're SUPPOSED to use them. What's the
point of using VB if you're not going to use its special methods that make your
life easier? This is straight from the VB documentation:
"As a rule, you should use the Visual Basic type conversion functions in
preference to the .NET Framework methods such as ToString(), either on
the
Convert class or on an individual type structure or class. The Visual
Basic functions are designed for optimal interaction with Visual Basic code,
and
they also make your source code shorter and easier to read. In addition,
the .NET Framework conversion methods do not always produce the same results
as the Visual Basic functions, for example when converting Boolean to
Integer. For more information, see Troubleshooting Data Types."
In addition, although I'm a guy who always initializes strings and
objects
as soon as possible rather than have them sit around until my algorithm
uses them- so I don't really care about the following- but, there's an
advantage to using VB's functions: they interpret "Nothing." You can't use the OO
methods on a string that is "Nothing" (s.ToUpper for instance won't
work).
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:O7**************@TK2MSFTNGP14.phx.gbl... > IMHO (and this has been debated for quite some time now), you should
view > all of the old "data-type" specific functions as legacy functions and
> no
> longer use them. Instead, use the more object-oriented methods of a type. >
> CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
> .ToString
> All date/time functions would be replaced with methods and properties
> of
> the Date class
> All string functions would be replaced with methods and properties of the > String class.
>
> et all.
>
>
> "Sean" <Se**@discussions.microsoft.com> wrote in message
> news:68**********************************@microsof t.com...
>> Book I am reading says that Cstr() is best method for efficency and
>> safety
>> however it doesnt compare that method of the .ToString() method.
>>
>> Which is best.
>>
>> Thanks
>>
>>
>
>
>> Checking if a variable actually contains data before doing a convert ..
is simply too much code.
You aren't serious, are you? If you can avoid that it makes the code a lot better readable.
You mean like the sentence above? I'm sure you meant "a lot more better
readablest".
Happy coding, pal.
Bob Lehmann
"Martin" <x@y.com> wrote in message
news:uu**************@TK2MSFTNGP11.phx.gbl... Wow, what happened to put you in this mood?
Checking if a variable actually contains data before doing a convert to
upper case is simply too much code. If you can avoid that it makes the
code a lot better readable.
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:ep**************@TK2MSFTNGP12.phx.gbl... You can't use the OO methods on a string that is "Nothing"
Why would you want to?
Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?
I'm guessing that On Error Resume Next is one of your friends too.
Bob Lehmann
"CMM" <cm*@nospam.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl... I don't think that's true at all. First off, CStr,CBool, Etc. are all
just
easier-to-read specialized wrappers around CType..... which in and of
itself is a special "VB" construct. The true "non-VB" casting operator is
DirectCast(...).
Contrary to what Scott M says you're SUPPOSED to use them. What's the
point of using VB if you're not going to use its special methods that make
your life easier? This is straight from the VB documentation:
"As a rule, you should use the Visual Basic type conversion functions
in preference to the .NET Framework methods such as ToString(), either on
the
Convert class or on an individual type structure or class. The Visual
Basic functions are designed for optimal interaction with Visual Basic code,
and
they also make your source code shorter and easier to read. In
addition, the .NET Framework conversion methods do not always produce the same
results as the Visual Basic functions, for example when converting Boolean to
Integer. For more information, see Troubleshooting Data Types."
In addition, although I'm a guy who always initializes strings and
objects
as soon as possible rather than have them sit around until my algorithm
uses them- so I don't really care about the following- but, there's an
advantage to using VB's functions: they interpret "Nothing." You can't use the OO
methods on a string that is "Nothing" (s.ToUpper for instance won't
work).
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:O7**************@TK2MSFTNGP14.phx.gbl...
> IMHO (and this has been debated for quite some time now), you should
view > all of the old "data-type" specific functions as legacy functions and
> no
> longer use them. Instead, use the more object-oriented methods of a
type. >
> CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
> .ToString
> All date/time functions would be replaced with methods and properties
> of
> the Date class
> All string functions would be replaced with methods and properties of
the > String class.
>
> et all.
>
>
> "Sean" <Se**@discussions.microsoft.com> wrote in message
> news:68**********************************@microsof t.com...
>> Book I am reading says that Cstr() is best method for efficency and
>> safety
>> however it doesnt compare that method of the .ToString() method.
>>
>> Which is best.
>>
>> Thanks
>>
>>
>
>
Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:e6**************@tk2msftngp13.phx.gbl... Checking if a variable actually contains data before doing a convert .. is simply too much code.
You aren't serious, are you?
If you can avoid that it makes the code a lot better readable. You mean like the sentence above? I'm sure you meant "a lot more better
readablest".
Happy coding, pal.
Bob Lehmann
"Martin" <x@y.com> wrote in message
news:uu**************@TK2MSFTNGP11.phx.gbl... Wow, what happened to put you in this mood?
Checking if a variable actually contains data before doing a convert to
upper case is simply too much code. If you can avoid that it makes the
code a lot better readable.
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:ep**************@TK2MSFTNGP12.phx.gbl... >>> You can't use the OO methods on a string that is "Nothing"
>
> Why would you want to?
>
> Oh, I get it, you're too lazy to check the data before performing an
> operation it. Isn't checking your data a 100 level concept?
>
> I'm guessing that On Error Resume Next is one of your friends too.
>
> Bob Lehmann
>
> "CMM" <cm*@nospam.com> wrote in message
> news:%2******************@TK2MSFTNGP09.phx.gbl...
>> I don't think that's true at all. First off, CStr,CBool, Etc. are all
>> just
>> easier-to-read specialized wrappers around CType..... which in and of
> itself
>> is a special "VB" construct. The true "non-VB" casting operator is
>> DirectCast(...).
>>
>> Contrary to what Scott M says you're SUPPOSED to use them. What's the
> point
>> of using VB if you're not going to use its special methods that make
your >> life easier? This is straight from the VB documentation:
>>
>> "As a rule, you should use the Visual Basic type conversion functions in >> preference to the .NET Framework methods such as ToString(), either on
>> the
>> Convert class or on an individual type structure or class. The Visual
> Basic
>> functions are designed for optimal interaction with Visual Basic code,
>> and
>> they also make your source code shorter and easier to read. In addition, > the
>> .NET Framework conversion methods do not always produce the same results > as
>> the Visual Basic functions, for example when converting Boolean to
> Integer.
>> For more information, see Troubleshooting Data Types."
>>
>> In addition, although I'm a guy who always initializes strings and
>> objects
>> as soon as possible rather than have them sit around until my
>> algorithm
> uses
>> them- so I don't really care about the following- but, there's an
> advantage
>> to using VB's functions: they interpret "Nothing." You can't use the
>> OO
>> methods on a string that is "Nothing" (s.ToUpper for instance won't
>> work).
>>
>> --
>> -C. Moya
>> www.cmoya.com
>> "Scott M." <s-***@nospam.nospam> wrote in message
>> news:O7**************@TK2MSFTNGP14.phx.gbl...
>> > IMHO (and this has been debated for quite some time now), you should
> view
>> > all of the old "data-type" specific functions as legacy functions
>> > and
>> > no
>> > longer use them. Instead, use the more object-oriented methods of a
> type.
>> >
>> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
>> > .ToString
>> > All date/time functions would be replaced with methods and
>> > properties
>> > of
>> > the Date class
>> > All string functions would be replaced with methods and properties
>> > of
> the
>> > String class.
>> >
>> > et all.
>> >
>> >
>> > "Sean" <Se**@discussions.microsoft.com> wrote in message
>> > news:68**********************************@microsof t.com...
>> >> Book I am reading says that Cstr() is best method for efficency and
>> >> safety
>> >> however it doesnt compare that method of the .ToString() method.
>> >>
>> >> Which is best.
>> >>
>> >> Thanks
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Nonsense. CStr is not some VB6 (better term is VB.Classic) legacy thing....
in .NET it's just a convenience wrapper around CType... which when used to
cast to a string is simply a wrapper around the object's ToString("G"). I
personally tend to use ToString() as well on my own strings.... but when I'm
handling strings that come from functions that I know might return nulls I'd
tend to use CStr().... it's the same exact thing as typing out all your "If
bla Is Nothing" code that I'm sure litters your nasty code (or maybe it
doesn't.... which is just as bad).
P.S. I'm not sure you know what a Method vs. a Function vs. a Statement
is... at least judging from the poppycock vomited in your post.
--
-C. Moya www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:eB**************@TK2MSFTNGP15.phx.gbl...
"guy" <gu*@discussions.microsoft.com> wrote in message
news:21**********************************@microsof t.com... both points of view are valid, however i use the vb string methods as the
compiler makes optimzations that can improve performance over the native
.Net
methods, also i find the vb methods read better.
The VB 6.0 way are not methods, they are functions. The .NET way are
object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.
To answer your question, ToString would be my suggestion, rather than
CStr(). ToString is a method of the Object Type, and since all classes
inherit from Object, all objects have this method.
cheers
guy
"Scott M." wrote:
IMHO (and this has been debated for quite some time now), you should
view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a
type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties of
the
Date class
All string functions would be replaced with methods and properties of
the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com...
> Book I am reading says that Cstr() is best method for efficency and
> safety
> however it doesnt compare that method of the .ToString() method.
>
> Which is best.
>
> Thanks
>
>
>> Have you ever contibuted anything positive
Uh, yeah.
I suggested that checking your data before performing operations the data is
a best practice. I highly doubt that any competent programmer would
disagree. Apparently you are not in that group.
Or, is your specialty in buffer overruns?
At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."
Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo hard
to do. And besides, my code is better readable since you know I don't indent
If blocks.
Perhaps you should stick to scripting languages where you don't have all the
icky typed variable stuff going on. I mean, isn't it a hassle declaring all
those variable thingys, with all that code and stuff?
Maybe, after you've completed Junior High, you'll have a different
perspective. (or to anything else)
Yes, I don't write malware.
Bob Lehmann
"Martin" <x@y.com> wrote in message
news:eF*************@TK2MSFTNGP09.phx.gbl... Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:e6**************@tk2msftngp13.phx.gbl... Checking if a variable actually contains data before doing a convert
... is simply too much code.
You aren't serious, are you?
If you can avoid that it makes the code a lot better readable.
You mean like the sentence above? I'm sure you meant "a lot more better
readablest".
Happy coding, pal.
Bob Lehmann
"Martin" <x@y.com> wrote in message
news:uu**************@TK2MSFTNGP11.phx.gbl... Wow, what happened to put you in this mood?
Checking if a variable actually contains data before doing a convert to
upper case is simply too much code. If you can avoid that it makes the
code a lot better readable.
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:ep**************@TK2MSFTNGP12.phx.gbl...
>>> You can't use the OO methods on a string that is "Nothing"
>
> Why would you want to?
>
> Oh, I get it, you're too lazy to check the data before performing an
> operation it. Isn't checking your data a 100 level concept?
>
> I'm guessing that On Error Resume Next is one of your friends too.
>
> Bob Lehmann
>
> "CMM" <cm*@nospam.com> wrote in message
> news:%2******************@TK2MSFTNGP09.phx.gbl...
>> I don't think that's true at all. First off, CStr,CBool, Etc. are
all >> just
>> easier-to-read specialized wrappers around CType..... which in and
of > itself
>> is a special "VB" construct. The true "non-VB" casting operator is
>> DirectCast(...).
>>
>> Contrary to what Scott M says you're SUPPOSED to use them. What's
the > point
>> of using VB if you're not going to use its special methods that make
your >> life easier? This is straight from the VB documentation:
>>
>> "As a rule, you should use the Visual Basic type conversion
functions in >> preference to the .NET Framework methods such as ToString(), either
on >> the
>> Convert class or on an individual type structure or class. The
Visual > Basic
>> functions are designed for optimal interaction with Visual Basic
code, >> and
>> they also make your source code shorter and easier to read. In
addition, > the
>> .NET Framework conversion methods do not always produce the same
results > as
>> the Visual Basic functions, for example when converting Boolean to
> Integer.
>> For more information, see Troubleshooting Data Types."
>>
>> In addition, although I'm a guy who always initializes strings and
>> objects
>> as soon as possible rather than have them sit around until my
>> algorithm
> uses
>> them- so I don't really care about the following- but, there's an
> advantage
>> to using VB's functions: they interpret "Nothing." You can't use the
>> OO
>> methods on a string that is "Nothing" (s.ToUpper for instance won't
>> work).
>>
>> --
>> -C. Moya
>> www.cmoya.com
>> "Scott M." <s-***@nospam.nospam> wrote in message
>> news:O7**************@TK2MSFTNGP14.phx.gbl...
>> > IMHO (and this has been debated for quite some time now), you
should > view
>> > all of the old "data-type" specific functions as legacy functions
>> > and
>> > no
>> > longer use them. Instead, use the more object-oriented methods of
a > type.
>> >
>> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
>> > .ToString
>> > All date/time functions would be replaced with methods and
>> > properties
>> > of
>> > the Date class
>> > All string functions would be replaced with methods and properties
>> > of
> the
>> > String class.
>> >
>> > et all.
>> >
>> >
>> > "Sean" <Se**@discussions.microsoft.com> wrote in message
>> > news:68**********************************@microsof t.com...
>> >> Book I am reading says that Cstr() is best method for efficency
and >> >> safety
>> >> however it doesnt compare that method of the .ToString() method.
>> >>
>> >> Which is best.
>> >>
>> >> Thanks
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Finishing junior high may be your problem. I have a real education ;-)
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:ub**************@TK2MSFTNGP09.phx.gbl... Have you ever contibuted anything positive Uh, yeah.
I suggested that checking your data before performing operations the data
is
a best practice. I highly doubt that any competent programmer would
disagree. Apparently you are not in that group.
Or, is your specialty in buffer overruns?
At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."
Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo
hard
to do. And besides, my code is better readable since you know I don't
indent
If blocks.
Perhaps you should stick to scripting languages where you don't have all
the
icky typed variable stuff going on. I mean, isn't it a hassle declaring
all
those variable thingys, with all that code and stuff?
Maybe, after you've completed Junior High, you'll have a different
perspective.
(or to anything else) Yes, I don't write malware.
Bob Lehmann
"Martin" <x@y.com> wrote in message
news:eF*************@TK2MSFTNGP09.phx.gbl... Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:e6**************@tk2msftngp13.phx.gbl... >>> Checking if a variable actually contains data before doing a convert
.. > is simply too much code.
> You aren't serious, are you?
>
>>> If you can avoid that it makes the code a lot better readable.
> You mean like the sentence above? I'm sure you meant "a lot more better
> readablest".
>
> Happy coding, pal.
>
> Bob Lehmann
>
> "Martin" <x@y.com> wrote in message
> news:uu**************@TK2MSFTNGP11.phx.gbl...
>> Wow, what happened to put you in this mood?
>> Checking if a variable actually contains data before doing a convert
>> to
>> upper case is simply too much code. If you can avoid that it makes the
> code
>> a lot better readable.
>>
>>
>> "Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
>> news:ep**************@TK2MSFTNGP12.phx.gbl...
>> >>> You can't use the OO methods on a string that is "Nothing"
>> >
>> > Why would you want to?
>> >
>> > Oh, I get it, you're too lazy to check the data before performing an
>> > operation it. Isn't checking your data a 100 level concept?
>> >
>> > I'm guessing that On Error Resume Next is one of your friends too.
>> >
>> > Bob Lehmann
>> >
>> > "CMM" <cm*@nospam.com> wrote in message
>> > news:%2******************@TK2MSFTNGP09.phx.gbl...
>> >> I don't think that's true at all. First off, CStr,CBool, Etc. are all >> >> just
>> >> easier-to-read specialized wrappers around CType..... which in and of >> > itself
>> >> is a special "VB" construct. The true "non-VB" casting operator is
>> >> DirectCast(...).
>> >>
>> >> Contrary to what Scott M says you're SUPPOSED to use them. What's the >> > point
>> >> of using VB if you're not going to use its special methods that
>> >> make
> your
>> >> life easier? This is straight from the VB documentation:
>> >>
>> >> "As a rule, you should use the Visual Basic type conversion functions > in
>> >> preference to the .NET Framework methods such as ToString(), either on >> >> the
>> >> Convert class or on an individual type structure or class. The Visual >> > Basic
>> >> functions are designed for optimal interaction with Visual Basic code, >> >> and
>> >> they also make your source code shorter and easier to read. In
> addition,
>> > the
>> >> .NET Framework conversion methods do not always produce the same
> results
>> > as
>> >> the Visual Basic functions, for example when converting Boolean to
>> > Integer.
>> >> For more information, see Troubleshooting Data Types."
>> >>
>> >> In addition, although I'm a guy who always initializes strings and
>> >> objects
>> >> as soon as possible rather than have them sit around until my
>> >> algorithm
>> > uses
>> >> them- so I don't really care about the following- but, there's an
>> > advantage
>> >> to using VB's functions: they interpret "Nothing." You can't use
>> >> the
>> >> OO
>> >> methods on a string that is "Nothing" (s.ToUpper for instance won't
>> >> work).
>> >>
>> >> --
>> >> -C. Moya
>> >> www.cmoya.com
>> >> "Scott M." <s-***@nospam.nospam> wrote in message
>> >> news:O7**************@TK2MSFTNGP14.phx.gbl...
>> >> > IMHO (and this has been debated for quite some time now), you should >> > view
>> >> > all of the old "data-type" specific functions as legacy functions
>> >> > and
>> >> > no
>> >> > longer use them. Instead, use the more object-oriented methods
>> >> > of a >> > type.
>> >> >
>> >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
>> >> > .ToString
>> >> > All date/time functions would be replaced with methods and
>> >> > properties
>> >> > of
>> >> > the Date class
>> >> > All string functions would be replaced with methods and
>> >> > properties
>> >> > of
>> > the
>> >> > String class.
>> >> >
>> >> > et all.
>> >> >
>> >> >
>> >> > "Sean" <Se**@discussions.microsoft.com> wrote in message
>> >> > news:68**********************************@microsof t.com...
>> >> >> Book I am reading says that Cstr() is best method for efficency and >> >> >> safety
>> >> >> however it doesnt compare that method of the .ToString() method.
>> >> >>
>> >> >> Which is best.
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
I think you better read your own post. CStr() is a built-in function of the
VB 6 language. It is not a method. ToString is a method of the Object type
(which all classes in .NET derive from). So, I'm not sure why you feel the
need to call this poppycock and suggest that I don't know what a function
vs. a method is.
As for which is better... As I said in my first post, it is a matter of
choice and I prefer the more object-oriented ToString object method.
"CMM" <cm*@nospam.com> wrote in message
news:ed**************@TK2MSFTNGP11.phx.gbl... Nonsense. CStr is not some VB6 (better term is VB.Classic) legacy
thing.... in .NET it's just a convenience wrapper around CType... which
when used to cast to a string is simply a wrapper around the object's
ToString("G"). I personally tend to use ToString() as well on my own
strings.... but when I'm handling strings that come from functions that I
know might return nulls I'd tend to use CStr().... it's the same exact
thing as typing out all your "If bla Is Nothing" code that I'm sure
litters your nasty code (or maybe it doesn't.... which is just as bad).
P.S. I'm not sure you know what a Method vs. a Function vs. a Statement
is... at least judging from the poppycock vomited in your post.
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:eB**************@TK2MSFTNGP15.phx.gbl...
"guy" <gu*@discussions.microsoft.com> wrote in message
news:21**********************************@microsof t.com... both points of view are valid, however i use the vb string methods as
the
compiler makes optimzations that can improve performance over the native
.Net
methods, also i find the vb methods read better.
The VB 6.0 way are not methods, they are functions. The .NET way are
object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.
To answer your question, ToString would be my suggestion, rather than
CStr(). ToString is a method of the Object Type, and since all classes
inherit from Object, all objects have this method.
cheers
guy
"Scott M." wrote:
IMHO (and this has been debated for quite some time now), you should
view
all of the old "data-type" specific functions as legacy functions and
no
longer use them. Instead, use the more object-oriented methods of a
type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties
of the
Date class
All string functions would be replaced with methods and properties of
the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com...
> Book I am reading says that Cstr() is best method for efficency and
> safety
> however it doesnt compare that method of the .ToString() method.
>
> Which is best.
>
> Thanks
>
>
> Contrary to what Scott M says you're SUPPOSED to use them. What's the point of using VB if you're not going to use its special methods that make
your life easier?
You should really relax and read what was posted. If you were supposed to
use the legacy conversion functions and not the .NET ToString and CType,
then why would MS add them in the first place.
My post started with IMHO and that much has been debated about this before.
Your opinion is fine, but it is just that. Wrappers have their own
downside, which tend to be more CPU cycles.
well .........
option 1
dim x as string
----- some stuff here that might or might not fill the string
if not x is nothing then
if x.length>0 then
---- do your stuff
end if
end if
option 2
dim x as string = ""
----- some stuff here that might or might not fill the string
if x.length>0 then
---- do your stuff
end if
option 3
dim x as string
----- some stuff here that might or might not fill the string
if len(x)>0 then
---- do your stuff
end if
Well In My Homble Opinion it all depends on a few factors what should favor
you
1. your personal coding style
2. design of your app ( if constructs like this happen a lot you might save
some typing with option 2 or 3 )
3. portability need to other .Net languages
I believe that option 1 and 3 are the same , although it is written
different option 2 is the practical guideline for VB and C# and is probably
the fastest and time sparing ( prevents RSI the most :-) )
regards
Michel Posseth [MCP]
"Scott M." <s-***@nospam.nospam> schreef in bericht
news:um**************@TK2MSFTNGP14.phx.gbl... Contrary to what Scott M says you're SUPPOSED to use them. What's the
point of using VB if you're not going to use its special methods that
make your life easier?
You should really relax and read what was posted. If you were supposed to
use the legacy conversion functions and not the .NET ToString and CType,
then why would MS add them in the first place.
My post started with IMHO and that much has been debated about this
before.
Your opinion is fine, but it is just that. Wrappers have their own
downside, which tend to be more CPU cycles.
"CMM" <cm*@nospam.com> schrieb: I don't think that's true at all. First off, CStr,CBool, Etc. are all just
easier-to-read specialized wrappers around CType..... which in and of
itself is a special "VB" construct.
ACK. While it doesn't matter if you use 'C<Type>' or 'CType(..., <Type>)',
I strongly recommend to use them instead of 'Convert.To*'.
The true "non-VB" casting operator is DirectCast(...).
.... which doesn't mean that 'DirectCast' should not be used. Personally I
prefer 'CType' for value types (type conversions) and 'DirectCast' for type
casts (reference types). However, some other people prefer to use 'CType'
instead of 'DirectCast'.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Bob Lehmann" <no****@dontbotherme.zzz> schrieb: You can't use the OO methods on a string that is "Nothing"
Why would you want to?
Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?
Why type 'If s IsNot Nothing AndAlso s.Length > 0 Then' if you could shorten
it to 'If Len(s) > 0 Then'? The same applies to 'ToString' vs. 'CStr': Why
type
\\\
If o Is Nothing Then
s = ""
Else
s = o.ToString()
End If
///
if you could archieve the same by using
\\\
s = CStr(o)
///
?
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Bob Lehmann" <no****@dontbotherme.zzz> schrieb: At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."
Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo
hard
to do. And besides, my code is better readable since you know I don't
indent
If blocks.
Well, why duplicate this checking code all over the source code if it is
possible to encapsulate it cleanly in high-level wrappers/functions like
'CStr'?
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Scott M." <s-***@nospam.nospam> schrieb: both points of view are valid, however i use the vb string methods as the
compiler makes optimzations that can improve performance over the native
.Net
methods, also i find the vb methods read better.
The VB 6.0 way are not methods, they are functions. The .NET way are
object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.
Does this really matter? The JIT compiler could inline the type conversion
functions.
To answer your question, ToString would be my suggestion, rather than
CStr(). ToString is a method of the Object Type, and since all classes
inherit from Object, all objects have this method.
'ToString' and 'CStr' serve different purposes. 'ToString' won't work on
'Nothing' references, which is a downside /if/ a 'Nothing' reference should
be converted to an empty string. That's exactly where 'CStr' can be used.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Thanks CMM, what you wrote is what I thought was true and I was looking for a
comfirmation.
As far as Scott goes I was refering to a "method" using the meaning of the
word "a way to". For my purposes it couldnt matter less if its a function or
a method.
"CMM" wrote: I don't think that's true at all. First off, CStr,CBool, Etc. are all just
easier-to-read specialized wrappers around CType..... which in and of itself
is a special "VB" construct. The true "non-VB" casting operator is
DirectCast(...).
Contrary to what Scott M says you're SUPPOSED to use them. What's the point
of using VB if you're not going to use its special methods that make your
life easier? This is straight from the VB documentation:
"As a rule, you should use the Visual Basic type conversion functions in
preference to the .NET Framework methods such as ToString(), either on the
Convert class or on an individual type structure or class. The Visual Basic
functions are designed for optimal interaction with Visual Basic code, and
they also make your source code shorter and easier to read. In addition, the
..NET Framework conversion methods do not always produce the same results as
the Visual Basic functions, for example when converting Boolean to Integer.
For more information, see Troubleshooting Data Types."
In addition, although I'm a guy who always initializes strings and objects
as soon as possible rather than have them sit around until my algorithm uses
them- so I don't really care about the following- but, there's an advantage
to using VB's functions: they interpret "Nothing." You can't use the OO
methods on a string that is "Nothing" (s.ToUpper for instance won't work).
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:O7**************@TK2MSFTNGP14.phx.gbl... IMHO (and this has been debated for quite some time now), you should view
all of the old "data-type" specific functions as legacy functions and no
longer use them. Instead, use the more object-oriented methods of a type.
CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
.ToString
All date/time functions would be replaced with methods and properties of
the Date class
All string functions would be replaced with methods and properties of the
String class.
et all.
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com... Book I am reading says that Cstr() is best method for efficency and
safety
however it doesnt compare that method of the .ToString() method.
Which is best.
Thanks
>> The VB 6.0 way are not methods, they are functions. The .NET way are object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.
Does this really matter? The JIT compiler could inline the type
conversion functions.
I was merely pointing out the inacurracy of the previous post. I'll leave
it up to the reader to determine if they care about the details.
To answer your question, ToString would be my suggestion, rather than
CStr(). ToString is a method of the Object Type, and since all classes
inherit from Object, all objects have this method.
'ToString' and 'CStr' serve different purposes. 'ToString' won't work on
'Nothing' references, which is a downside /if/ a 'Nothing' reference
should be converted to an empty string. That's exactly where 'CStr' can
be used.
As stated by others already, good programming practice would dictate that
data should be validated before being converted. So, I suppose I could say,
"Does it really matter since any good programmer would be checking for
nothing before converting the data?".
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Same answer as when you asked the same question earilier in the thread.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... "Bob Lehmann" <no****@dontbotherme.zzz> schrieb: You can't use the OO methods on a string that is "Nothing"
Why would you want to?
Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?
Why type 'If s IsNot Nothing AndAlso s.Length > 0 Then' if you could
shorten it to 'If Len(s) > 0 Then'? The same applies to 'ToString' vs.
'CStr': Why type
\\\
If o Is Nothing Then
s = ""
Else
s = o.ToString()
End If
///
if you could archieve the same by using
\\\
s = CStr(o)
///
?
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Because CStr() wouldn't throw an exception if it encountered a Nothing
value, which could cause unexpected bugs in the application. ToString would
throw an exception and thus make it easier to determine the problem.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uY*************@TK2MSFTNGP15.phx.gbl... "Bob Lehmann" <no****@dontbotherme.zzz> schrieb: At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."
Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo
hard
to do. And besides, my code is better readable since you know I don't
indent
If blocks.
Well, why duplicate this checking code all over the source code if it is
possible to encapsulate it cleanly in high-level wrappers/functions like
'CStr'?
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
To add to this, you can't use DirectCast on anything but Reference Types
anyway, so CType will need to be used for all numeric casting anyway.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... "CMM" <cm*@nospam.com> schrieb:I don't think that's true at all. First off, CStr,CBool, Etc. are all just
easier-to-read specialized wrappers around CType..... which in and of
itself is a special "VB" construct.
ACK. While it doesn't matter if you use 'C<Type>' or 'CType(...,
<Type>)', I strongly recommend to use them instead of 'Convert.To*'.
The true "non-VB" casting operator is DirectCast(...).
... which doesn't mean that 'DirectCast' should not be used. Personally I
prefer 'CType' for value types (type conversions) and 'DirectCast' for
type casts (reference types). However, some other people prefer to use
'CType' instead of 'DirectCast'.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Then you should absolutely go with your preference, which is what I said in
the first place. I merely indicated what my preference was and why.
Good luck!
"Sean" <Se**@discussions.microsoft.com> wrote in message
news:BD**********************************@microsof t.com... Thanks CMM, what you wrote is what I thought was true and I was looking
for a
comfirmation.
As far as Scott goes I was refering to a "method" using the meaning of the
word "a way to". For my purposes it couldnt matter less if its a function
or
a method.
"CMM" wrote:
I don't think that's true at all. First off, CStr,CBool, Etc. are all
just
easier-to-read specialized wrappers around CType..... which in and of
itself
is a special "VB" construct. The true "non-VB" casting operator is
DirectCast(...).
Contrary to what Scott M says you're SUPPOSED to use them. What's the
point
of using VB if you're not going to use its special methods that make your
life easier? This is straight from the VB documentation:
"As a rule, you should use the Visual Basic type conversion functions in
preference to the .NET Framework methods such as ToString(), either on
the
Convert class or on an individual type structure or class. The Visual
Basic
functions are designed for optimal interaction with Visual Basic code,
and
they also make your source code shorter and easier to read. In addition,
the
..NET Framework conversion methods do not always produce the same results
as
the Visual Basic functions, for example when converting Boolean to
Integer.
For more information, see Troubleshooting Data Types."
In addition, although I'm a guy who always initializes strings and
objects
as soon as possible rather than have them sit around until my algorithm
uses
them- so I don't really care about the following- but, there's an
advantage
to using VB's functions: they interpret "Nothing." You can't use the OO
methods on a string that is "Nothing" (s.ToUpper for instance won't
work).
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:O7**************@TK2MSFTNGP14.phx.gbl... > IMHO (and this has been debated for quite some time now), you should
> view
> all of the old "data-type" specific functions as legacy functions and
> no
> longer use them. Instead, use the more object-oriented methods of a
> type.
>
> CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or
> .ToString
> All date/time functions would be replaced with methods and properties
> of
> the Date class
> All string functions would be replaced with methods and properties of
> the
> String class.
>
> et all.
>
>
> "Sean" <Se**@discussions.microsoft.com> wrote in message
> news:68**********************************@microsof t.com...
>> Book I am reading says that Cstr() is best method for efficency and
>> safety
>> however it doesnt compare that method of the .ToString() method.
>>
>> Which is best.
>>
>> Thanks
>>
>>
>
>
"Scott M." <s-***@nospam.nospam> schrieb: Because CStr() wouldn't throw an exception if it encountered a Nothing
value, which could cause unexpected bugs in the application. ToString
would throw an exception and thus make it easier to determine the problem.
Well, but there are cases where I'd call 'CStr' intentionally because I want
a 'Nothing' reference to be converted to an empty string!
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
I hear what you are saying, but as I said in the previous post, using CStr()
wouldn't allow you to discriminate between those Nothing values that you
intended to run across and Nothing values that inadvertantly may happen. As
others have said, a simple If statement that checks for the Nothing value
would allow you to get a Nothing value and convert it to an empty string
while still maintaining the integrety of the code.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uu*************@tk2msftngp13.phx.gbl... "Scott M." <s-***@nospam.nospam> schrieb: Because CStr() wouldn't throw an exception if it encountered a Nothing
value, which could cause unexpected bugs in the application. ToString
would throw an exception and thus make it easier to determine the
problem.
Well, but there are cases where I'd call 'CStr' intentionally because I
want a 'Nothing' reference to be converted to an empty string!
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Scott M." <s-***@nospam.nospam> schrieb: I hear what you are saying, but as I said in the previous post, using
CStr() wouldn't allow you to discriminate between those Nothing values that
you intended to run across and Nothing values that inadvertantly may
happen. As others have said, a simple If statement that checks for the
Nothing value would allow you to get a Nothing value and convert it to an
empty string while still maintaining the integrety of the code.
'CStr' is different from 'ToString'. It's obvious that it doesn't behave
like 'ToString', and the additional behavior is publically well-known. So
using 'CStr' *iff* it makes sense does not break the integrity of the code.
It's the developer's fault if it breaks integrity.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
> data should be validated before being converted. So, I suppose I could say, "Does it really matter since any good programmer would be checking
for nothing before converting the data?".
They are doing it! Except they're using CStr to do it! It "checks" for the
programmer. Unless you actually need to do something ELSE based on whether a
string is Nothing, it's astronomically stupid to do what you say. I mean,
come on....
If s is Nothing Then
Return ""
Else
Return s.ToString()
End If
Why? That's exactly what CStr does.
--
-C. Moya www.cmoya.com
>> I have a real education
Which you have demonstrated, admirably.
Bob Lehmann
"Martin" <x@y.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... Finishing junior high may be your problem. I have a real education ;-)
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:ub**************@TK2MSFTNGP09.phx.gbl... Have you ever contibuted anything positive
Uh, yeah.
I suggested that checking your data before performing operations the
data is
a best practice. I highly doubt that any competent programmer would
disagree. Apparently you are not in that group.
Or, is your specialty in buffer overruns?
At least you have a sound rationale -
"Checking if a variable actually contains data before doing a convert to
upper case is simply too much code."
Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo
hard
to do. And besides, my code is better readable since you know I don't
indent
If blocks.
Perhaps you should stick to scripting languages where you don't have all
the
icky typed variable stuff going on. I mean, isn't it a hassle declaring
all
those variable thingys, with all that code and stuff?
Maybe, after you've completed Junior High, you'll have a different
perspective.
(or to anything else)
Yes, I don't write malware.
Bob Lehmann
"Martin" <x@y.com> wrote in message
news:eF*************@TK2MSFTNGP09.phx.gbl... Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else)
"Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
news:e6**************@tk2msftngp13.phx.gbl...
>>> Checking if a variable actually contains data before doing a
convert .. > is simply too much code.
> You aren't serious, are you?
>
>>> If you can avoid that it makes the code a lot better readable.
> You mean like the sentence above? I'm sure you meant "a lot more
better > readablest".
>
> Happy coding, pal.
>
> Bob Lehmann
>
> "Martin" <x@y.com> wrote in message
> news:uu**************@TK2MSFTNGP11.phx.gbl...
>> Wow, what happened to put you in this mood?
>> Checking if a variable actually contains data before doing a convert
>> to
>> upper case is simply too much code. If you can avoid that it makes
the > code
>> a lot better readable.
>>
>>
>> "Bob Lehmann" <no****@dontbotherme.zzz> wrote in message
>> news:ep**************@TK2MSFTNGP12.phx.gbl...
>> >>> You can't use the OO methods on a string that is "Nothing"
>> >
>> > Why would you want to?
>> >
>> > Oh, I get it, you're too lazy to check the data before performing
an >> > operation it. Isn't checking your data a 100 level concept?
>> >
>> > I'm guessing that On Error Resume Next is one of your friends too.
>> >
>> > Bob Lehmann
>> >
>> > "CMM" <cm*@nospam.com> wrote in message
>> > news:%2******************@TK2MSFTNGP09.phx.gbl...
>> >> I don't think that's true at all. First off, CStr,CBool, Etc. are
all >> >> just
>> >> easier-to-read specialized wrappers around CType..... which in
and of >> > itself
>> >> is a special "VB" construct. The true "non-VB" casting operator
is >> >> DirectCast(...).
>> >>
>> >> Contrary to what Scott M says you're SUPPOSED to use them. What's
the >> > point
>> >> of using VB if you're not going to use its special methods that
>> >> make
> your
>> >> life easier? This is straight from the VB documentation:
>> >>
>> >> "As a rule, you should use the Visual Basic type conversion
functions > in
>> >> preference to the .NET Framework methods such as ToString(),
either on >> >> the
>> >> Convert class or on an individual type structure or class. The
Visual >> > Basic
>> >> functions are designed for optimal interaction with Visual Basic
code, >> >> and
>> >> they also make your source code shorter and easier to read. In
> addition,
>> > the
>> >> .NET Framework conversion methods do not always produce the same
> results
>> > as
>> >> the Visual Basic functions, for example when converting Boolean
to >> > Integer.
>> >> For more information, see Troubleshooting Data Types."
>> >>
>> >> In addition, although I'm a guy who always initializes strings
and >> >> objects
>> >> as soon as possible rather than have them sit around until my
>> >> algorithm
>> > uses
>> >> them- so I don't really care about the following- but, there's an
>> > advantage
>> >> to using VB's functions: they interpret "Nothing." You can't use
>> >> the
>> >> OO
>> >> methods on a string that is "Nothing" (s.ToUpper for instance
won't >> >> work).
>> >>
>> >> --
>> >> -C. Moya
>> >> www.cmoya.com
>> >> "Scott M." <s-***@nospam.nospam> wrote in message
>> >> news:O7**************@TK2MSFTNGP14.phx.gbl...
>> >> > IMHO (and this has been debated for quite some time now), you
should >> > view
>> >> > all of the old "data-type" specific functions as legacy
functions >> >> > and
>> >> > no
>> >> > longer use them. Instead, use the more object-oriented methods
>> >> > of
a >> > type.
>> >> >
>> >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType
or >> >> > .ToString
>> >> > All date/time functions would be replaced with methods and
>> >> > properties
>> >> > of
>> >> > the Date class
>> >> > All string functions would be replaced with methods and
>> >> > properties
>> >> > of
>> > the
>> >> > String class.
>> >> >
>> >> > et all.
>> >> >
>> >> >
>> >> > "Sean" <Se**@discussions.microsoft.com> wrote in message
>> >> > news:68**********************************@microsof t.com...
>> >> >> Book I am reading says that Cstr() is best method for
efficency and >> >> >> safety
>> >> >> however it doesnt compare that method of the .ToString()
method. >> >> >>
>> >> >> Which is best.
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Would you make the same argument for CInt?
Say you wanted to exclude unanswered questions on a survey where you will
average a 0 to 4 rating.
0 <> Nothing.
Bob Lehmann
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... "Bob Lehmann" <no****@dontbotherme.zzz> schrieb: You can't use the OO methods on a string that is "Nothing"
Why would you want to?
Oh, I get it, you're too lazy to check the data before performing an
operation it. Isn't checking your data a 100 level concept?
Why type 'If s IsNot Nothing AndAlso s.Length > 0 Then' if you could
shorten it to 'If Len(s) > 0 Then'? The same applies to 'ToString' vs. 'CStr':
Why type
\\\
If o Is Nothing Then
s = ""
Else
s = o.ToString()
End If
///
if you could archieve the same by using
\\\
s = CStr(o)
///
?
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Well, thanks for calling me stupid. If you would calm down and READ my
other posts, I have addressed why CStr() is actually more dangerous to use
than ToString.
Try to just understand what I'm saying for a moment...If you rely on CStr()
to do your validation checks, then it will allow all Nothing values and
would not be able to alert YOU the programmer to a validation error unless
you add an if statement of your own that checks for "".
Your example code of what I'd write is inaccurate given that if s Is
Nothing, I wouldn't want and empty string in its place, I'd probably WANT an
exception.
If you just want to rant to hear yourself, fine - - but you seem like you
are being rather close minded to the benefits of structuring your code in a
more object oriented way. You also seem to believe that saving a few
keystrokes of code is always better than not adding a few more important
lines of code.
Let me ask you something, what would you write if you didn't want to proceed
with your string data when the user hasn't entered any data? I imagine the
code would look very similar to what you wrote below as an example of what
you'd need to write with ToString. And given that the 2 solutions are so
similar, why not choose the more OO way of writing it?
"CMM" <cm*@nospam.com> wrote in message
news:OI**************@TK2MSFTNGP12.phx.gbl... data should be validated before being converted. So, I suppose I could
say, "Does it really matter since any good programmer would be checking
for nothing before converting the data?".
They are doing it! Except they're using CStr to do it! It "checks" for the
programmer. Unless you actually need to do something ELSE based on whether
a string is Nothing, it's astronomically stupid to do what you say. I
mean, come on....
If s is Nothing Then
Return ""
Else
Return s.ToString()
End If
Why? That's exactly what CStr does.
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> schrieb: Try to just understand what I'm saying for a moment...If you rely on
CStr() to do your validation checks, then it will allow all Nothing values
and would not be able to alert YOU the programmer to a validation error
unless you add an if statement of your own that checks for "".
Your example code of what I'd write is inaccurate given that if s Is
Nothing, I wouldn't want and empty string in its place, I'd probably WANT
an exception.
Huh?! You are mixing up cases. CMM and I simply said that generally
recommending not to use 'CStr' at all is plain stupid. If you /want/ an
exception to be thrown, simply do not use 'CStr'!
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
>So using 'CStr' *iff* it makes sense does not break the integrity of the code.
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Well, yeah! Yiou seem to now agree with me that using CStr() doesn't
*always* make sense. That's all I've been trying to say...CStr() can get
you into trouble in certain situations. And when it does, it can be
difficult to troubleshoot where the problem is due to the *valid*, but empty
string floating around in memory. ToString can get you into trouble as
well, but it's a whole lot easier to see where the problem is in the
ToString scenario. And if you want to avoid the empty string possibility of
CStr(), you are going to need an IF statement to check the string, just as
you would need to check the string for Nothing using ToString, so there's no
code savings that others have indicated there would be.
As for the additional behavior of CStr() being well known, I highly
disagree. This whole thread (and countless others) started off with the OP
confused over the difference between CStr() and .ToString.
"Scott M." <s-***@nospam.nospam> schrieb: So using 'CStr' *iff* it makes sense does not break the integrity of the
code. Well, yeah! Yiou seem to now agree with me that using CStr() doesn't
*always* make sense. That's all I've been trying to say...CStr() can get
you into trouble in certain situations.
Well, I'm glad we agree on this point too :-).
As for the additional behavior of CStr() being well known, I highly
disagree. This whole thread (and countless others) started off with the
OP confused over the difference between CStr() and .ToString.
I think this problem always arises if people are using tools they do not
fully understand.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
>> think this problem always arises if people are using tools they do not
fully understand.
Which could be avoided if best practices were followed to begin with, and
not fueled by bad advice.
Bob Lehmann
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OC**************@TK2MSFTNGP11.phx.gbl... "Scott M." <s-***@nospam.nospam> schrieb:So using 'CStr' *iff* it makes sense does not break the integrity of
thecode.
Well, yeah! Yiou seem to now agree with me that using CStr() doesn't
*always* make sense. That's all I've been trying to say...CStr() can
get you into trouble in certain situations.
Well, I'm glad we agree on this point too :-).
As for the additional behavior of CStr() being well known, I highly
disagree. This whole thread (and countless others) started off with the
OP confused over the difference between CStr() and .ToString.
I think this problem always arises if people are using tools they do not
fully understand.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Yes and then the question is who defines the best practices and guidelines
???
cause past week i showed some examples from the best practices and
guidelines book i have ( oficial MS press book written by the core
reference writer )
and you should have seen the thread :-)
so question is ........ who defines this then ,,,,, every sole developer for
himself apperently ,,,, so in the end we stay with the same coding mess
regards
M. Posseth [MCP]
"Bob Lehmann" <no****@dontbotherme.zzz> schreef in bericht
news:u%***************@tk2msftngp13.phx.gbl... think this problem always arises if people are using tools they do not fully understand.
Which could be avoided if best practices were followed to begin with, and
not fueled by bad advice.
Bob Lehmann
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OC**************@TK2MSFTNGP11.phx.gbl... "Scott M." <s-***@nospam.nospam> schrieb: > >So using 'CStr' *iff* it makes sense does not break the integrity of
the > >code.
> Well, yeah! Yiou seem to now agree with me that using CStr() doesn't
> *always* make sense. That's all I've been trying to say...CStr() can get > you into trouble in certain situations.
Well, I'm glad we agree on this point too :-).
> As for the additional behavior of CStr() being well known, I highly
> disagree. This whole thread (and countless others) started off with
> the
> OP confused over the difference between CStr() and .ToString.
I think this problem always arises if people are using tools they do not
fully understand.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Herfried, Huh?! You are mixing up cases. CMM and I simply said that generally
recommending not to use 'CStr' at all is plain stupid.
Good catch,
Cor
Carlos If s is Nothing Then
Return ""
Else
Return s.ToString()
End If
This is in my opinion only nececarry if you declare s as Object and use
reflection or latebinding to do your job.
If s is a member of an object it is forever needed to test on the existence
of the object.
Because that the ToString is one of the base members and not much more
characthers to type do I use forever ToString, although I have to admit that
it is not consistent.
So seeing what you wrote in this thread we agree, with the exception of
course of doing instructions to instance not needed with an not used value.
:-)
Cor
Scott,
The VB 6.0 way are not methods, they are functions. The .NET way are
object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.
What you write is true, however we are talking about dotNet her. In dotNet
all methods are Methods even if you call them functions. It does not matter
if they are placed in the System Namespace or placed in whatever namespace
including your own.
In the Visual Basic namespace are many methods which are more optimized in
whatever way than the standard system.Net methods. Some are just wrappers
with backward compatible reasons (but absolute not all).
This optimized can be to make it easier and more descripting writing a
program.
By instance IsDate what is nothing more than a convert in a try block,
however much easier to write or by instance a Find method which is twice as
fast as an IndexOf a full string.
Just my opinion
Cor
"Bob Lehmann" <no****@dontbotherme.zzz> schrieb: think this problem always arises if people are using tools they do not
fully understand.
Which could be avoided if best practices were followed to begin with, and
not fueled by bad advice.
Using 'CStr' whenever it /makes sense/ is good practice.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message Using 'CStr' whenever it /makes sense/ is good practice.
Always has been always will be. If one doesn't like VB's specialized helper
functions and methods, maybe they shouldn't be coding in VB. And, to call
them "legacy" is both ignorant and shortsighted. They are what make VB "VB."
Chances are at some point people like Scott M will realize what
"encapsulation" means and write their own SafeToString(object) helper
function... not really realizing (or caring) that they had this all along.
--
-C. Moya www.cmoya.com
> ToString scenario. And if you want to avoid the empty string possibility of CStr(), you are going to need an IF statement to check the string, just
as you would need to check the string for Nothing using ToString, so
there's no code savings that others have indicated there would be.
Ever heard of encapsulation? If your code is littered with Is Nothing checks
all over the place just to process a string you've missed the point of
modern procedural programming.
That's all I've been trying to say...CStr() can get you into trouble in
certain situations. And when it does, it can be difficult to troubleshoot
where the problem is due to the *valid*, but empty string floating around
in memory.
Name one situation.
In almost all situations you'd usually want to treat a Nothing string as
Empty. Caring whether it's actually Nothing is the exception and not
something to base an entire coding practice on when it doesn't warrant it.
Again, this is one area (among many) that sets VB apart from its more
stripped down .NET sibling languages.
As for the additional behavior of CStr() being well known, I highly
disagree. This whole thread (and countless others) started off with the
OP confused over the difference between CStr() and .ToString.
Considering CStr and its older Str cousin have been around since B.A.S.I.C.
I'd chalk it up to just not understanding what VB as a high-level coding
language is versus the framework its latest incarnation rides on.
--
-C. Moya www.cmoya.com
I'm not mixing up anything. Indicating that I am stupid for recommending
not to use CStr() is what you've both said. But at the same time, you've
both also admitted that CStr() can get you into trouble. So my advice is go
with the code that will satisfy all scenarios and for this you both call me
stupid.
They are your own words Herfried, just scroll down and read them if you've
forgotten.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OE**************@TK2MSFTNGP11.phx.gbl... "Scott M." <s-***@nospam.nospam> schrieb: Try to just understand what I'm saying for a moment...If you rely on
CStr() to do your validation checks, then it will allow all Nothing
values and would not be able to alert YOU the programmer to a validation
error unless you add an if statement of your own that checks for "".
Your example code of what I'd write is inaccurate given that if s Is
Nothing, I wouldn't want and empty string in its place, I'd probably WANT
an exception.
Huh?! You are mixing up cases. CMM and I simply said that generally
recommending not to use 'CStr' at all is plain stupid. If you /want/ an
exception to be thrown, simply do not use 'CStr'!
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Cor,
You are completely missing the point. My point is that writing
CStr(someString) over someObject.ToString is a throwback to the VB 6.0 style
of object BASED programming and not consistent with the object ORIENTED
style of programming.
In this context, yes there is a difference between a method and a language
function. As a teacher, when I have students new to this, the question is
always the same, "How do I know when you should use an object method vs.
using a language function and pass it some type's value?". Type CStr() in
VS.NET and it will turn blue. Blue is for language elements. Yes,
internally this "function" operates as a method, but from a coding *style*
perspective the developer is not using a method, they are using a language
construct.
For consistency sake as well as the fact that many of the old VB 6.0
"functions" don't offer any benefits over object methods, I prefer the OO
way.
As for CStr() in particular, I've said over and over that this is my
PREFERENCE and IMHO it doesn't need to be everyone's choice. Using ToString
on string values along with an Is Nothing check works in every single
situation. CStr() would need an IF Then check of its own to validate its
conversion, so the two approached amount to roughly the same amount of code.
Now, CMM and Herfried have changed their original stance and admitted that
if you need to process Nothing differently than a string, you will have
problems with CStr(). And in *my* travels, handling Nothing differently
than a string value is pretty darn common, which means using ToString makes
perfect sense in every situation I encounter. For advocating this, CMM and
Herfried have decided to get personal and call me stupid. I don't know CMM,
but I wouldn't have expected that from Herfried.
-Scott
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl... Scott,
The VB 6.0 way are not methods, they are functions. The .NET way are
object methods. The VB.NET compiler does NOT optimize the VB 6.0
functions to work BETTER than the natvie .NET object methods.
What you write is true, however we are talking about dotNet her. In dotNet
all methods are Methods even if you call them functions. It does not
matter if they are placed in the System Namespace or placed in whatever
namespace including your own.
In the Visual Basic namespace are many methods which are more optimized in
whatever way than the standard system.Net methods. Some are just wrappers
with backward compatible reasons (but absolute not all).
This optimized can be to make it easier and more descripting writing a
program.
By instance IsDate what is nothing more than a convert in a try block,
however much easier to write or by instance a Find method which is twice
as fast as an IndexOf a full string.
Just my opinion
Cor
I've never admitted CStr can "get you into trouble" and I'd like you to give
one example when it might.
As for "calling you stupid"... I don't think that it was anyone's intention
to level a personal insult. We're simply debating the merit of your claims
about CStr. Though I do think calling CStr "legacy" does sort of demonstate
a bit of ignorance considering it's entirely false.
--
-C. Moya www.cmoya.com
Wow, you are just full of compliments CMM. Read the first 4 letters I wrote
in my OP. If I told you that I always want to treat a Nothing value
differently than a String value, what would you suggest I do?
"CMM" <cm*@nospam.com> wrote in message
news:u6**************@TK2MSFTNGP10.phx.gbl... "Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message Using 'CStr' whenever it /makes sense/ is good practice.
Always has been always will be. If one doesn't like VB's specialized
helper functions and methods, maybe they shouldn't be coding in VB. And,
to call them "legacy" is both ignorant and shortsighted. They are what
make VB "VB."
Chances are at some point people like Scott M will realize what
"encapsulation" means and write their own SafeToString(object) helper
function... not really realizing (or caring) that they had this all along.
--
-C. Moya
www.cmoya.com
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl... Cor,
You are completely missing the point. My point is that writing
CStr(someString) over someObject.ToString is a throwback to the VB 6.0
style of object BASED programming and not consistent with the object
ORIENTED style of programming.
I hope you're teaching your students about encapsulation. Because that's
exactly what CStr is.
Also, the fact that by-design the .NET String object violates the strict
"object ORIENTED" notion that you seem to be harping on. For instance,
s.ToUpper() doesn't exactly perform a true OO operation (in that s isn't
modified). So there goes that.
In this context, yes there is a difference between a method and a language
function. As a teacher, when I have students new to this, the question is
always the same, "How do I know when you should use an object method vs.
using a language function and pass it some type's value?". Type CStr() in
VS.NET and it will turn blue. Blue is for language elements. Yes,
internally this "function" operates as a method, but from a coding *style*
perspective the developer is not using a method, they are using a language
construct.
Also known as a keyword, right? Well, that's what makes VB "VB."
Respectfully, if you don't like the things that make VB "VB," maybe you
shouldn't be using or teaching VB. C# seems much better suited to your
preferences, no?
For consistency sake as well as the fact that many of the old VB 6.0
"functions" don't offer any benefits over object methods, I prefer the OO
way.
They offer many benefits. Maybe it might help if somebody wrapped that all
up as Shared Methods in a "StringUtility" class? Does
StringUtility.CStr(...) make it easier for you to use? Would that make it
more "OO" to you?
As for CStr() in particular, I've said over and over that this is my
PREFERENCE and IMHO it doesn't need to be everyone's choice. Using
ToString on string values along with an Is Nothing check works in every
single situation. CStr() would need an IF Then check of its own to
validate its conversion, so the two approached amount to roughly the same
amount of code.
The latter accomplishes encapsulation. The former (your method) accomplishes
needlessly verbose code.
Now, CMM and Herfried have changed their original stance and admitted that
if you need to process Nothing differently than a string, you will have
problems with CStr().
I admitted nothing that isn't already obvious nor changed my stance. If you
need to treat Nothing differently than EmptyString then it's obvious you
wouldn't use CStr. Instead, it would behoove you to write your own helper
function.... like, SafeGetString(object, valueIfNothing) As String...
instead of littering If Is Nothing conditionals all over your code.
Again encapsulation is a good practice.
And in *my* travels, handling Nothing differently than a string value is
pretty darn common, which means using ToString makes perfect sense in
every situation I encounter.
In *my* travels, you usually want to treat Nothing as EmptyString. The
instance where this isn't true is rare and specialized. Indeed, the VB
language stresses this in that its Equality operators reinforce this notion.
I've alluded to this in another post in this thread... but, possibly VB is
not the language for you.
For advocating this, CMM and Herfried have decided to get personal and
call me stupid. I don't know CMM, but I wouldn't have expected that from
Herfried.
No one called you stupid... as a personal attack. If anything I said
offended you, I apologize.
--
-C. Moya www.cmoya.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Bill L. |
last post by:
We recently noticed that the vb.net CStr function yields different
results than the vb6 version when converting SQL decimal data. If, for
example, the data is defined in SQL as decimal(19,10), the...
|
by: c_shah |
last post by:
Very beginner question..
What's difference between cstr vs .ToString vs Ctype for converting to
String?
|
by: John |
last post by:
Hi
I have a WinForm app with a bound form. When user enters a value in field
rateid I lookup the respective rate amount from a table and assign it to
field rate.I am using the DLookup function...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
