My FIRST Class!! But it doesn't work as expected - please HELP!

[Herfried K. Wagner [MVP]]

I don't think there *is* a C# namespace

Well, there actually is such a namespace, but it contains mainly a wrapper
around the C# compiler.

 

[Zanna]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> ha scritto nel
messaggio

Actually, CInt(<somevalue>) is the same as CType(<somevalue>, Integer)
While the latter requires more typing, this is another case where I
try to get my head out of classic VB and stop using CInt, CLng, etc.
and start using the "new" way.

The right .Net way would be the use of Convert class and DirectCast()
"function".
All others are retrocompatibility for retroprogrammers.

Maybe CType can sobstitute DirectCast() to semplify the cast of value type.

I only look at C# code when I need to port something to VB.Net.
Sometimes I can only find a sample for something in C#.

This is the real goal: .Net code can easily ported to another .Net language
without many effords.
A Vb.Net code can be very difficult to convert.

I consider myself to be a .Net programmer who happens to use the
VB syntax due to having worked with classic VB for many years.

We should consider ourselves as .Net programmers, not as VB.Net or c#
programmers.

 

[Herfried K. Wagner [MVP]]

The right .Net way would be the use of Convert class and DirectCast()
"function".
All others are retrocompatibility for retroprogrammers.

Sorry, but that's plain nonsense. I strongly recommend to read this
article:

Conversion operators in VB
<URL:http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx>

DirectCast revealed

Maybe CType can sobstitute DirectCast() to semplify the cast of value
type.

?!?

'DirectCast' cannot be used for value types at all. 'DirectCast' is a cast
operator, not a conversion operator ('CType' is actually both, cast and
conversion operator, depending on where it is used).

This is the real goal: .Net code can easily ported to another .Net
language
without many effords.
A Vb.Net code can be very difficult to convert.

No, that's definitely not the goal of .NET. The goal of .NET is
interoperability between programming languages, not easy converting of code
between programming languages. If the latter was the goal, everybody would
use IL assembler.

 

[Joergen Bech]

The right .Net way would be the use of Convert class and DirectCast()
"function".
All others are retrocompatibility for retroprogrammers.

Maybe CType can sobstitute DirectCast() to semplify the cast of value type.

I'm only mentioning it because I checked it a few days ago:

CInt(<somevalue>)

and

CType(<somevalue>, Integer)

will compile to the same thing (the latter).

But when I look up CInt in the documentation I see this remark:

"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."

Hm ... Interesting. In that case, I stand corrected (not about
Microsoft.VisualBasic, but CInt, CLng, etc).

But if I write
---snip---
Dim d As Double = 5.0#

Dim b As Byte = CByte(d)
Dim sh As Short = CShort(d)
Dim i As Integer = CInt(d)
Dim l As Long = CLng(d)
Dim str As String = CStr(d)
Dim bool As Boolean = CBool(d)

Dim bnet As Byte = CType(d, Byte)
Dim shnet As Short = CType(d, Short)
Dim inet As Integer = CType(d, Integer)
Dim lnet As Long = CType(d, Long)
Dim strnet As String = CType(d, String)
Dim boolnet As Boolean = CType(d, Boolean)
---snip---

and look at the compiled code in .Net Reflector, I get

---snip---
Dim num3 As Double = 5

Dim num1 As Byte = CType(Math.Round(num3), Byte)
Dim num8 As Short = CType(Math.Round(num3), Short)
Dim num4 As Integer = CType(Math.Round(num3), Integer)
Dim num6 As Long = CType(Math.Round(num3), Long)
Dim text1 As String = Conversions.ToString(num3)
Dim flag1 As Boolean = (num3 <> 0)

Dim num2 As Byte = CType(Math.Round(num3), Byte)
Dim num9 As Short = CType(Math.Round(num3), Short)
Dim num5 As Integer = CType(Math.Round(num3), Integer)
Dim num7 As Long = CType(Math.Round(num3), Long)
Dim text2 As String = Conversions.ToString(num3)
Dim flag2 As Boolean = (num3 <> 0)
---snip---

Sure look equivalent to me.

I agree that there might be differences in some of the conversion
functions (like boolean to integer, which is specifically mentioned),
but I am not sure I agree with the Microsoft recommendation in
general. Sure is important to be aware of the differences though.
CInt(<value>) is not the same as CType(Int(<value>+0.5), Integer):
http://www.uop.edu/cop/psychology/Statistics/Rounding.html

I guess I'll have to start saying "common" .Net instead of "proper"
..Net. My animosity towards Microsoft.VisualBasic started the day
I needed to translate "Dim dt As Date = DateSerial(y, m, d)" to C#.

Eventually I found that I could write "Dim dt As New Date(y, m, d)"
which was much more straightforward to convert. Had not thought
about looking at the overloads for the constructor. I was looking
for an equivalent function in C#.

But DateSerial and the Date(y, m, d) constructor are not equivalent.

In the VB6 days I would obtain the last day of the month by writing
DateSerial(currentyear, currentmonth + 1, 0), e.g. (2005,13,0) became
(2005,12,31) which was what I wanted. Kind of a dirty way of doing
it. DateSerial can still be abused in this way in .Net, but
Date(2005, 13, 0) will throw an exception. Instead, the "proper"
(sorry, "common") way of obtaining the required result would be
"Dim dt As New Date(2005, 12, Date.DaysInMonth(2005, 12))".

Trouble is: Suppose I had written a function using DateSerial and
abused that function as described above (but perhaps not as
explicitly). Then comes a C# programmer and asks for a copy of
the function so he can translate it to C#. Not being aware of the
subtle differences, he translates DateSerial(y,m,d) to Date(y,m,d).
Eventually the function is called with a set of parameters that might
have worked fine in the VB version but fails in the C# one.

What were we talking about anyway? Oh yeah, rolling a dice.

/JB

 

[Herfried K. Wagner [MVP]]

I guess I'll have to start saying "common" .Net instead of "proper"
.Net. My animosity towards Microsoft.VisualBasic started the day
I needed to translate "Dim dt As Date = DateSerial(y, m, d)" to C#.

You could have added a reference to the managed library
"Microsoft.VisualBasic.dll" in the C# project ;-).

 

[Joergen Bech]

You could have added a reference to the managed library
"Microsoft.VisualBasic.dll" in the C# project ;-).

Don't even go there

Well, the new year is less than an hour away, so I am not going
to touch a computer for the rest of 2005.

Happy new year, all!

/JB

 

[m.posseth]

Let me start by wishing you all a verry happy and healthy new year , hope
you did not hurt your fingers when using the fireworks last night


Well if i may throw some gassoline on this firy thread in the new year ;-)

This is for me a reasson to walk through the code of my current project and
see if i can add a few of these declarations here and there

I see this as verry big advantages for VB , as probably someone who
decompiles my code and has a C# only background will encounter these
problems to ( i am already obfuscating my code but i also follow the tips
from Dan Appleman to throw in some nice constructs in code so people
mightlosse interest to spend a lot of time getting it working in the event
they do succeed in reconstructing )


About the C# namespace :

well it does exist however it is almost empty ,,,,, maybe i should
have better said C# VS VB syntax i see nowadays, even some of my
collegues fixating on the framework classes when they program in VB with
VB it is now hard to see the difference between "normall" syntax , and that
was is wrapped through the microsoft.visualbasic namespace . However i see
this as a advantage of a evolved versus a new language a eveolved language
has some shortcuts to do the same ,,, that is the main reasson in my opinion
that it is faster to program with, well if i would abandon this big
advantage i could just as easily program in C# and so stretch all the
deadlines to a farrer point in the future .

let me give you an example .... where started this discussion ??? we were
talking about a dice

see were i wrote working code ,,,, and see below how long it took before it
was doing what he wanted with the alternative code
well that is now the power of the VB namespace ,,,,,, if MS did not
want us to use the VB namespace they should have removed it however if the
examples of MS contain code with the VB namespace
i do not feel that this is the general idea .


regards

Michel Posseth [MCP]

 

[Herfried K. Wagner [MVP]]

Joergen,

Well, the new year is less than an hour away, so I am not going
to touch a computer for the rest of 2005.

Happy new year, all!

Although I am a bit late now, I wish everybody here health, luck, and
success for 2006! Hopefully 2006 will be a more peaceful year.

BTW ;-):

More C# Elvis impersonators
<URL:http://msmvps.com/blogs/bill/archive/2005/12/09/78502.aspx>

 

[Joergen Bech]

Joergen,



Although I am a bit late now, I wish everybody here health, luck, and
success for 2006! Hopefully 2006 will be a more peaceful year.

BTW ;-):

More C# Elvis impersonators
<URL:http://msmvps.com/blogs/bill/archive/2005/12/09/78502.aspx>

I hope you are not suggesting I am one of those? I am not anti-VB
or a C# wannabe programmer or anything like that.

Just anti-one-little-namespace-included-by-default.

Here is some reading material. This discussion is not new:
http://www.knowdotnet.com/articles/forgetmicrosoftvisualbasicnamespace.html
http://addressof.com/blog/archive/2003/10/31/242.aspx
http://weblogs.asp.net/jcogley/archive/2005/05/23/408540.aspx

but the very best (and most balanced) article I have found must be
this one (straight from the horse's mouth):
http://www.panopticoncentral.net/archive/2004/05/31/1100.aspx

which among other things links to this (long) article:
http://tinyurl.com/4oumj

I realize that some of those posts are pro-Microsoft.VisualBasic.

Again: I try to stay away from Microsoft.VisualBasic because

1) it makes it easier to port code to/from C#

2) there are subtle differences between the functions in MVB and the
system namespaces and I don't want to have to remember those
because (if) I am being inconsistent in my usage of those
throughout my application.

Hope that makes my position clear. Other people might have
other priorities and a different view of M.VB. I accept that.

/Joergen Bech

 

[Herfried K. Wagner [MVP]]

I hope you are not suggesting I am one of those? I am not anti-VB
or a C# wannabe programmer or anything like that.

Sorry, no, that was definitely not my intention.

Just anti-one-little-namespace-included-by-default.

Here is some reading material. This discussion is not new:
http://www.knowdotnet.com/articles/forgetmicrosoftvisualbasicnamespace.html
http://addressof.com/blog/archive/2003/10/31/242.aspx
http://weblogs.asp.net/jcogley/archive/2005/05/23/408540.aspx

Well, I believe it definitely makes sense to know the low-level constructs
behind the functions which are provided by "Microsoft.VisualBasic.dll", but
I don't think that it's a good idea to use them in VB.NET code instead of
VB.NET's functions only because equivalent functionality can be archieved
using the pure .NET Framework.

There are many reasons for using VB.NET's function instead of those which
are part of the .NET Framework. In the first place, people who have a
Classic VB or BASIC background can easily adopt VB.NET and migrate source
code. Sure, there are huge differences between Classic VB and VB.NET, but
the continued existence of VB's functions in VB.NET is a big plus. Compare
this with the legacy syntax of C#, which has mainly been continued to
attract former C++ and Java developers.

However, "Microsoft.VisualBasic.dll" contains functionality which is not
available in the .NET Framework at all, such as 'AppActivate', and in .NET
2.0 parts of the 'My' framework such as Windows' own dialogs for visualizing
file system operations.

but the very best (and most balanced) article I have found must be
this one (straight from the horse's mouth):
http://www.panopticoncentral.net/archive/2004/05/31/1100.aspx


Again: I try to stay away from Microsoft.VisualBasic because

1) it makes it easier to port code to/from C#

If this is a requirement, that's a good choice.

2) there are subtle differences between the functions in MVB and the
system namespaces and I don't want to have to remember those
because (if) I am being inconsistent in my usage of those
throughout my application.

I speak both and I rarely mix them up .

 

[Cor Ligthert [MVP]]

Joergen,

It is a pity if you try to use from a language only that which is the same
as all other languages ever used. You miss a lot and make it yourself very
difficult. As well do you make it worser to maintain, because you don't use
the tools that are common for the problem.

I assume that you do the same when you eat and therefore eat almost every
day the same.

Happy new year by the way.



Cor

 

[Cor Ligthert [MVP]]

Herfried,

If this is a requirement, that's a good choice.

Why than just write it direct in C# and don't turn yourself in strange
behaviour and make it with that difficult for those who are reviewing your
program.

