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

[Cap'n Ahab]

I have used VB3 - VB6, so learning all this OO stuff is reasonably new
to me (although I looked at Java a few years ago). Anyway, I thought I
would write a small class to begin with, with a property and 2 methods,
along with a constructor (where you use New(), I think, yes?).

So, I decided to create a class that represents a die, which can be
rolled - using a Roll() method - and which has a property to find out
the value on the face of the die after a roll - GetValue(). I then
added a Display() method that prints out the value of the die to the
console window.

Now, my thinking was that in writing the New() constructor I should
Roll() the die to get a 1st random number value. Indeed this worked
fine. However, when I instantiated (or do I say consumed?) the class
twice - the dice always show the same value!!!

I cannot see where this is going wrong - could someone please point out
the error of my ways?

The code is quite small - and here is the class (in Class1.vb)...

Public Class Die

Private _value As Int16
Dim _generator As New Random

Public Sub New()
Me.Roll()
End Sub

Public ReadOnly Property GetValue() As Int16
Get
Return _value
End Get
End Property

Public Sub Roll()
_value = _generator.Next(1, 7)
End Sub

Public Sub Display()
Console.WriteLine(Me.GetValue)
End Sub

End Class

The Module1.vb file holds this code...

Module Module1

Sub Main()

Dim One As New Die
Dim Two As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

End Sub

End Module

When run, the values are listed like this...

1
1

2
2

6
6

5
5

3
3

Why do they duplicate if they are supposed to be random - there is
either something in the Dim One/Two as New Die that I don't appreciate
or there is something in the Constructor New() that I don't understand.

Thanks in advance for any help.

[m.posseth]

well i would do it like this
Public Class Die

Private _value As Int16

Public Sub New()

Randomize()

Me.Roll()

End Sub

Public ReadOnly Property GetValue() As Int16

Get

Return _value

End Get

End Property

Public Sub Roll()

' Initialize the random-number generator.

Randomize()

' Generate random value between 1 and 6.

_value = CInt(Int((6 * Rnd()) + 1))

End Sub

Public Sub Display()

Console.WriteLine(Me.GetValue)

End Sub

End Class

Module Module1

Sub Main()

Dim One As New Die

Dim Two As New Die

Do

One.Display()

One.Roll()

Two.Display()

Two.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

End Sub

End Module

wich seems to work as expected

regards

Michel Posseth [MCP]


"Cap'n Ahab" <sp***********@lycos.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

I have used VB3 - VB6, so learning all this OO stuff is reasonably new
to me (although I looked at Java a few years ago). Anyway, I thought I
would write a small class to begin with, with a property and 2 methods,
along with a constructor (where you use New(), I think, yes?).

So, I decided to create a class that represents a die, which can be
rolled - using a Roll() method - and which has a property to find out
the value on the face of the die after a roll - GetValue(). I then
added a Display() method that prints out the value of the die to the
console window.

Now, my thinking was that in writing the New() constructor I should
Roll() the die to get a 1st random number value. Indeed this worked
fine. However, when I instantiated (or do I say consumed?) the class
twice - the dice always show the same value!!!

I cannot see where this is going wrong - could someone please point out
the error of my ways?

The code is quite small - and here is the class (in Class1.vb)...

Public Class Die

Private _value As Int16
Dim _generator As New Random

Public Sub New()
Me.Roll()
End Sub

Public ReadOnly Property GetValue() As Int16
Get
Return _value
End Get
End Property

Public Sub Roll()
_value = _generator.Next(1, 7)
End Sub

Public Sub Display()
Console.WriteLine(Me.GetValue)
End Sub

End Class

The Module1.vb file holds this code...

Module Module1

Sub Main()

Dim One As New Die
Dim Two As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

End Sub

End Module

When run, the values are listed like this...

1
1

2
2

6
6

5
5

3
3

Why do they duplicate if they are supposed to be random - there is
either something in the Dim One/Two as New Die that I don't appreciate
or there is something in the Constructor New() that I don't understand.

Thanks in advance for any help.

[Armin Zingler]

"Cap'n Ahab" <sp***********@lycos.com> schrieb

Dim _generator As New Random

Random numbers are not really Random. To get a "more random" number, use

Dim _generator As New Random(Environment.TickCount)
Armin

[m.posseth]

> Random numbers are not really Random. To get a "more random" number, use

Dim _generator As New Random(Environment.TickCount)

Armin ,,,,, it does this automaticly if you do not provide an init number

http://msdn.microsoft.com/library/de...mrandomize.asp
although when i rethink this situation

this would also solve his problem , cuase it will now internally be the same
as calling randomize multiple times

Public Class Die

Private _value As Int16

Public Sub New()
Me.Roll()
End Sub

Public ReadOnly Property GetValue() As Int16
Get
Return _value
End Get
End Property

Public Sub Roll()
Dim _generator As New Random
_value = _generator.Next(1, 7)
End Sub

Public Sub Display()
Console.WriteLine(Me.GetValue)
End Sub

End Class
regards

Michel Posseth [MCP]
"Armin Zingler" <az*******@freenet.de> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... "Cap'n Ahab" <sp***********@lycos.com> schrieb

Dim _generator As New Random

Random numbers are not really Random. To get a "more random" number, use

Dim _generator As New Random(Environment.TickCount)
Armin

[Cor Ligthert [MVP]]

Michel,

I certainly would not do it as you showed, because that an int16 consumes
probably more than an Integer, which last is the default for at least all
32bits system and therefore perfectly fits in the register of the computer
and needs no extra accessing to use that.

For the rest I did not look, trusting on it that yours and Armins answers
are the right ones and there would not be much to add for me.

:-)

