"Clever" classic VB trick
-
I used to include this function in some classic VB apps: Function RunningInDevEnv() as Boolean On Error Resume Next Debug.Print 1/0 RunningInDevEnv = (Err.Number <> 0) End Function I was curious and tried running this in VB.NET: Function RunningInDevEnv() As Boolean On Error Resume Next Debug.Print(1 / 0) Return (Err.Number <> 0) End Function It compiles in VB.NET but always returns True. I noticed the C# compiler does not accept 1 / 0 at all. Is the VB.NET compiler being so forgiving here a good thing? Sad to say some poor soul as I write this is probably trying to port one of my old VB apps to VB.NET and wondering why some "weird" behavior by the classic app in development mode is not carrying over to VB.NET. I hope the gods above will forgive me. I think the lesson is to try to avoid clever tricks like this, even when they work (for awhile).
-
I used to include this function in some classic VB apps: Function RunningInDevEnv() as Boolean On Error Resume Next Debug.Print 1/0 RunningInDevEnv = (Err.Number <> 0) End Function I was curious and tried running this in VB.NET: Function RunningInDevEnv() As Boolean On Error Resume Next Debug.Print(1 / 0) Return (Err.Number <> 0) End Function It compiles in VB.NET but always returns True. I noticed the C# compiler does not accept 1 / 0 at all. Is the VB.NET compiler being so forgiving here a good thing? Sad to say some poor soul as I write this is probably trying to port one of my old VB apps to VB.NET and wondering why some "weird" behavior by the classic app in development mode is not carrying over to VB.NET. I hope the gods above will forgive me. I think the lesson is to try to avoid clever tricks like this, even when they work (for awhile).
Follow the white rabbit... VB6 wouldn't compile Debug.Print statements into the final code, and therefore wouldn't compile in the expression being evaluated either. Therefore if you were in the environment the division by zero would cause an error to be raised but you'd resume at the next statement, and the error number would be set to something other than 0, but in the compiled code the line causing the error wouldn't be present, so the problem wouldn't occur. A debug build of the VB.NET code would cause the error to occur and the operation would return True. A release build should not. See the documentation for
ConditionalAttribute. The C# compiler tends to have better diagnostics and won't allow you to compile division by a literal zero. You'd have to use a variable containing the value 0.Stability. What an interesting concept. -- Chris Maunder
-
I used to include this function in some classic VB apps: Function RunningInDevEnv() as Boolean On Error Resume Next Debug.Print 1/0 RunningInDevEnv = (Err.Number <> 0) End Function I was curious and tried running this in VB.NET: Function RunningInDevEnv() As Boolean On Error Resume Next Debug.Print(1 / 0) Return (Err.Number <> 0) End Function It compiles in VB.NET but always returns True. I noticed the C# compiler does not accept 1 / 0 at all. Is the VB.NET compiler being so forgiving here a good thing? Sad to say some poor soul as I write this is probably trying to port one of my old VB apps to VB.NET and wondering why some "weird" behavior by the classic app in development mode is not carrying over to VB.NET. I hope the gods above will forgive me. I think the lesson is to try to avoid clever tricks like this, even when they work (for awhile).
.net already has the method. system.diagnostics.debugger.isattached
-
.net already has the method. system.diagnostics.debugger.isattached
try creating a usercontrol, and put that control on a form. that method isnt very reliable as you will see.
:badger: