END function in .NET???

Why is the End function still in .NET???

Woka

Just to annoy the hell out of you.

WHY?! There is no backwards compatibility with .NET...so WHY WHY WHY have it in.
Stupid .NET END MS Woof

MsgBox still exists too, btw. There is a bit of 'persisted memory' with vb.net, I guess. This should go away in 2005.

There's lots of them, Format(...) is another, the .NET way being StringVariable.Format(...) etc. Is it possible to turn it off?

I think it's possible if you remove references to microsoft.visualbasic

Quote:

---

Originally posted by Ideas Man
There's lots of them, Format(...) is another, the .NET way being StringVariable.Format(...) etc. Is it possible to turn it off?

---

Why bother to turn it off. You are hardly likely to use it by mistake are you?

YES you are.
I was using MsgBox untiul someone here said...no, no, no :D

Ooops.

Woka

Just avoid using shared legacy functions. Most things are accomplished via object.member syntax now.

One thing I would have liked VB.Net to carry over is the Like 'operator'. It is accessible through interop but it is a pain to have to go thel ong way round to get it. Although Regex is much more powerful, it can be a pain to set up.

BTW, End was a statement, not a function :)

Well, lots of people already bitzch a lot about the changes from VB6 to VB.Net, especially about changes that make porting even more difficult. Imagine what they'd say if there was no compatibility namespace. ;) True, it makes things more difficult in the sense that it sets ppl to think that things like End, MsgBox etc. are still a part of .Net but I would assume that the price of scraping the compatibility namespace was simply deemed to be too high.

Cheers,
NTG

Can I ask why MsgBox is bad to use in .NET?
Is there a replacement for this?
Why would you want it to go away?


Thanks.

The replacement is:

VB Code:

MessageBox.Show("Woof")

It goes on the fact that everything in .NET is an object.

Woka

personally I don't think it is bad to use it

first of all, the replacement in .NET is to use MessageBox.Show

second of all, messagebox.Show is part of the forms dll, so lets say you are writing a formless service or something, you need to reference the DLL to access messagebox.show, same as you need to access the VB library for MsgBox()

I say use whichever you want until someone actually gives me a real reason why MsgBox() is EVIL!!!

I have seen tons of example code from MS programmers that use both

Quote:

---

Originally posted by kleinma
I have seen tons of example code from MS programmers that use both

---

That's hardly an argument for this practice being ok. ;) Don't get me started on VB code from MS - there are numerous VB examples in MSDN that are utter dogszhit.

Quote:

---

Originally posted by kleinma
I say use whichever you want until someone actually gives me a real reason why MsgBox() is EVIL!!!

---

I don't have nothing against MsgBox in particular but things like that can give the false impression that nothing has changed. Yes, it's a shared method, just like MessageBox.Show - yes, it comes out of a library, just like MessageBox.Show...but by relying on MsgBox, CInt, CDate, Mid, Left, On Error Goto, IIf etc it's easy for some ppl to miss the big picture. Something has changed. And to that add that some parts of the VisualBasic namespace don't behave as a .Net programmer would expect them to, IIf being a good example.

Quote:

---

Originally posted by kleinma
second of all, messagebox.Show is part of the forms dll, so lets say you are writing a formless service or something, you need to reference the DLL to access messagebox.show, same as you need to access the VB library for MsgBox()

---

Right. But what about using MsgBox in a forms project ? That's just adding another reference that you can do without.

Bottom line for me: if you know that you need something in Microsoft.VisualBasic and you can't do it any other way, go ahead and use it. Otherwise, do it the other way. Only real excuse for not bothering to explore and learn the System class is porting code from VB6 to VB.Net in a hurry. BTW, is there a Microsoft.VisualBasic namespace in Mono ?

Cheers,
NTG

hold the phone... whats wrong with CINT() or CDATE() ????

they are not even in the VB namespace

and what is different about IIF() in .net??

I'll be corrected if I'm wrong, but this is what I've heard about IIf in .NET: It evaluates all three parts (does the comparison, loads both values) and then sends them to the Iif function. That is considered inefficient.

Quote:

---

Originally posted by kleinma
hold the phone... whats wrong with CINT() or CDATE() ????

they are not even in the VB namespace

and what is different about IIF() in .net??

---

Think the .NET equivelant is:

VB Code:

CType(Text1.Text, Integer)
'Or something like:
Text1.Text.COnvert(Integer) 'not sure if the syntax is correct here

Woof

You were kinda close, you do it like this:

VB Code:

Convert.ToInt32(Text1.Text)