Cor

[m.posseth]

well it was altered TS code ,,,, i was in doubt regarding the 16 bit integer
value

but i have never found a true answer for it as the thoughts seem to change
day by day regarding this issue

one says the IA-32 architecture processes 32-bit integers just as
fast as 16-bit or 8-bit integers and that the smallest possible size will
preserve memory

others tell you to always use the 32 bit size when possible cause 16 bit
vars preserve memory but requires more CPU cycles

and again others come with the fact that 32 bit would always be better as it
is the architecture size

etc etc etc etc

i assumed the TS had it`s reasson ( or accepts one of the above for true )
i for myself would have used the integer datatype

regards

Michel Posseth [MCP]
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:uE*************@TK2MSFTNGP12.phx.gbl...

Michel,

I certainly would not do it as you showed, because that an int16 consumes
probably more than an Integer, which last is the default for at least all
32bits system and therefore perfectly fits in the register of the computer
and needs no extra accessing to use that.

For the rest I did not look, trusting on it that yours and Armins answers
are the right ones and there would not be much to add for me.

:-)

Cor

[Joergen Bech]

Some comments to the other posts:

1. Yes, I prefer Integer (Int32) too. As I am using Option Strict in
nearly all the modules I write, I find that I need to perform fewer
explicit type conversions when interacting with the rest of the
framework :)

2. Randomize is ugly. I am not sure I would ever call it except once
and then store the result in a global variable.

---snip---
Public Shared Sub Randomize()
Dim data1 As ProjectData = ProjectData.GetProjectData
Dim single1 As Single = VBMath.GetTimer
Dim num2 As Integer = data1.m_rndSeed
Dim num1 As Integer =
BitConverter.ToInt32(BitConverter.GetBytes(single1 ), 0)
num1 = (((num1 And 65535) Xor (num1 >> 16)) << 8)
num2 = ((num2 And -16776961) Or num1)
data1.m_rndSeed = num2
End Sub

Private Shared Function GetTimer() As Single
Dim time1 As DateTime = DateTime.Now
Return CType((((((60 * time1.Hour) + time1.Minute) * 60) +
time1.Second) + (CType(time1.Millisecond, Double) / 1000)), Single)
End Function
---snip---

3. Finally: Your first instincts were right. With one small change,
your class will perform as required:

---snip---
Public Class Die
Private _value As Int32
Private Shared _generator As New Random

Public Sub New()
Me.Roll()
End Sub

Public ReadOnly Property Value() As Int32
Get
Return _value
End Get
End Property

Public Sub Roll()
_value = _generator.Next(1, 7)
End Sub

End Class

Private Sub TestDie()
Dim d1 As New Die
Dim d2 As New Die

Debug.WriteLine(d1.Value())
d1.Roll()
Debug.WriteLine(d2.Value())
d2.Roll()

Debug.WriteLine(d1.Value())
d1.Roll()
Debug.WriteLine(d2.Value())
d2.Roll()

End Sub

---snip---

It doesn't get any simpler than this. Why complicate things?

The main difference here is the addition of the "Shared" keyword
to the _generator member variable.

This means that the generator is only instantiated once and shared
between any instances of the Die class you might create. No need
to use the Randomize command or anything.

If you are writing a program that rolls a dice (once) when the user
clicks a button, maybe it's ok to use Randomize to seed a new
Random object, but if you are doing multiple rolls within the same
split-second, or need to use the Random object to generate a large
amount of random data for testing, statistics, noise plots, whatever,
stay away from Randomize. Try running the Sub below. Remove one
or both of the Randomize statements.

---snip---
Private Sub NotSoRandom()
For i As Integer = 1 To 200
Randomize() '<<< makes no difference
Dim r As New Random
Randomize() '<<< makes no difference
Debug.WriteLine(r.Next(1, 7))
Next
End Sub
---snip---

If you disagree with my views in these specific contexts, please post
a follow-up.

Regards,

Joergen Bech

On 31 Dec 2005 03:55:53 -0800, "Cap'n Ahab" <sp***********@lycos.com>
wrote:

I have used VB3 - VB6, so learning all this OO stuff is reasonably new
to me (although I looked at Java a few years ago). Anyway, I thought I
would write a small class to begin with, with a property and 2 methods,
along with a constructor (where you use New(), I think, yes?).

So, I decided to create a class that represents a die, which can be
rolled - using a Roll() method - and which has a property to find out
the value on the face of the die after a roll - GetValue(). I then
added a Display() method that prints out the value of the die to the
console window.

Now, my thinking was that in writing the New() constructor I should
Roll() the die to get a 1st random number value. Indeed this worked
fine. However, when I instantiated (or do I say consumed?) the class
twice - the dice always show the same value!!!

I cannot see where this is going wrong - could someone please point out
the error of my ways?

The code is quite small - and here is the class (in Class1.vb)...

Public Class Die

Private _value As Int16
Dim _generator As New Random

Public Sub New()
Me.Roll()
End Sub

Public ReadOnly Property GetValue() As Int16
Get
Return _value
End Get
End Property

Public Sub Roll()
_value = _generator.Next(1, 7)
End Sub

Public Sub Display()
Console.WriteLine(Me.GetValue)
End Sub

End Class

The Module1.vb file holds this code...

Module Module1

Sub Main()

Dim One As New Die
Dim Two As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

End Sub

End Module

When run, the values are listed like this...

1
1

2
2

6
6

5
5

3
3

Why do they duplicate if they are supposed to be random - there is
either something in the Dim One/Two as New Die that I don't appreciate
or there is something in the Constructor New() that I don't understand.

Thanks in advance for any help.

[Joergen Bech]

Well, I cannot say how much difference it makes for a single
variable. I just use Integer as a convenience.

But for arrays, I can positively say that it makes a difference:

---snip---
Private Sub MemoryTest()
Dim mw As New MemoryWatch
mw.Start()

Dim d1(10000) As Byte
mw.CheckPoint()
Debug.WriteLine("10000 bytes: " & mw.MemoryDelta)

Dim d2(10000) As Short
mw.CheckPoint()
Debug.WriteLine("10000 words: " & mw.MemoryDelta)

Dim d4(10000) As Integer
mw.CheckPoint()
Debug.WriteLine("10000 integers: " & mw.MemoryDelta)

Dim d8(10000) As Long
mw.CheckPoint()
Debug.WriteLine("10000 longs: " & mw.MemoryDelta)

End Sub
---snip---

results in something like

---snip---
10000 bytes: 10028
10000 words: 20004
10000 integers: 40016
10000 longs: 80020
---snip---

In other words, 10000 16-bit values are not treated as 10000
32-bit values in terms of storage. Does this mean an extra shift
operation for the cpu when reading every other value in the 16-bit
array? Perhaps. Does it matter? Probably not much, considering
all the other work the clr has to do in order to address and read
the value.

So I would say: For simple member and throw-away variables (those that
will never leave the cpu cache anyway), use what is convenient, but
when working with large amounts of data or performance-critical loops,
etc, think about what you are doing. Test for time and resource usage.

In most cases, make sure the program is readable, then optimize if
necessary (though there are exceptions to this rule).

Regards,

Joergen Bech

On Sat, 31 Dec 2005 14:25:40 +0100, "m.posseth"
<mi*****@nohausystems.nl> wrote:

well it was altered TS code ,,,, i was in doubt regarding the 16 bit integer
value

but i have never found a true answer for it as the thoughts seem to change
day by day regarding this issue

one says the IA-32 architecture processes 32-bit integers just as
fast as 16-bit or 8-bit integers and that the smallest possible size will
preserve memory

others tell you to always use the 32 bit size when possible cause 16 bit
vars preserve memory but requires more CPU cycles

and again others come with the fact that 32 bit would always be better as it
is the architecture size

etc etc etc etc

i assumed the TS had it`s reasson ( or accepts one of the above for true )
i for myself would have used the integer datatype

