Why is the End function still in .NET???
Woka
Printable View
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
Why bother to turn it off. You are hardly likely to use it by mistake are you?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?
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:
It goes on the fact that everything in .NET is an object.VB Code:
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
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 have seen tons of example code from MS programmers that use both
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
I say use whichever you want until someone actually gives me a real reason why MsgBox() is EVIL!!!
Right. But what about using MsgBox in a forms project ? That's just adding another reference that you can do without.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()
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.
Think the .NET equivelant is: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??
WoofVB Code:
You were kinda close, you do it like this:
VB Code:
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
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.Quote:
Originally posted by kleinma
hold the phone... whats wrong with CINT() or CDATE() ????
they are not even in the VB namespace
Dim i As Integer = CInt("10") is equivalent to:
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 [Microsoft.VisualBasic]
Microsoft.VisualBasic.CompilerServices.IntegerType::FromString(string)
IL_000b: stloc.0
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
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.Quote:
Originally posted by kleinma
and what is different about IIF() in .net??
Cheers,
NTG
where do you get these IL traces?Quote:
Originally posted by ntg
Dim i As Integer = CInt("10") is equivalent to:
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 [Microsoft.VisualBasic]
Microsoft.VisualBasic.CompilerServices.IntegerType::FromString(string)
IL_000b: stloc.0
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
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
I've used the standard MS ILDasm tool, that should be at your FrameworkSDK\Bin\ildasm.exe path.Quote:
Originally posted by kleinma
where do you get these IL traces?
Cheers,
NTG
they arent VB6 functions...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
errrr..CLng, MsgBox etc...not vb6 functions??? hmmmmm :confused:
Woka
ugh... from MSDNQuote:
Originally posted by Wokawidget
errrr..CLng, MsgBox etc...not vb6 functions??? hmmmmm :confused:
Woka
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.
http://msdn.microsoft.com/library/de...tinternals.aspQuote:
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.
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...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
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:
well I only program in VB.NET, but I would imagine that the messagebox.show works in C# as well as VBQuote:
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:
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.Quote:
Originally posted by kleinma
I would imagine that the messagebox.show works in C# as well as VB
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.
Hmm, couldn't get it to work.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.
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.
Because in general, C# programmers are much sexier than VB programmers.Quote:
Originally posted by cpatzer
Why is it that some people put C# above VB?
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?
there are few things you can do in C# that can't be done in VB.NET and with each release of VS.NET (IE, 2002, 2003, and soon to be 2005) the gap seems to be getting smaller. They keep adding. Either way the differences are very very small.. and 99% of the time you won't use the additional things.
A lot of people say C# is better because .NET was written in it.. but that really doesn't mean anything...
as far as salaries go.. I read an article on that and C# programmer get paid more, not because C# is more powerful a language.. but generally C# programmers come from a C background versus VB.NET programmers coming from a VB background..
there is less learning curve because they have been working with full OO languages already, where VB users are now learning these new features...
Well, I have worked with PHP, PERL, JavaScript, MySql, VB, VB.NET (HTML of course who hasn't) So I don't think that applies in my case (of course I could be wrong).
JavaScript for one, being only a scripting language, is OOP and OOP is available in both PERL and PHP though both of those languages do include quite a few intrinsic functions and are both scripting languages.
Though I must say OOP is pretty much all that I use in these languages as OOP ROCKS!!! It is the most flexible, reusable, logical way to program (again in my most humble opinion).
So I would say that it would really rely on your background as a whole.
well that is why i said generally... of course it could be looked at on a case by case basis... but when you are going to work at some big company... and they are doing applications in .NET, chances are they would rather hire a C# developer with lots of C on his resume over a VB.NET programmer with VB6 on his resume (or her resume.. sorry laides)
but to each his own.. i make a pretty damn good living and I don't touch C or C#, simply because I don't need to.
Not that I'm advocating one language over the other, it's really more preference, but there are some things you can do in C# that can't be done in VB. An unsafe code block is a block of code (marked as unsafe) where you can use pointers. That's probably a bad explanation, check it out on MSDN.
i think they are "unsafe" or "unmanaged" because they go outside the scope of the framework and if not done correctly can cause a major crash versus just the runtime throwing up an exception...Quote:
Originally posted by Mike Hildner
Not that I'm advocating one language over the other, it's really more preference, but there are some things you can do in C# that can't be done in VB. An unsafe code block is a block of code (marked as unsafe) where you can use pointers. That's probably a bad explanation, check it out on MSDN.
The documentation says unsafe is needed for stuff that uses pointers and is not verifiable by the command language runtime. I'm not sure if that means unmanaged or not. When I think unmanaged, I think unmanaged C++. That is, does not rely on .NET at all.
I have the book, C# Complete, I think it's called, that has a pretty good section on some things that C# can do that VB.NET cannot, it also lists some stuff that C# cannot do, but C++ can.
Personally, I've never had to use anything that C# can do that VB.NET can't, I guess it applies somewhere.
I agree whole-heartedly with what you say about salaries, BTW.
Well, I have to admit that's interesting. Some of the points I see in that article:Quote:
1. Most old-style methods (CInt, Mid, Left, etc) are wrappers for the system class equivalent methods.
2. There are some distinct cases where some of the old-style methods don't have system class alternates.
3. The authors say that some old-style calls are actually faster than the system class equivalents (even though they call system class methods).
4. You can't prevent a VB.Net executable assembly from loading Microsoft.VisualBasic namespace.
OK. Let's see:
1. Right, that sounds reasonable. But in this case, why would we want to use wrapper classes unless we have to ? Generally speaking, IMHO the only right place to use wrapper classes purposefully is to expose primitive types as objects (like the Integer class).
2. Right again. That's what I've been saying for some time now, if you HAVE to use old-style functions and know what you're about then go do it.
3. That didn't sound right, how can methods that are actually wrappers for the system class be faster ? I quote:
So I wrote the following:Quote:
The Mid, Left, and Right methods in Visual Basic .NET all call String.Substring. However, the Visual Basic Runtime methods are optimized to prevent string allocation for some common cases. For example, the following simple case is 85 percent faster using the Visual Basic Runtime methods versus the System method:
Recommendation: Use Mid, Left, and Right, which are found in the VisualBasic namespace.VB Code:
VB Code:
where StopWatch is a copy of the StopWatch class used in the Prime Numbers contest. The results I'm getting are that the String.Substring method calls are being executed slightly faster. That much about 85% speed gains. BTW, here's the IL for the Mid method.
I don't know about you ppl, but that doesn't seem like what I'd want to do.Code:.method public hidebysig static string Mid(string str,
int32 Start,
int32 Length) cil managed
{
// Code size 107 (0x6b)
.maxstack 3
.locals init (int32 V_0,
string V_1)
IL_0000: ldarg.1
IL_0001: ldc.i4.0
IL_0002: bgt.s IL_0019
IL_0004: ldstr "Argument_GTZero1"
IL_0009: ldstr "Start"
IL_000e: call string Microsoft.VisualBasic.CompilerServices.Utils::GetResourceString(string,
string)
IL_0013: newobj instance void [mscorlib]System.ArgumentException::.ctor(string)
IL_0018: throw
IL_0019: ldarg.2
IL_001a: ldc.i4.0
IL_001b: bge.s IL_0032
IL_001d: ldstr "Argument_GEZero1"
IL_0022: ldstr "Length"
IL_0027: call string Microsoft.VisualBasic.CompilerServices.Utils::GetResourceString(string,
string)
IL_002c: newobj instance void [mscorlib]System.ArgumentException::.ctor(string)
IL_0031: throw
IL_0032: ldarg.2
IL_0033: ldc.i4.0
IL_0034: beq.s IL_0039
IL_0036: ldarg.0
IL_0037: brtrue.s IL_003f
IL_0039: ldstr ""
IL_003e: ret
IL_003f: ldarg.0
IL_0040: callvirt instance int32 [mscorlib]System.String::get_Length()
IL_0045: stloc.0
IL_0046: ldarg.1
IL_0047: ldloc.0
IL_0048: ble.s IL_0050
IL_004a: ldstr ""
IL_004f: ret
IL_0050: ldarg.1
IL_0051: ldarg.2
IL_0052: add.ovf
IL_0053: ldloc.0
IL_0054: ble.s IL_0060
IL_0056: ldarg.0
IL_0057: ldarg.1
IL_0058: ldc.i4.1
IL_0059: sub.ovf
IL_005a: callvirt instance string [mscorlib]System.String::Substring(int32)
IL_005f: ret
IL_0060: ldarg.0
IL_0061: ldarg.1
IL_0062: ldc.i4.1
IL_0063: sub.ovf
IL_0064: ldarg.2
IL_0065: callvirt instance string [mscorlib]System.String::Substring(int32,
int32)
IL_006a: ret
} // end of method Strings::Mid
4. That was an interesting revelation. Since that's true, I'll concede that any use of old-style methods doesn't associate with it the penalty of loading the DLL.
Since we're also talking about C#, there's also another point that I must make. In my team there are 4 ppl using .Net, one being a good C# programmer without any VB background. We have some projects in maintenance and I feel it's good that every programmer can maintain code regardless of whether it's VB or C#. I can imagine what the C# guy would say if he saw:
"Darn, what the heck is that ?" That's what he'd say.VB Code:
Apologies for the lengthy post. :blush:
Cheers,
NTG
OK,
Since I seem to have all of the experts in this forum I thought I could pose this question here as I am still a bit of a newb.
When calling functions in your application that get called time and time again. Is it bad if you Dim variables in those functions.
Or is this the way it should to be?Code:Private Function getFileProps(ByVal path As String)
Dim myStreamReader As New StreamReader("C:\myFile.txt")
Dim myFileInfo As New FileInfo(path)
Dim myFileSize As Integer = myFileInfo.Length
Dim myXMLDocument As New XmlDocument
myXMLDocument.Load("C:\myXMLDoc.xml")
...
End Function
Code:
Private Function getFileProps(ByVal path As String)
Dim myStreamReader As New StreamReader("C:\myFile.txt")
Dim myFileInfo As New FileInfo(path)
Dim myFileSize As Integer = myFileInfo.Length
Dim myXMLDocument As New XmlDocument
myXMLDocument.Load("C:\myXMLDoc.xml")
...
myStreamReader = Nothing
myFileInfo = Nothing
myFileSize = Nothing
myXMLDocument = Nothing
End Function
I read somewhere that setting most stuff in .NET to Nothing does just that Nothing and that the garbage collector will pick them up.
Yet my application I am currently working on is how you say "The 12 days of Christmas"!
This function would be called every 10 seconds. For testing purposed it is being called every 2/10ths of a second.
Please let me know the right way.
Hi,Quote:
Originally posted by cpatzer
OK,
Or is this the way it should to be?
Code:
Private Function getFileProps(ByVal path As String)
Dim myStreamReader As New StreamReader("C:\myFile.txt")
Dim myFileInfo As New FileInfo(path)
Dim myFileSize As Integer = myFileInfo.Length
Dim myXMLDocument As New XmlDocument
myXMLDocument.Load("C:\myXMLDoc.xml")
...
myStreamReader = Nothing
myFileInfo = Nothing
myFileSize = Nothing
myXMLDocument = Nothing
End Function
I read somewhere that setting most stuff in .NET to Nothing does just that Nothing and that the garbage collector will pick them up.
I thought the variables would be set to Nothing immediately the code went out of their scope.
That's if you know C#. I know VB.NET and it's easier for me to read VB.NET code. Sense? :afrog:Quote:
Originally posted by Mike Hildner
Other than that, IMHO, C# code is much cleaner and easier to read than VB.
Your second method is fine. Scope is limited to the function.Quote:
Originally posted by cpatzer
OK,
I read somewhere that setting most stuff in .NET to Nothing does just that Nothing and that the garbage collector will pick them up.
Yet my application I am currently working on is how you say "The 12 days of Christmas"!
This function would be called every 10 seconds. For testing purposed it is being called every 2/10ths of a second.
Please let me know the right way.
Links on th GC:
http://msdn.microsoft.com/library/de...etGCbasics.asp
http://msdn.microsoft.com/msdnmag/issues/1100/gci/
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/
So I don't or I do have to set the variables to nothing?
Thanks
Hi
No you don't have to set them to nothing.
Regards
Jorge
Thank you.
Thank you.
Inshort, Msgbox is a wrapper for Messagebox.Show
The only extra work it does is Agument checking and converting and grabing the assembly name and window title.
VBCode:method public static Microsoft.VisualBasic.MsgBoxResult MsgBox(object Prompt, Microsoft.VisualBasic.MsgBoxStyle Buttons, object Title) cil managed
{
.param [2] = int32(0x00000000)
.param [3] = (nullref)
// Code Size: 198 byte(s)
.maxstack 8
.locals (
Microsoft.VisualBasic.MsgBoxResult result1,
[System.Windows.Forms]System.Windows.Forms.IWin32Window window1,
string text1,
string text2,
Microsoft.VisualBasic.CompilerServices.IVbHost host1)
L_0000: call Microsoft.VisualBasic.CompilerServices.IVbHost Microsoft.VisualBasic.CompilerServices.HostServices::get_VBHost()
L_0005: stloc.s host1
L_0007: ldloc.s host1
L_0009: brfalse.s L_0013
L_000b: ldloc.s host1
L_000d: callvirt instance [System.Windows.Forms]System.Windows.Forms.IWin32Window Microsoft.VisualBasic.CompilerServices.IVbHost::GetParentWindow()
L_0012: stloc.1
L_0013: ldarg.1
L_0014: ldc.i4.s 15
L_0016: and
L_0017: ldc.i4.5
L_0018: bgt.s L_0033
L_001a: ldarg.1
L_001b: ldc.i4 240
L_0020: and
L_0021: ldc.i4.s 64
L_0023: bgt.s L_0033
L_0025: ldarg.1
L_0026: ldc.i4 3840
L_002b: and
L_002c: ldc.i4 512
L_0031: ble.s L_0036
L_0033: ldc.i4.0
L_0034: starg.s Buttons
L_0036: ldarg.0
L_0037: brfalse.s L_0040
L_0039: ldarg.0
L_003a: call string Microsoft.VisualBasic.CompilerServices.StringType::FromObject(object)
L_003f: stloc.2
L_0040: leave.s L_005d
L_0042: pop
L_0043: ldstr "Argument_InvalidValueType2"
L_0048: ldstr "Prompt"
L_004d: ldstr "String"
L_0052: call string Microsoft.VisualBasic.CompilerServices.Utils::GetResourceString(string, string, string)
L_0057: newobj instance void [mscorlib]System.ArgumentException::.ctor(string)
L_005c: throw
L_005d: ldarg.2
L_005e: brtrue.s L_0080
L_0060: ldloc.s host1
L_0062: brtrue.s L_0076
L_0064: call [mscorlib]System.Reflection.Assembly [mscorlib]System.Reflection.Assembly::GetCallingAssembly()
L_0069: callvirt instance [mscorlib]System.Reflection.AssemblyName [mscorlib]System.Reflection.Assembly::GetName()
L_006e: callvirt instance string [mscorlib]System.Reflection.AssemblyName::get_Name()
L_0073: stloc.3
L_0074: leave.s L_00a4
L_0076: ldloc.s host1
L_0078: callvirt instance string Microsoft.VisualBasic.CompilerServices.IVbHost::GetWindowTitle()
L_007d: stloc.3
L_007e: leave.s L_00a4
L_0080: ldarg.2
L_0081: call string Microsoft.VisualBasic.CompilerServices.StringType::FromObject(object)
L_0086: stloc.3
L_0087: leave.s L_00a4
L_0089: pop
L_008a: ldstr "Argument_InvalidValueType2"
L_008f: ldstr "Title"
L_0094: ldstr "String"
L_0099: call string Microsoft.VisualBasic.CompilerServices.Utils::GetResourceString(string, string, string)
L_009e: newobj instance void [mscorlib]System.ArgumentException::.ctor(string)
L_00a3: throw
L_00a4: ldloc.1
L_00a5: ldloc.2
L_00a6: ldloc.3
L_00a7: ldarg.1
L_00a8: ldc.i4.s 15
L_00aa: and
L_00ab: ldarg.1
L_00ac: ldc.i4 240
L_00b1: and
L_00b2: ldarg.1
L_00b3: ldc.i4 3840
L_00b8: and
L_00b9: ldarg.1
L_00ba: ldc.i4 -4096
L_00bf: and
L_00c0: call [System.Windows.Forms]System.Windows.Forms.DialogResult [System.Windows.Forms]System.Windows.Forms.MessageBox::Show([System.Windows.Forms]System.Windows.Forms.IWin32Window, string, string, [System.Windows.Forms]System.Windows.Forms.MessageBoxButtons, [System.Windows.Forms]System.Windows.Forms.MessageBoxIcon, [System.Windows.Forms]System.Windows.Forms.MessageBoxDefaultButton, [System.Windows.Forms]System.Windows.Forms.MessageBoxOptions)
L_00c5: ret
.try L_0036 to L_0042 catch [mscorlib]System.Exception handler L_0042 to L_005d
.try L_005d to L_0089 catch [mscorlib]System.Exception handler L_0089 to L_00a4
VB Code:
What can you do in C# and cannot do VB.Net, is it worth me starting to learn C# ????Quote:
Originally Posted by Mike Hildner
<Shocked Dino>
Quote:
Originally Posted by Mike Hildner
Its all what you get used to, i prever VB for exactly the same reason :D
Unsafe code is C# code that uses pointers. I don't like the way C# does it though, its as if there is a stigma in using pointers.
Its not that VB can't do the same stuff as C#'s unsafe code, but not having pointers, VB must do it a different way.
This is all swings and roundabouts.
There's a little more to it than just unsafe code. Read this. Of course, stick with whatever you like, or go both ways, who cares? Personally I prefer one syntax over another, but that's just me.
HEY, That's a double negative!! Bad grammar! Bad! ;)Quote:
Originally Posted by Asgorath
In general, variables declared within a function block are not created on the heap, but are created on the stack, and are gone as soon as the function returns. Considering that .NET goes through the IL, I don't know whether or not that is true for .NET code or not. Does anybody know? Does anybody care, considering that garbage collection would have the same apparent result regardless of actual behavior?
One thing to keep in mind is that a part of this argument is form over function. I remember people complaining about C++ (back during ANSI standardization time) because it wasn't "REALLY" OO the way that a language such as SmallTalk was because you could still have global variables and code outside of objects.
I've always been bothered by people who rationalize a certain design practice because it follows a prescribed 'form'. I have currently moved away from most global basic types (strings, ints, etc.), and included what would have been global basic types into classes that include some functions for doing manipulations across all the variables. While this has advantages for organization, I certainly wouldn't claim it to be any doctrine.
The goal is to balance functionality, efficiency and maintainability. C# and VB are almost indistinguishable in all three areas. While there are differences, most people will probably not encounter those differences, so which language they choose depends more on familiarity (and thus maintainability) rather than language features.
Enough rambling.