[RESOLVED] [2005] Option Strict On and Late Binding

Hi!!

I have Option Strict On and this code:

vb Code:

Private Sub Bs_MouseEnter(ByVal sender As Object, ByVal e As System.EventArgs) Handles B1.MouseEnter, B2.MouseEnter, B3.MouseEnter, B4.MouseEnter, B5.MouseEnter
    sender.BackgroundImage = My.Resources.BHover
End Sub

And i get this error: "Option Strict On disallows late binding". I went searching how could i fix it. And the only thing i could find has to turn option strict off.

Is there anyway of fixing with out turning strict off?

If you want only for that page then place this in the top of the page

Code:

---

option Strict Off

---

If you want it for the whole project

Code:

---

To set Option Strict in the integrated development environment (IDE)

On the Tools menu, choose Options.

Open the Projects and Solutions node.

Choose VB Defaults.

Modify the Option Strict setting.

---

directcast sender into whatever type it's supposed to be.

As you have it there, it is still boxed in an object.

dana - no, bad. Turning "strict off" is sloppy coding no matter how you cut it.

Hi Sevenhallo,
Here we develop application which does automation of
Winword Documents.For that here our employees has so many
version of MS Office.For getting the default version of Winword
I normallly use LateBinding.Is it Bad

The only bad thing would be to turn Option Strict Off.

Hack is totally right.

Thks a lot sevenhalo, for the tip to use directcast. It worked.

Now i ran into a similar problem:

vb Code:

Dim Helms(3), Armors(4), Pants(4), Gloves(4), Boots(4), SAS(3), SM(2), BCB(1), Shields(2), Wings(4), SSO(4), Misc(7), Tabelas(11) As String
Dim Array(11) As Array
Helms(0) = "Dk_Helms"
Helms(1) = "Dw_Helms"
Helms(2) = "Elf_Helms"
Helms(3) = "Dl_Helms"
Tabelas(0) = "BI_Helms"
Array(0) = Helms
Armors(0) = "Dk_Armors"
Armors(1) = "Dw_Armors"
Armors(2) = "Elf_Armors"
Armors(3) = "Dl_Armors"
Armors(4) = "Mg_Armors"
Tabelas(1) = "BI_Armors"
Array(1) = Armors
...
'This line is after a nested loop
Dim CmdSelect As New OleDb.OleDbCommand("SELECT * FROM " & Array(Actual)(TabActual).ToString, MuShop.ClassAndItems)

I get the same error were: "Array(Actual)(TabActual).ToString" but since its a jagged array i cant figure out how to solve this.

I think what dana is saying is that they do a lot of office automation apps which in many cases require late binding and therefor option strict needs to be off since option strict disallows late binding. Normally you can reference a specific office version and use early binding, but if your app needs to target various versions of office, then you can't set a specific version reference, you have to use late binding.

One thing to note is that option strict can be set at the project level, but also at the module level, so it would be possible to have option strict ON for the project, but turn it off in certain modules where you need to use late binding. That way your entire project doesn't suffer from not getting the option strict syntax errors.

i fixed with CType.

To be honest, that code gives me a headache.

You're working in an OOP language. Why are you not taking advantage of it? Divide things out into custom objects, for instance...

Code:

---

    Private col As New Generic.List(Of IThings)

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        col.Add(New Thing1)
        col.Add(New Thing2)
    End Sub

    Private Interface IThings
        ReadOnly Property Name() As String
    End Interface
    Private Class Thing1 : Implements IThings
        Public ReadOnly Property Name() As String Implements IThings.Name
            Get
                Return "Thing1"
            End Get
        End Property
    End Class
    Private Class Thing2 : Implements IThings
        Public ReadOnly Property Name() As String Implements IThings.Name
            Get
                Return "Thing2"
            End Get
        End Property
    End Class

---

I have 2 things (Thing1 and Thing2). They both have Name in common. Now both Thing1 and Thing2 are "related" by IThings.

I need a collection of these IThings, so I made col. Anything that implements IThings can be added to col and I know they will all have a "Name" property. Thing1 might also have properties that Thing2 doesn't, but they both are IThings.

You can do this with your example. Take for instance Helm, Pants and Gloves. What do they all have in common? They're all armor. So now you need to have a class for each (helm, pants and gloves) and put together an interface for IArmor. Now what does all armor have? All armor has a name, it also has a type (sor instance, chainmail, leather studded, etc) and it probably has a condition (damaged, shiny, dirty, whatever).

The possibilities and vastness of what you can do with these is endless, but realize you're working with a language that offers and expects objects.

The issue with early binding is solved with the ability to box objects. After you identify which version of office you are working with, you have a different set of insturctions to follow.