Read for the rest my comment to Joergen.

(Although I have the same idea as Armin wrote in this newsgroup some days
ago about a lot of improvements in VB 2005)

Happy newyear of course.



Cor

 

[Joergen Bech]

Joergen,

It is a pity if you try to use from a language only that which is the same
as all other languages ever used. You miss a lot and make it yourself very
difficult. As well do you make it worser to maintain, because you don't use
the tools that are common for the problem.

As I have written elsewhere, given a choice between similar
functionality in the System namespace and the M.VB one
(as in the same amount of code to write), I'll chose the System
functions.

The Rnd vs Random discussion was a good example of this.

If I needed something like AppActivate, of course I would not
rewrite that one from scratch, but use the one in M.VB. I could
write it myself, but my (work) time is as valuable as anyone else's
and I won't reinvent the wheel. Note: AppActivate is just a
bunch of calls to native Win32 API functions. There is nothing
blocking me from writing such a function myself, but it's already
there, so I won't.

I am not missing out on anything. I study the framework and use
whatever I need from both camps. I also use the My.* namespace
after I moved to VB2005.

It seems to me that *you* are the one stuck in one camp and
missing out on the good bits from the other.

But for my part, this thread has gone on long enough, so I'll
stop here and get back to help out with new questions (if I'm
able), time permitting. Regular work days start again tomorrow.

I assume that you do the same when you eat and therefore eat almost every
day the same.

No comments.

Peace!

/JB

 

[Herfried K. Wagner [MVP]]

Why than just write it direct in C# and don't turn yourself in strange
behaviour and make it with that difficult for those who are reviewing your
program.

Yep, I had the same thoughts.

 

[Zanna]

"Herfried K. Wagner [MVP]" <[email protected]> ha scritto nel
messaggio

Sorry, but that's plain nonsense. I strongly recommend to read this
article:

Conversion operators in VB
<URL:http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx>

DirectCast revealed
<URL:http://www.panopticoncentral.net/archive/2003/07/10/149.aspx>

Already read one year ago.
And they are not really related with the point.
Microsoft did some twisted jump to leave to lazy VB6 programmers the luxury
to write Randomize instead of new Random.
This is not the .Net way.
Stop.

'DirectCast' cannot be used for value types at all.

That's way I talked about CType().

'DirectCast' is a cast
operator, not a conversion operator ('CType' is actually both, cast and
conversion operator, depending on where it is used).

A 'cast' should be possible with value type, ie Int32 to Int16 is a cast.
And if you're talking about .Net passing from a superclass to a class is not
properly a cast, but an 'unboxing'.

But this is just philosofy.
What is sure is that CInt is a language specific function (NOT a language
specific keyword! That would be legal, but a *function* that cannot be used
by other .Net languages).

No, that's definitely not the goal of .NET. The goal of .NET is
interoperability between programming languages, not easy converting of code
between programming languages. If the latter was the goal, everybody would
use IL assembler.

You're right.
But when you sow the Microsoft launch of .Net, they said "Look at the code!
Is just a question of syntax".
That's true, if you write .Net code. Not if you write VB code.
And no matther about the thousands of VB people all around that ask for
translating to or from c# some code, simply because they don't know .Net but
just VB (not even VB.Net, only VB).
And those that says that VB.net is sloooow... SURE! You are working on the
extra Microsoft.VisualBasic layer...

 

[Herfried K. Wagner [MVP]]

Already read one year ago.
And they are not really related with the point.
Microsoft did some twisted jump to leave to lazy VB6 programmers the
luxury
to write Randomize instead of new Random.
This is not the .Net way.
Stop.

As 'Randomize' is a managed function, it's perfectly legitimate to use it,
especially if existing VB6 code is being migrated to VB.NET. Otherwise
you'd have to refuse using third-party libraries at all because they are not
part of the FCL.

That's way I talked about CType().



A 'cast' should be possible with value type, ie Int32 to Int16 is a cast.
And if you're talking about .Net passing from a superclass to a class is
not
properly a cast, but an 'unboxing'.

Well, I was talking in VB-speech .