regards

Michel Posseth [MCP]
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:uE*************@TK2MSFTNGP12.phx.gbl...

Michel,

I certainly would not do it as you showed, because that an int16 consumes
probably more than an Integer, which last is the default for at least all
32bits system and therefore perfectly fits in the register of the computer
and needs no extra accessing to use that.

For the rest I did not look, trusting on it that yours and Armins answers
are the right ones and there would not be much to add for me.

:-)

Cor

[Cap'n Ahab]

Thanks for the responses, guys. The one that seems to make it work as
I originally planned is the change below...

Private _generator As New Random ---> Private Shared
_generator As New Random

However, this runs contrary to what I would expect! 180 degrees
wrong!!!!
I would have thought that the code in the constructor would create a
random number between 1 - 6 (which it does) but in addition it would be
a different value for every new object that is instantiated by the die
class as part of the Dim myObject as New Die command (but it doesn't).
Why do they have the same value? I thought if you wanted a value to be
common throughout instantiation of a class THEN you used the SHARED
command - not the other way round as happens here. Using shared makes
instantiations of the Die Class begin with, well, a different number
from each other.

I think this is more of my lack of understanding of how the Random
command works and not my appreciation of OO programming. Do you agree?

[Cap'n Ahab]

I have also noticed that instead of using Shared, if I rewrite the
New() constructor by adding the Randomize() command as below...

Public Sub New()
Randomize()
Me.Roll()
End Sub

and then consume 3 objects based on the Die Class,

Then use the same loop..

Dim One As New Die
Dim Two As New Die
Dim Three As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()
Three.Display()
Three.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

That the results are not random between the die at all!! The numbers
either are 3 of a the same number OR a pair of numbers an other other
number - no exceptions. How very odd!

Now I AM confused, lol.

[m.posseth]

The code i showed i have also run ,,, and it worked as dices in my situation

also nice thingy is that alter after the comments i searched the msdn site
and saw that MS does it the same way

Dim MyValue As Integer
Randomize ' Initialize random-number generator.
MyValue = CInt(Int((6 * Rnd()) + 1)) ' Generate random value between 1 and
6.above is MS code

regards

Michel Posseth [MCP]
"Cap'n Ahab" <sp***********@lycos.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

I have also noticed that instead of using Shared, if I rewrite the
New() constructor by adding the Randomize() command as below...

Public Sub New()
Randomize()
Me.Roll()
End Sub

and then consume 3 objects based on the Die Class,

Then use the same loop..

Dim One As New Die
Dim Two As New Die
Dim Three As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()
Three.Display()
Three.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

That the results are not random between the die at all!! The numbers
either are 3 of a the same number OR a pair of numbers an other other
number - no exceptions. How very odd!

Now I AM confused, lol.

[Joergen Bech]

Do you have a direct link to that sample?

To me, that looks like VB6 code. Not the way it would be
written in VB.Net.

/JB

On Sat, 31 Dec 2005 15:33:08 +0100, "m.posseth"
<mi*****@nohausystems.nl> wrote:

The code i showed i have also run ,,, and it worked as dices in my situation

also nice thingy is that alter after the comments i searched the msdn site
and saw that MS does it the same way

Dim MyValue As Integer
Randomize ' Initialize random-number generator.
MyValue = CInt(Int((6 * Rnd()) + 1)) ' Generate random value between 1 and
6.above is MS code

regards

Michel Posseth [MCP]
"Cap'n Ahab" <sp***********@lycos.com> wrote in message
news:11**********************@o13g2000cwo.googleg roups.com...

I have also noticed that instead of using Shared, if I rewrite the
New() constructor by adding the Randomize() command as below...

Public Sub New()
Randomize()
Me.Roll()
End Sub

and then consume 3 objects based on the Die Class,

Then use the same loop..

Dim One As New Die
Dim Two As New Die
Dim Three As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()
Three.Display()
Three.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

That the results are not random between the die at all!! The numbers
either are 3 of a the same number OR a pair of numbers an other other
number - no exceptions. How very odd!

Now I AM confused, lol.

[Joergen Bech]

That is why I included the Randomize source from .Net Reflector.

To show you that Randomize just uses the current time and creates
a value by shuffling the bits around.

When you instantiate multiple Die objects within the same fraction
of a second, they will get the same seed value.

Which is why you are getting two or three identical start values
in your example below.

Which is why you do not want to use Randomize.

/Joergen Bech

On 31 Dec 2005 06:23:16 -0800, "Cap'n Ahab" <sp***********@lycos.com>
wrote:

I have also noticed that instead of using Shared, if I rewrite the
New() constructor by adding the Randomize() command as below...

Public Sub New()
Randomize()
Me.Roll()
End Sub

and then consume 3 objects based on the Die Class,

Then use the same loop..

Dim One As New Die
Dim Two As New Die
Dim Three As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()
Three.Display()
Three.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

That the results are not random between the die at all!! The numbers
either are 3 of a the same number OR a pair of numbers an other other
number - no exceptions. How very odd!

Now I AM confused, lol.

[m.posseth]

nope this is VB.Net code

here it is

http://msdn.microsoft.com/library/de...mrandomize.asp

Michel Posseth [MCP]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:gi********************************@4ax.com...

Do you have a direct link to that sample?

To me, that looks like VB6 code. Not the way it would be
written in VB.Net.

/JB

On Sat, 31 Dec 2005 15:33:08 +0100, "m.posseth"
<mi*****@nohausystems.nl> wrote:

The code i showed i have also run ,,, and it worked as dices in my
situation

also nice thingy is that alter after the comments i searched the msdn site
and saw that MS does it the same way

Dim MyValue As Integer
Randomize ' Initialize random-number generator.
MyValue = CInt(Int((6 * Rnd()) + 1)) ' Generate random value between 1 and
6.above is MS code

regards

Michel Posseth [MCP]
"Cap'n Ahab" <sp***********@lycos.com> wrote in message
news:11**********************@o13g2000cwo.google groups.com...

I have also noticed that instead of using Shared, if I rewrite the
New() constructor by adding the Randomize() command as below...

Public Sub New()
Randomize()
Me.Roll()
End Sub

and then consume 3 objects based on the Die Class,

Then use the same loop..

Dim One As New Die
Dim Two As New Die
Dim Three As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()
Three.Display()
Three.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

That the results are not random between the die at all!! The numbers
either are 3 of a the same number OR a pair of numbers an other other
number - no exceptions. How very odd!

Now I AM confused, lol.

[Joergen Bech]

The Random object is shared and only instantiated once.

So if we call the Random object R and three Die objects D1, D2, and
D3,
you have

R = New Random(...<some seed value from the system tick count>)
D1 = R.Next(...) (=first value in the random sequence)
D2 = R.Next(...) (=second value in the random sequence)
D3 = R.Next(...) (=third value in the random sequence)

and so on.

You might say that this is not entirely correct when mapped to the
real world because the roll of one die actually uses the next rnd
value in a common sequence, which means that rolling D1, D2, D3
produces different results than D1, D3, D2, as one die "uses" a
value that might have been used by another die, i.e. the die objects
do not follow separate sequences (do not have their own Random
object).

But do we (I) care? Nah! :) Keep it simple.

As for appreciating how the Random class works vs OOP? In this
case I think it is a little bit of both. Try setting a breakpoint on
the "Private Shared _generator As New Random" line and run
the code again.

The Random object returns an Integer value (works with Integer
values internally - don't be fooled by the Double functions) from
a sequence calculated using a 56-integer array based on the seed
value in the constructor (tick count if no seed is supplied). Whenever
the .Next function is used, the "next" value from the "sequence" is
returned, the seed array is updated, some indexes to the seed array
are updated, etc. Something like that.

I have not tested how "random" the output from the Random object is.

Seems to be optimized for speed.

I am not sure the algorithm used would be accepted in a Las Vegas
gambling machine, but I suppose it is alright for most everyday uses.

Hope any of this helps.

/JB

On 31 Dec 2005 06:14:55 -0800, "Cap'n Ahab" <sp***********@lycos.com>
wrote:

Thanks for the responses, guys. The one that seems to make it work as
I originally planned is the change below...

Private _generator As New Random ---> Private Shared
_generator As New Random

However, this runs contrary to what I would expect! 180 degrees
wrong!!!!
I would have thought that the code in the constructor would create a
random number between 1 - 6 (which it does) but in addition it would be
a different value for every new object that is instantiated by the die
class as part of the Dim myObject as New Die command (but it doesn't).
Why do they have the same value? I thought if you wanted a value to be
common throughout instantiation of a class THEN you used the SHARED
command - not the other way round as happens here. Using shared makes
instantiations of the Die Class begin with, well, a different number
from each other.

I think this is more of my lack of understanding of how the Random
command works and not my appreciation of OO programming. Do you agree?

[Joergen Bech]

Look at this sample for Visual Basic Scripting Edition (which is sort
of a subset of VB6):
http://msdn.microsoft.com/library/de...d89c926250.asp
(tinyurl: http://tinyurl.com/ants9)

Looks familliar? If you search for Rnd and Randomize, sure you will
end up on those pages. But if you search for something about working
with random numbers in .Net in general, hopefully you will find pages
talking about the Random class.

Rnd and Randomize is part of the Microsoft.VisualBasic namespace
(in the VBMath class).

Rnd returns a single and uses the "classic VB" Rnd algorithm.
It is not the same as using the Random class. It is not even a wrapper
for the Random class.

I have said it before: Microsoft.VisualBasic.* is not "proper" .Net.
So I won't say it again. Or someone will tell me off :)

/JB

On Sat, 31 Dec 2005 16:07:38 +0100, "m.posseth"
<mi*****@nohausystems.nl> wrote:

nope this is VB.Net code

here it is

http://msdn.microsoft.com/library/de...mrandomize.asp

Michel Posseth [MCP]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:gi********************************@4ax.com.. .

Do you have a direct link to that sample?

To me, that looks like VB6 code. Not the way it would be
written in VB.Net.

/JB

On Sat, 31 Dec 2005 15:33:08 +0100, "m.posseth"
<mi*****@nohausystems.nl> wrote:

The code i showed i have also run ,,, and it worked as dices in my
situation

also nice thingy is that alter after the comments i searched the msdn site
and saw that MS does it the same way

Dim MyValue As Integer
Randomize ' Initialize random-number generator.
MyValue = CInt(Int((6 * Rnd()) + 1)) ' Generate random value between 1 and
6.above is MS code

regards

Michel Posseth [MCP]
"Cap'n Ahab" <sp***********@lycos.com> wrote in message
news:11**********************@o13g2000cwo.googl egroups.com...
I have also noticed that instead of using Shared, if I rewrite the
New() constructor by adding the Randomize() command as below...

Public Sub New()
Randomize()
Me.Roll()
End Sub

and then consume 3 objects based on the Die Class,

Then use the same loop..

Dim One As New Die
Dim Two As New Die
Dim Three As New Die

Do

One.Display()
One.Roll()
Two.Display()
Two.Roll()
Three.Display()
Three.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

That the results are not random between the die at all!! The numbers
either are 3 of a the same number OR a pair of numbers an other other
number - no exceptions. How very odd!

Now I AM confused, lol.

[Zanna]

"m.posseth" <mi*****@nohausystems.nl> ha scritto nel messaggio
news:#9**************@TK2MSFTNGP10.phx.gbl...

but i have never found a true answer for it as the thoughts seem to change
day by day regarding this issue

one says the IA-32 architecture processes 32-bit integers just as
fast as 16-bit or 8-bit integers and that the smallest possible size will
preserve memory

Just put Option Strict On and the compiler will correct some extra issues
about 16/32 bits.

--
Reporting tool: http://www.neodatatype.net

[m.posseth]

well in this case we do not share the same point of view , VB = VB if it
works it works

Yes i know VBS and for a fact VBA and VB starting of the folowup to Qbasic
and even better i started with Basic when a PC was a C64

The Microsoft.visualbasic namespace is standard availlable in a VB project
, Do we ask a C# coder to abandon the C# namespace ??
so what is your point in saying Microsoft.VisualBasic.* is not "proper"
..Net

i have chosen to code mainly on the .Net platform in VB.Net so i can use
all of its main advantages faster , simpler coding just to call two of
them

If its name was Microsoft.VisualBasic6.* i would say you are right but in
this case it is just a valid namespace just like anny other

And you were talking about the KIBS principle ?? ( Keep It Bloody Simple )

Are you sure you are not actually a C# progger trying to make VB just as
ineficient ? ;-)
regards

i quit for now ,,, going to travel to my family to start celebrating the
new year with a nice dinner and champagne

so finally

I wish You and your family and everyone else who might read this thread A
verry happy and healthy 2006

Watch out with fireworks !! i would say ,,, clear your thoughts give
everyone who nags you a new chance :-)
Michel Posseth [MCP]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:k8********************************@4ax.com...

Look at this sample for Visual Basic Scripting Edition (which is sort
of a subset of VB6):
http://msdn.microsoft.com/library/de...d89c926250.asp
(tinyurl: http://tinyurl.com/ants9)

Looks familliar? If you search for Rnd and Randomize, sure you will
end up on those pages. But if you search for something about working
with random numbers in .Net in general, hopefully you will find pages
talking about the Random class.

Rnd and Randomize is part of the Microsoft.VisualBasic namespace
(in the VBMath class).

Rnd returns a single and uses the "classic VB" Rnd algorithm.
It is not the same as using the Random class. It is not even a wrapper
for the Random class.

I have said it before: Microsoft.VisualBasic.* is not "proper" .Net.
So I won't say it again. Or someone will tell me off :)

/JB

On Sat, 31 Dec 2005 16:07:38 +0100, "m.posseth"
<mi*****@nohausystems.nl> wrote:

nope this is VB.Net code

here it is

http://msdn.microsoft.com/library/de...mrandomize.asp

Michel Posseth [MCP]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:gi********************************@4ax.com. ..

Do you have a direct link to that sample?

To me, that looks like VB6 code. Not the way it would be
written in VB.Net.

/JB

On Sat, 31 Dec 2005 15:33:08 +0100, "m.posseth"
<mi*****@nohausystems.nl> wrote:

The code i showed i have also run ,,, and it worked as dices in my
situation

also nice thingy is that alter after the comments i searched the msdn
site
and saw that MS does it the same way

Dim MyValue As Integer
Randomize ' Initialize random-number generator.
MyValue = CInt(Int((6 * Rnd()) + 1)) ' Generate random value between 1
and
6.above is MS code

regards

Michel Posseth [MCP]
"Cap'n Ahab" <sp***********@lycos.com> wrote in message
news:11**********************@o13g2000cwo.goog legroups.com...
>I have also noticed that instead of using Shared, if I rewrite the
> New() constructor by adding the Randomize() command as below...
>
> Public Sub New()
> Randomize()
> Me.Roll()
> End Sub
>
> and then consume 3 objects based on the Die Class,
>
> Then use the same loop..
>
> Dim One As New Die
> Dim Two As New Die
> Dim Three As New Die
>
> Do
>
> One.Display()
> One.Roll()
> Two.Display()
> Two.Roll()
> Three.Display()
> Three.Roll()
>
> Loop Until UCase(Console.ReadLine) = "Q"
>
> That the results are not random between the die at all!! The numbers
> either are 3 of a the same number OR a pair of numbers an other other
> number - no exceptions. How very odd!
>
> Now I AM confused, lol.
>

[m.posseth]

i code always with option strict on ( and option explicit )
this is been set above every code module i write

but in this case it was a change to the TS`s code so it wasn`t there

but Zanna what is the problem with this code then ??

Option Explicit On

Option Strict On

Public Class Die

Private _value As Int16

Public Sub New()

Randomize()

Me.Roll()

End Sub

Public ReadOnly Property GetValue() As Int16

Get

Return _value

End Get

End Property

Public Sub Roll()

' Initialize the random-number generator.

Randomize()

' Generate random value between 1 and 6.

_value = CShort(CInt(Int((6 * Rnd()) + 1)))

End Sub

Public Sub Display()

Console.WriteLine(Me.GetValue)

End Sub

End Class

Module Module1

Sub Main()

Dim One As New Die

Dim Two As New Die

Do

One.Display()

One.Roll()

Two.Display()

Two.Roll()

Loop Until UCase(Console.ReadLine) = "Q"

End Sub

End Module

in my opinion this is perfectly valid code ,,,, correct me if i am wrong

regards

Michel Posseth [MCP]

"Zanna" <zn*******@virgilio.it> wrote in message
news:43**********************@reader1.news.tin.it. ..

"m.posseth" <mi*****@nohausystems.nl> ha scritto nel messaggio
news:#9**************@TK2MSFTNGP10.phx.gbl...

but i have never found a true answer for it as the thoughts seem to
change
day by day regarding this issue

one says the IA-32 architecture processes 32-bit integers just as
fast as 16-bit or 8-bit integers and that the smallest possible size will
preserve memory

Just put Option Strict On and the compiler will correct some extra issues
about 16/32 bits.

--
Reporting tool: http://www.neodatatype.net

[Joergen Bech]

The Microsoft.visualbasic namespace is standard availlable in a VB project
, Do we ask a C# coder to abandon the C# namespace ??
I don't think there *is* a C# namespace :)
so what is your point in saying Microsoft.VisualBasic.* is not "proper"
.Net
Sorry. Let me put this another way: I do not use functionality from
the Microsoft.VisualBasic.* namespace if similar functionality can be
found in mscorlib.
i have chosen to code mainly on the .Net platform in VB.Net so i can use
all of its main advantages faster , simpler coding just to call two of
them

If its name was Microsoft.VisualBasic6.* i would say you are right but in
this case it is just a valid namespace just like anny other
In this case, the choice between Rnd and Random is not just a choice
between two namespaces; it is a choice between two different
algorithms.

As I think I have mentioned in another thread, I consider
Microsoft.VisualBasic to be a wrapper around similar functionality
found elsewhere in the framework. A wrapper Microsoft made to
make the transition to .Net easier for the millions of classic VB
developers out there. I wish they would mark the whole namespace
obsolete.
And you were talking about the KIBS principle ?? ( Keep It Bloody Simple )
I think Random.Next(1, 7) is simpler than CInt(Int(Rnd*6)+1).

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. Why have two ways of doing the
same thing? It can only lead to more of those code formatting wars
(like indentation, use of comments, curly braces, etc).
Are you sure you are not actually a C# progger trying to make VB just as
ineficient ? ;-)
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#.

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.

Remember: It is called CLR as in Common *Language* Runtime.

We are all friends here :)
i quit for now ,,, going to travel to my family to start celebrating the
new year with a nice dinner and champagne

Yep. Plenty of time for VB next year.

Regards,

Joergen Bech

[Herfried K. Wagner [MVP]]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:

The Microsoft.visualbasic namespace is standard availlable in a VB
project
, Do we ask a C# coder to abandon the C# namespace ??

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.

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

[Zanna]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> ha scritto nel
messaggio news:pg********************************@4ax.com...

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]]

