Discussion: Option Strict and VB functions

[divil]

Robby here...I had a hard time merging these threads, so I'm invading your post Divil.

 

This is a spin-off from another thread.

 

The discussion is:

 

- Using Option Strict On

- Using VB functions such as Mid$, Left$, Len, CInt, Clng, MsgBox etc...

 

 

________________________________End of Robby's note:

 

 

When you stop relying on VB doing the work for you :P

 

Turn on Option Strict, always. It stops you doing bad things like mixing data types and not explicitly converting.

Edited April 3, 2003 by Robby

[bpayne111]

ohh yes i forgot about old option strict... good point divill

i know i should be using it now but i guess i am actually just being lazy :\

[Robby]

Actually the old one is Option Expicit, the new one is Option Strict.

That's the important one, it's a real must have.

 

I can say I found one instance where I was forced to turn it off, :(

'CData being an Excel range...
arr(iRow, iCol) = CType(CData(iRow, iCol).value, String)

[Volte]

Would

arr(iRow, iCol) = Convert.ToString(CData(iRow, iCol).Value)

not work? I avoid any functions that you can't use in both C#

and VB.NET (CWhatever() functions, MsgBox(), Int(), etc).

[Robby]

It'll work but only with Option Strict Off :(

[Guest mutant]

Would

arr(iRow, iCol) = Convert.ToString(CData(iRow, iCol).Value)

not work? I avoid any functions that you can't use in both C#

and VB.NET (CWhatever() functions, MsgBox(), Int(), etc).

 

Dont get me wrong, im not trying to insult anybody or anything like that. Ive been reading through your posts, and you keep saying that you dont use functions that cant be used in C#. I dont see why, both are separate languages, if its just because both operate on .NET framework, then what would you do if you were programming visual C++ .net. Notice the bold .net so you dont confuse it with "normal" C++,. Again, i got nothing against it but this intrests me, so if you dont have anything against would mind telling me why you think this way?

[bpayne111]

i'm gonna take it upon myself to answer for him...

I actually thought that was a good idea (not great, but good for learning) because i see lots of people sitting in vb class typing == and wondering what's wrong.

well anyway only using functions that are common to both would keep you from going 'errr ummm is that vb or c' so why not until you get to the point where you have to break the trend and learn the differences.

 

My personal plan is somewhat different. I'm trying to master vb as well as i can so that any differences in C# will jump out and smack me in the face and i'll remember them right off the bat.

but this whole issue is way off subject maybe we should start a new thread. I am personally interested in everyones ways of coping with multiple languages.

[Volte]

Well, I am very strict about my personal coding standards, and in my

opinion, that is one that should be followed. There's nothing wrong

with using those functions, but I don't. They might do the same

things when compiled, I don't know.

[Guest mutant]

I got nothing against about your coding standards, they are yours :) . It was just intresting to me.

[Volte]

Robby: what is the error that Option Strict gives you?

[Robby]

From the list of all VB functions ... CWhatever() , MsgBox(), Int() String Functions...

The only one I do use is CType(), never CInt, Clng or Left$(),Mid$() etc...

 

Nothing to do with C#, it's just the way like it.

[Robby]

Late Binding not allowed.

[Volte]

OK, then, is arr() an array of Strings, or what?

[Robby]

yup

[Robby]

I found the funtion in question...

   Private Function ReadExcelData() As String(,)
       Dim arr(,) As String
       Dim EXL As New Excel.Application()
       Try
           Dim WSheet As New Excel.Worksheet()
           WSheet = CType(EXL.Workbooks.Open(Application.StartupPath & _
	"\RegistrationsCourse\RegistrationCourses.xls").Worksheets.Item(1), Excel.Worksheet)
           EXL.Range("A1:D11").Select()
           Dim CData As Excel.Range
           CData = CType(EXL.Selection, Excel.Range)
           Dim iCol, iRow As Integer

           ReDim arr(11, 4)
           For iCol = 1 To 4
               For iRow = 1 To 11
                   arr(iRow, iCol) = CType(CData(iRow, iCol).value, String) '<<<< This line
               Next
           Next
       Catch ex As Exception
           MessageBox.Show(ex.Message)
       Finally
           EXL.Workbooks.Close()
           EXL = Nothing
       End Try
       Return arr
   End Function

[Volte]

Is CData() giving you intellisense when you do the '.' after it? Value

is not capitalized, which would lead me to believe it's attempting to

Access CData an an Object.

 

Try

arr(iRow, iCol) = CType(CType(CData(iRow, iCol), Excel.Range).value, String)

[Robby]

Hmm, I was sure that I tried that, no matter. IT WORKS :)

 

You da man Volte.

[Volte]

:D :)

 

Glad it worked for ya. :)

[Heiko]

My 2c:

 

Stay away from CStr, CInt etc., they are likely to crash on dbnull values, if I recall correctly.

 

We wrote our own custom converter (this one relies on CStr, though, but will chack for dbnull first)

[Volte]

You can use the Convert class in place of all of those functions,

and DirectCast in place of many CType calls. No need for CStr at

all.

[quwiltw]

Turn on Option Strict, always. It stops you doing bad things like mixing data types and not explicitly converting.

We just had this discussion in my office and I think Option Strict is annoying for one reason: you can't treat a derived class the same as a base class without casting. In my opinion, you should be able to manipulate derived classes using a reference to the base class in much the same way you would an interface.

[divil]

In what respect? If you have a variable declared as a base class then you absolutely should have to cast it if in one circumstance you know it's going to be an instance of a subclass instead. If it were going to be a subclass all the time, presumably it would be declared that way.

 

You can certainly manipulate a variable if it's declared as a base class just as flexibly as if it were declared as the subclass, only of course you won't have access to the subclass-specific members. If you call a method on it which has been overridden, the overriding method still gets called.

 

Maybe I misunderstood your argument?

[Nerseus]

Strict != Simpler Coding :)

 

I still prefer strict (the only way to go in C#). I used to get aggravated at not being able to use Enums as ints without casting, but I got over my issues and learned to do it the "right" way. Of course, "right" is a per-user setting (or per-office in some installations :))

 

-Nerseus

[quwiltw]

In what respect? If you have a variable declared as a base class then you absolutely should have to cast it if in one circumstance you know it's going to be an instance of a subclass instead.

abosutely? Why? If I have a derived class it'll always have the base classes methods available, so why should I have to cast it? It should work just like an Interface in my opinion, just like C++ and Java. Is this your personal preference or have you a situation that would break that I've just not experienced yet?

[divil]

It *does* work just like an interface in that scenario. As I said before, you don't have to cast it to run an overridden method on the base class.