What is sure is that CInt is a language specific function (NOT a language
specific keyword! That would be legal, but a *function* that cannot be
used
by other .Net languages).

'CInt' et al. are compiled inline. The compiler knows 'CInt', etc. as it
knows 'Asc', 'AscW', 'Chr', and 'ChrW' and replaces calls to these functions
to constant literals if a constant value is passed to them, i.e. 'ChrW(12)'.
It's true that 'CInt' et al. cannot be used by simply adding a reference to
"Microsoft.VisualBasic.dll" and importing some namespaces or modules. They
are mostly a language feature. Note that in VB6 'CInt' has been a library
function which had special treatment by the compiler.

I believe it's not a good idea to use only language features of programming
language X which are present in programming language Y too. Take 'using'
blocks, for example. This block statement was not available in VB
2002/2003, but it has been available in VC# 2002/2003. Do you think that a
single C# developer refused to use 'using' only because VB.NET didn't
support it and its use would have made conversion of source code a more
complicated job? I strongly doubt that this was the case. Or would you
refuse using VB.NET's handy declarative event handling syntax only because
C# doesn't support a similar syntax? Where would you draw the border?

You're right.
But when you sow the Microsoft launch of .Net, they said "Look at the
code!
Is just a question of syntax".
That's true, if you write .Net code. Not if you write VB code.

In both cases the applications are based on the .NET Framework. Using the
VB.NET runtime library only adds another view to functionality of the .NET
Framework, but it doesn't compromise language interoperability or
compatibility. Thus it's really just a question of syntax (and
productivity, of course ). Being able to convert source code between
programming languages was not one of the main goals of .NET. Moreover it
doesn't matter in which language a certain component has been written at
all. It's only important that it's compiled to MSIL.

And no matther about the thousands of VB people all around that ask for
translating to or from c# some code, simply because they don't know .Net
but
just VB (not even VB.Net, only VB).

The same applies to C# developers who refuse to get familiar with
"Microsoft.VisualBasic.dll" and its functions! "Microsoft.VisualBasic.dll"
is a managed library as any other managed library, except that it has been
specifically designed for the use with VB.NET.

And those that says that VB.net is sloooow... SURE! You are working on the
extra Microsoft.VisualBasic layer...

Sorry, but that's again nonsense.

 

[Cor Ligthert [MVP]]

Zanna,

Already read one year ago.
And they are not really related with the point.
Microsoft did some twisted jump to leave to lazy VB6 programmers the
luxury
to write Randomize instead of new Random.
This is not the .Net way.
Stop.

No Randomize did exist earlier in true Microsoft languages, you mean
probably Microsoft did some twisted jumps to lazy C# programmers to Write
Random instead of Randomize.

What is not true by the way, it is just that VB has some more possiblilities
as by instance in English Flesh and Meat. In most languages there is only
one word for it. However because of historic reason English has two words
for that. ("Flesh" is derived from the Germanic languages, "Meat" is derived
from the Italic languages).

VB.Net is more a language like English, while C# is more as a synthytic
language like German.

No a little bit out of sense. A value cannot be casted (it is in most cases
a bit pattern). In C# there is not DirectCast there does it directly means a
convert because you don't have a directcast command, only a CType. (However
convert is by C users, seldom used and the word cast is used. The same as
the from origin French nobles did only use "meat" in old England because
that was what they were eating.)

That's way I talked about CType().



A 'cast' should be possible with value type, ie Int32 to Int16 is a cast.

No a conversion

What is sure is that CInt is a language specific function (NOT a language
specific keyword! That would be legal, but a *function* that cannot be
used
by other .Net languages).

Method as any other method.

code between programming languages.

No you can use both languages in one project even in versions older than
2005, although you have than one of those to set in a class libary project.
With one exception a C# project is not always CLR compliant and can give
problems (VBNet can be it as well in a rare situation not).

And those that says that VB.net is sloooow... SURE! You are working on the
extra Microsoft.VisualBasic layer...

It is probably more that there is a seperated Microsoft.VisualBasic
namespace to give the first users of C# not the idea that VisualBasic could
be used as well with the same results as with C#.

At the moment all *good* ,Net developpers know that there is in fact no
difference in C# and VBNet beside the way the source is written.

Cor