Yea. That's the beastie. There's another method alos, but I can't think of it off the top of my head as I have other serious problems at work I am trying to deal with. God damn IIS and ASP.NET and web projects :(

WOOOOOF

Quote:

---

Originally posted by kleinma
hold the phone... whats wrong with CINT() or CDATE() ????

they are not even in the VB namespace

---

Like I said, nothing wrong as long as you know why you would want to use CInt instead of Convert.ToInt32 or Integer.Parse. By the way, Integer.Parse offers a lot more control in integer conversion.

Dim i As Integer = CInt("10") is equivalent to:

Code:

---

  .maxstack  1
  .locals init ([0] int32 i)
  IL_0000:  nop
  IL_0001:  ldstr      "10"
  IL_0006:  call      int32 [Microsoft.VisualBasic]
Microsoft.VisualBasic.CompilerServices.IntegerType::FromString(string)
  IL_000b:  stloc.0

---

Dim i As Integer = Convert.ToInt32("10") is equivalent to:

Code:

---

  .maxstack  1
  .locals init ([0] int32 i)
  IL_0000:  nop
  IL_0001:  ldstr      "10"
  IL_0006:  call      int32 [mscorlib]System.Convert::ToInt32(string)
  IL_000b:  stloc.0

---

Quote:

---

Originally posted by kleinma
and what is different about IIF() in .net??

---

Not different than VB6. However, some ppl have gotten used to the fact that you can control whether boolean expressions will be short-circuited or not. You don't have that kind of control with IIf, and it's much easier to code a MyIIf class with two static overloaded methods that could provide the functionality of IIf with more control. Again, if a coder fully understands what's happening behind the curtains it's A-OK to use IIf, CInt and the like.

Cheers,
NTG

Quote:

---

Originally posted by ntg

Dim i As Integer = CInt("10") is equivalent to:

Code:

---

  .maxstack  1
  .locals init ([0] int32 i)
  IL_0000:  nop
  IL_0001:  ldstr      "10"
  IL_0006:  call      int32 [Microsoft.VisualBasic]
Microsoft.VisualBasic.CompilerServices.IntegerType::FromString(string)
  IL_000b:  stloc.0

---

Dim i As Integer = Convert.ToInt32("10") is equivalent to:

Code:

---

  .maxstack  1
  .locals init ([0] int32 i)
  IL_0000:  nop
  IL_0001:  ldstr      "10"
  IL_0006:  call      int32 [mscorlib]System.Convert::ToInt32(string)
  IL_000b:  stloc.0

---

---

where do you get these IL traces?

Does VS produce them?

Integer.Parse...that's the beatie.

