Discussion: Option Strict and VB functions

Divil

Well-known member
Joined
Nov 17, 2002
Messages
2,748
Robby here...I had a hard time merging these threads, so Im 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 Robbys 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.
 
Last edited by a moderator:
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 :\
 
Actually the old one is Option Expicit, the new one is Option Strict.
Thats the important one, its a real must have.

I can say I found one instance where I was forced to turn it off, :(
Code:
CData being an Excel range...
arr(iRow, iCol) = CType(CData(iRow, iCol).value, String)
 
Would
Code:
arr(iRow, iCol) = Convert.ToString(CData(iRow, iCol).Value)
not work? I avoid any functions that you cant use in both C#
and VB.NET (CWhatever() functions, MsgBox(), Int(), etc).
 
Originally posted by VolteFace
Would
Code:
arr(iRow, iCol) = Convert.ToString(CData(iRow, iCol).Value)
not work? I avoid any functions that you cant 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?
 
im 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 whats 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. Im 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 ill 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.
 
Well, I am very strict about my personal coding standards, and in my
opinion, that is one that should be followed. Theres nothing wrong
with using those functions, but I dont. They might do the same
things when compiled, I dont know.
 
I got nothing against about your coding standards, they are yours :) . It was just intresting to me.
 
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#, its just the way like it.
 
I found the funtion in question...
Code:
    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
 
Is CData() giving you intellisense when you do the . after it? Value
is not capitalized, which would lead me to believe its attempting to
Access CData an an Object.

Try
Code:
arr(iRow, iCol) = CType(CType(CData(iRow, iCol), Excel.Range).value, String)
 
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)
 
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.
 
Back
Top