"Zanna" <zn*******@virgilio.it> schrieb:

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.

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

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.

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.

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

[Joergen Bech]

>> 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'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/St.../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]]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:

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 ;-).

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

[Joergen Bech]

On Sat, 31 Dec 2005 23:03:43 +0100, "Herfried K. Wagner [MVP]"
<hi***************@gmx.at> wrote:

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:

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 ;-).

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 ;-)

.Net. My animosity towards Microsoft.VisualBasic started the day
I needed to translate "Dim dt As Date = DateSerial(y, m, d)" to C#.

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]
"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:88********************************@4ax.com... On Sat, 31 Dec 2005 23:03:43 +0100, "Herfried K. Wagner [MVP]"
<hi***************@gmx.at> wrote:

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:

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 ;-).

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

[Herfried K. Wagner [MVP]]

Joergen,

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:

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>

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

[Joergen Bech]

On Sun, 1 Jan 2006 13:24:34 +0100, "Herfried K. Wagner [MVP]"
<hi***************@gmx.at> wrote:

Joergen,

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:

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>

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/f...namespace.html
http://addressof.com/blog/archive/2003/10/31/242.aspx
http://weblogs.asp.net/jcogley/archi...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/arc...5/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]]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:

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>

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/f...namespace.html
http://addressof.com/blog/archive/2003/10/31/242.aspx
http://weblogs.asp.net/jcogley/archi...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/arc...5/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 :-).

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

[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,

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.

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]

On Sun, 1 Jan 2006 22:42:17 +0100, "Cor Ligthert [MVP]"
<no************@planet.nl> wrote:

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]]

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:

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.

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.

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

[Zanna]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio news:#z**************@TK2MSFTNGP14.phx.gbl...

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...
--
- Free .Net Reporting tool
http://www.neodatatype.net

[Herfried K. Wagner [MVP]]

"Zanna" <zn*******@virgilio.it> schrieb:

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.

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.

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

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?

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.

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.

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

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

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

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().

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

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.

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.

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