Fixed my .NET problem...upgrading to SP2 busts web projects stored in source safe :(

Got everything working now though.

Kleinma...why use vb6 functions?

Woka

Quote:

---

Originally posted by kleinma
where do you get these IL traces?

---

I've used the standard MS ILDasm tool, that should be at your FrameworkSDK\Bin\ildasm.exe path.

Cheers,
NTG

Quote:

---

Originally posted by Wokawidget
Does VS produce them?

Integer.Parse...that's the beatie.

Fixed my .NET problem...upgrading to SP2 busts web projects stored in source safe :(

Got everything working now though.

Kleinma...why use vb6 functions?

Woka

---

they arent VB6 functions...

errrr..CLng, MsgBox etc...not vb6 functions??? hmmmmm :confused:

Woka

Quote:

---

Originally posted by Wokawidget
errrr..CLng, MsgBox etc...not vb6 functions??? hmmmmm :confused:

Woka

---

ugh... from MSDN

Quote:

---

MsgBox versus MessageBox.Show
In Visual Basic .NET, the MsgBox method is a Visual Basic Runtime wrapper around a call to the MessageBox.Show method from the System.Windows.Forms namespace. MsgBox does some extra work to emulate the behavior of the Visual Basic 6 MsgBox function before culminating in a call to MessageBox.Show. The minute cost of these emulating steps is insignificant, particularly when compared to the time it takes a user to react to a dialog box.

Note MsgBox returns the same integer values returned by MessageBox.Show. Strictly speaking MessageBox.Show returns a DialogResult value and MsgBox returns a MsgBoxResult value. The values in these enumerations have the same meanings: OK = 1, Yes = 6, No = 7, and so on. You can also use CType to convert a MsgBoxResult to a DialogResult.
The choice between MsgBox and MessageBox is a matter of consistency. If you are migrating a Visual Basic 6 application to Visual Basic .NET, there is no compelling reason to replace calls to MsgBox with MessageBox.Show.

Recommendation: Use MsgBox throughout your code.

---

Quote:

---

Visual Basic .NET includes data type conversion keywords, many of which are carried over from Visual Basic 6. But unlike the Visual Basic 6 functions, these keywords are not function calls but intrinsic language features. The keywords CBool, CByte, CChar, CShort, CInt, CLng, CSng, CDbl, CDec, CDate, CObj, and CStr map to Visual Basic Runtime method calls, .NET Framework class library method calls, or IL type conversion instructions. The exact method call or IL instructions generated depends on the expression against which the conversion is being applied. Some conversions are optimized away, such as CInt(123.45) which is replaced with the integer constant 123 in the IL. This is an example where using the Visual Basic Runtime results in better performance than using the System namespace. CInt("123") becomes a call that leads to calls to System.Double.Parse then System.Math.Round. CStr(4853) is ultimately handled by System.Int32.ToString. Conversions that are not optimized away eventually lead to methods in the System namespace, but there is no significant performance benefit when using the System namespace methods directly. Furthermore, the Visual Basic compiler is able to perform certain optimizations on conversions using the language keywords that it does not perform on conversions done through the System namespace.

---

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

Yea, that's only if you're converting.

So in general, with a new .NET app use MessageBox.Show

No point in sloppy coding using 1/2 VB6 and 1/2 .NET

Woka

Quote:

---

Originally posted by Wokawidget
Yea, that's only if you're converting.

So in general, with a new .NET app use MessageBox.Show

No point in sloppy coding using 1/2 VB6 and 1/2 .NET

Woka

---

woka, its not like they just straight ported over the MsgBox function... yes it has the same params as a VB6 messagebox.. but it is still a rewritten method...

did you not see the bold text that said
Recommendation: Use MsgBox throughout your code.

while i will give you that it says
MsgBox does some extra work to emulate the behavior of the Visual Basic 6 MsgBox function before culminating in a call to MessageBox.Show

it still says
The minute cost of these emulating steps is insignificant, particularly when compared to the time it takes a user to react to a dialog box.

so its up to preference as far as I am concerned.. its not like they are going to remove msgbox from the framework...

Ok,

So MsgBox is a VB6 function call that has been "converted" to .NET, right? And MessageBox.Show is a "pure" .NET object.

Other than that, in what functionality do they differ?

I don't want to know about wrappers or anthing else, just how are they functionally different?

If they aren't why did Microsoft choose to do this?

If it aint broke don't fix it right?

Thanks:thumb:

Quote:

---

Originally posted by cpatzer
Ok,

So MsgBox is a VB6 function call that has been "converted" to .NET, right? And MessageBox.Show is a "pure" .NET object.

Other than that, in what functionality do they differ?

I don't want to know about wrappers or anthing else, just how are they functionally different?

If they aren't why did Microsoft choose to do this?

If it aint broke don't fix it right?

Thanks:thumb:

---

well I only program in VB.NET, but I would imagine that the messagebox.show works in C# as well as VB

Quote:

---

Originally posted by kleinma
I would imagine that the messagebox.show works in C# as well as VB

---

Nope. Or at least it doesn't appear to in a quick test. No reason for it in C# anyway - the VB namespace is a convenience for VB programmers.

MessageBox.Show most certainly works in C#.

I'm a dope. Read too quickly and thought the assertion was that MsgBox would work in C#.

lol. MsgBox would work, though, if you import (using) the VisualBasic namespace. Why you would do that, I don't know.

Quote:

---

Originally posted by Mike Hildner
lol. MsgBox would work, though, if you import (using) the VisualBasic namespace. Why you would do that, I don't know.

---

Hmm, couldn't get it to work.
And now I'm asking a bigger question, why do I care? - I only work in C# anyway. Silly VB nonsense... ;)

Why is it that some people put C# above VB?

I have worked it both somewhat and the only real difference is syntax.

I want my programming to ge quick and painless. I have alot of crap to do in a little time!

I wasn't [putting C# above VB] - just a little joke. However I will say that even coming from a VB background I now much prefer C# - but that's all it really is - a preference thing.

Quote:

---

Originally posted by cpatzer
Why is it that some people put C# above VB?

---

Because in general, C# programmers are much sexier than VB programmers.

Seriously though, C# programmers get paid more than VB.NET programmers. There are things you can do in C# that you can't do in VB.NET - unsafe code blocks, for example. Other than that, IMHO, C# code is much cleaner and easier to read than VB.

Unsafe code block?