Option Strict Off is never acceptable in my book.

i think my solution is faster and simples , maybe not so good but its good enought:

vb Code:

Dim CmdSelect As New OleDb.OleDbCommand("SELECT * FROM " & CType(Array(Actual), String())(TabActual).ToString, MuShop.ClassAndItems)

You would be wrong and forever stuck in the mindset of a linear programmer.

what u mean with mindset of a linear programmer, because i'm portuguese and i dont really understand that expression

I believe what he means is you are more or less approaching this the way someone would in a language that DOESN'T support all the object oriented features that VB.NET supports.

You are basically bypassing some of the fundamental concepts and abilities in the language and making your code more cumbersome and ultimately harder to maintain.

he is right i could use the example he gave and "use" the object oriented features, but in this case its not that big a deal. This project is small and simple. To do a class for each "thing" (helm, armor, gloves, pants, shields, etc) would be a waste of time and code. Because that part of the code is the only code that uses it (its about 15 lines of code).

I'm not saying you should change your code technique, I was just trying to let you know what he was getting at ;)

Changing your technique wouldn't just improve those 15 lines of code. It would improve your entire program. The immediate benefit will only be seen in those 15 lines, but using the objects and storing information wouldn't be the indexing disaster you're potentially facing.

Just a quick tip - take it or leave it.

Just wanted to add that Option Strict On and Late Binding is very possible. Use Reflection and your good to go.

This code is bad:

vb.net Code:

Dim Helms(3) As String
 
Helms(0) = "Dk_Helms"
Helms(1) = "Dw_Helms"
Helms(2) = "Elf_Helms"
Helms(3) = "Dl_Helms"

This code is good:

vb.net Code:

Public Enum Helm
    Dk
    Dw
    Elf
    Dl
End Enum

Now Helm is a type and each type of helm is a member of that type. Everywhere you want to use a helm you use the Helm type and you are limited to only valid Helm values. If you use strings for each type of helm then you can assign any string you want and the compiler will never point out your error, perhaps leading to your deployed application crashing.

Here is the entire code:

vb Code:

Dim Helms(3), Armors(4), Pants(4), Gloves(4), Boots(4), SAS(3), SM(2), BCB(1), Shields(2), Wings(4), SSO(4), Misc(7), Tabelas(11) As String
        Dim Array(11) As Array
        Helms(0) = "Dk_Helms"
        Helms(1) = "Dw_Helms"
        Helms(2) = "Elf_Helms"
        Helms(3) = "Dl_Helms"
        Tabelas(0) = "BI_Helms"
        Array(0) = Helms
        Armors(0) = "Dk_Armors"
        Armors(1) = "Dw_Armors"
        Armors(2) = "Elf_Armors"
        Armors(3) = "Dl_Armors"
        Armors(4) = "Mg_Armors"
        Tabelas(1) = "BI_Armors"
        Array(1) = Armors
        Pants(0) = "Dk_Pants"
        Pants(1) = "Dw_Pants"
        Pants(2) = "Elf_Pants"
        Pants(3) = "Dl_Pants"
        Pants(4) = "Mg_Pants"
        Tabelas(2) = "BI_Pants"
        Array(2) = Pants
        Gloves(0) = "Dk_Gloves"
        Gloves(1) = "Dw_Gloves"
        Gloves(2) = "Elf_Gloves"
        Gloves(3) = "Dl_Gloves"
        Gloves(4) = "Mg_Gloves"
        Tabelas(3) = "BI_Gloves"
        Array(3) = Gloves
        Boots(0) = "Dk_Boots"
        Boots(1) = "Dw_Boots"
        Boots(2) = "Elf_Boots"
        Boots(3) = "Dl_Boots"
        Boots(4) = "Mg_Boots"
        Tabelas(4) = "BI_Boots"
        Array(4) = Boots
        SAS(0) = "Dk_Swords"
        SAS(1) = "Dk_Axes"
        SAS(2) = "Dk_Spears"
        SAS(3) = "Mg_Swords"
        Tabelas(5) = "BI_Swords_Axes_Spears"
        Array(5) = SAS
        SM(0) = "Dk_Maces"
        SM(1) = "Elf_Maces"
        SM(2) = "Dl_Scepters"
        Tabelas(6) = "BI_Scepters_Maces"
        Array(6) = SM
        BCB(0) = "Elf_Bows"
        BCB(1) = "Elf_Crossbows"
        Tabelas(7) = "BI_Bows_Crossbows"
        Array(7) = BCB
        Shields(0) = "Dk_Shields"
        Shields(1) = "Dw_Shields"
        Shields(2) = "Elf_Shields"
        Tabelas(8) = "BI_Shields"
        Array(8) = Shields
        Wings(0) = "Dk_Wings"
        Wings(1) = "Dw_Wings"
        Wings(2) = "Elf_Wings"
        Wings(3) = "Mg_Wings"
        Wings(4) = "Dl_Wings"
        Tabelas(9) = "BI_Wings"
        Array(9) = Wings
        SSO(0) = "Dk_Skills"
        SSO(1) = "Dw_Spells"
        SSO(2) = "Elf_Orbs"
        SSO(3) = "Dl_Spells"
        SSO(4) = "Mg_Skills"
        Tabelas(10) = "BI_SSO"
        Array(10) = SSO
        Misc(0) = "Misc_Item_Bags"
        Misc(1) = "Misc_Potions"
        Misc(2) = "Misc_Pets"
        Misc(3) = "Misc_Jewels"
        Misc(4) = "Misc_Quest_Items"
        Misc(5) = "Misc_BC_DS"
        Misc(6) = "Misc_Rings_Pendents"
        Misc(7) = "Misc_Others"
        Tabelas(11) = "BI_Misc"
        Array(11) = Misc
        Try
            MuShop.ClassAndItems.Open()
            For Actual As Integer = 0 To Array.Length - 1
                For TabActual As Integer = 0 To Array(Actual).Length - 1
                    Dim CmdSelect As New OleDb.OleDbCommand("SELECT * FROM " & CType(Array(Actual), String())(TabActual).ToString, MuShop.ClassAndItems)
                    Dim Reader As OleDb.OleDbDataReader = CmdSelect.ExecuteReader
                    While Reader.Read
                        Dim CommandInsert As New OleDb.OleDbCommand("INSERT INTO " & Tabelas(Actual) & " ([Name], Category, [Number], [Level], [Level?], [Skill?], [Luck?], [Options?], Y, X, Path) VALUES (@Name, @Category, @Number, @Level, @PTLevel, @PTSkill, @PTLuck, @PTOptions, @Y, @X, @Path)", MuShop.ClassAndItems)
                        CommandInsert.Parameters.AddWithValue("@Name", Reader("Name"))
                        CommandInsert.Parameters.AddWithValue("@Category", Reader("Category"))
                        CommandInsert.Parameters.AddWithValue("@Number", Reader("Number"))
                        CommandInsert.Parameters.AddWithValue("@Level", Reader("Level"))
                        CommandInsert.Parameters.AddWithValue("@PTLevel", Reader("Level?"))
                        CommandInsert.Parameters.AddWithValue("@PTSkill", Reader("Skill?"))
                        CommandInsert.Parameters.AddWithValue("@PTLuck", Reader("Luck?"))
                        CommandInsert.Parameters.AddWithValue("@PTOptions", Reader("Options?"))
                        CommandInsert.Parameters.AddWithValue("@Y", Reader("Y"))
                        CommandInsert.Parameters.AddWithValue("@X", Reader("X"))
                        CommandInsert.Parameters.AddWithValue("@Path", Reader("Path"))
                        CommandInsert.ExecuteNonQuery()
                    End While
                    Reader.Close()
                Next
            Next
        Catch ex As Exception
             'some code
        Finally
            MuShop.ClassAndItems.Close()
        End Try

Dk_Helms, Dw_Helms, Elf_Helms, BI_Helms are table names from DB (Access).
Now can I still obtain the same result, using enumerations?

Hmmm... didn't notice they were table names. I assumed they were being used differently, and we all know what assuming does. You could still use enumerations and convert the values to strings but it's probably of no real benefit.

That said, I'm not quite sure, if you're hard-coding the table names anyway, why you need those arrays at all.

The code copies data from a set of tables to one table. To make clear he copies all the data from Dk_Helms, Dw_Helms, Elf_Helms, Dl_Helms and inserts this data into the BI_Helms. All the data from the armor tables and puts it in the BI_Armors. Etc
So i used 2 loops, the first one loops through the BI tables (BI_Helms, BI_Armors, etc) then the second loop loops through the tables from which retrieve the data (DK_Helms, Elf_Helms, DW_Helms, etc).
So he reads all from the Helms tables (because of the second loop) and adds all the data to the BI_Helms while he is reading from the helms Tables.
If I was to make a command to each table (for example a command to copy the data from Dk_Helms to BI_Helms, Dw_Helms to BI_Helms, etc) i would get a lot of commands and repeated code. So the 2 loops relate the Helms tables with the BI_Helm table, the Armor Tables with BI_Armor, and do all the copying correctly. And if i want to add more tables i just need to add them to the array.
That why the arrays.