Option Strict

[YYZ]

After reading many messages in this group, it seems that the preferred
setting for this is ON. Okay, I did that in my project (first with
..Net -- long time VB6 developer) and now a bunch of problems have
cropped up. Most are easy to solve with using an explicit type cast
cType(whatever, whatever type), but some aren't.

Situation 1: I've got code that tries to get the itemkey of the
selected item in a combobox.
cmbDecCBrwrM1.SelectedItem.ItemKey

That worked before, but now, "Option Strict On disallows late binding"
-- well, I'm not sure how to get the item key of the selected item,
because now selecteditem only has the "GetType" default method in its
intellisense. I'm not sure what I could type this to to get an itemkey
property...

Situation 2: I've created a collection class (stolen, actually, from
Microsoft I believe) that allows me to have a strongly typed
colleciton. I solved a couple of problems by overloading the remove
method to handle an integer or a string, and also Type-ing some other
things...but here is what is left:

Public ReadOnly Property NewEnum() As stdole.IUnknown
Get
'this property allows you to enumerate
'this collection with the For...Each syntax
NewEnum = mCol.GetEnumerator
End Get
End Property

Error is on the NewEnum = mCol.GetEnumerator line, and the error is
that it can't convert iUnknown to iEnumerator. I think I solved this
one by changing the declaration of the proc to ... As
System.Collections.IEnumerator But I don't know if that messed
everything up because I can't run the project to test it because of the
other errors.

Finally, is using Option Strict On really that good of an idea if all
you do is do some explicit CType functions? I mean, if, while running
your program, it blows up on something without Option Strict On, it
wouldn't help to have Option Strict on and just CType that same line,
because you are still "going out on a limb" and trusting that the
object you are CTyping really IS the type of object you want...right?

Any pointers would be appreciated.

Matt

[Marina]

Is the ItemKey property declared as Object? In which case you have to use
CType again to cast it to the appropriate type.

Option Strict on is a good idea. If you were using C#, it would be as if
this was on all the time, since C# has no concept of Option Strict. Option
Strict forces you to think about what are the types of the objects you are
dealing with, and catches many many errors at compile time instead of at run
time.

Yes, a CType can fail and you can still have a runtime error. But, when you
are writing that CType code, it really forces you to think about the type of
the object you are CType'ing. So odds are you are not going to try to CType
it to the wrong type.

Additionally, having Option Strict On should result in more efficient code.
The compiler can know what types your objects are, and emit more efficient
IL. Whereas the other way, all that takes place at runtime, and the runtime
is trying to figure out what type everything is, and if this method really
exists, etc.

To me, turning it off, is just being lazy. I'm sure there are situations
where it is useful or necessary, but that would be a pretty rare scenario.

"YYZ" <ma********@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

After reading many messages in this group, it seems that the preferred
setting for this is ON. Okay, I did that in my project (first with
.Net -- long time VB6 developer) and now a bunch of problems have
cropped up. Most are easy to solve with using an explicit type cast
cType(whatever, whatever type), but some aren't.

Situation 1: I've got code that tries to get the itemkey of the
selected item in a combobox.
cmbDecCBrwrM1.SelectedItem.ItemKey

That worked before, but now, "Option Strict On disallows late binding"
-- well, I'm not sure how to get the item key of the selected item,
because now selecteditem only has the "GetType" default method in its
intellisense. I'm not sure what I could type this to to get an itemkey
property...

Situation 2: I've created a collection class (stolen, actually, from
Microsoft I believe) that allows me to have a strongly typed
colleciton. I solved a couple of problems by overloading the remove
method to handle an integer or a string, and also Type-ing some other
things...but here is what is left:

Public ReadOnly Property NewEnum() As stdole.IUnknown
Get
'this property allows you to enumerate
'this collection with the For...Each syntax
NewEnum = mCol.GetEnumerator
End Get
End Property

Error is on the NewEnum = mCol.GetEnumerator line, and the error is
that it can't convert iUnknown to iEnumerator. I think I solved this
one by changing the declaration of the proc to ... As
System.Collections.IEnumerator But I don't know if that messed
everything up because I can't run the project to test it because of the
other errors.

Finally, is using Option Strict On really that good of an idea if all
you do is do some explicit CType functions? I mean, if, while running
your program, it blows up on something without Option Strict On, it
wouldn't help to have Option Strict on and just CType that same line,
because you are still "going out on a limb" and trusting that the
object you are CTyping really IS the type of object you want...right?

Any pointers would be appreciated.

Matt

[YYZ]

Okay, thanks for that. I hadn't looked @ this code in a while and had
just assumed that I was adding strings into the combobox. Actually,
they were my own clsListItem objects, and those did have an ItemKey
property -- so using cType again worked perfectly -- thanks for that!

Finally, thanks for the reason WHY to use Option Strict. That really
helped. I didn't realize it would end up being faster, which in .Net
is always a good thing.

I feel better about using CType, which for a little while there was
making me feel like I was just hiding a bunch of problems instead of
fixing them!

I honestly think this will help me figure out how to use .Net better
now because I'll have to learn the object hierarchy better.

Matt

[Marina]

You bring up a good point regarding object hierarchy.

When you cast to the correct type, you will also end up getting VS.NET to
show you the intellisense for that object. Not only will this help you code
faster, you will learn a lot more about the object and what it can do by
seeing its properties/methods.

"YYZ" <ma********@gmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...

Okay, thanks for that. I hadn't looked @ this code in a while and had
just assumed that I was adding strings into the combobox. Actually,
they were my own clsListItem objects, and those did have an ItemKey
property -- so using cType again worked perfectly -- thanks for that!

Finally, thanks for the reason WHY to use Option Strict. That really
helped. I didn't realize it would end up being faster, which in .Net
is always a good thing.

I feel better about using CType, which for a little while there was
making me feel like I was just hiding a bunch of problems instead of
fixing them!

I honestly think this will help me figure out how to use .Net better
now because I'll have to learn the object hierarchy better.

Matt

[Armin Zingler]

"YYZ" <ma********@gmail.com> schrieb

After reading many messages in this group, it seems that the
preferred setting for this is ON. Okay, I did that in my project
(first with .Net -- long time VB6 developer) and now a bunch of
problems have cropped up. Most are easy to solve with using an
explicit type cast cType(whatever, whatever type), but some aren't.

Situation 1: I've got code that tries to get the itemkey of the
selected item in a combobox.
cmbDecCBrwrM1.SelectedItem.ItemKey

That worked before, but now, "Option Strict On disallows late
binding" -- well, I'm not sure how to get the item key of the
selected item, because now selecteditem only has the "GetType"
default method in its intellisense. I'm not sure what I could type
this to to get an itemkey property...
What is the type of the item in the combobox?

Situation 2: I've created a collection class (stolen, actually, from
Microsoft I believe) that allows me to have a strongly typed
colleciton. I solved a couple of problems by overloading the remove
method to handle an integer or a string, and also Type-ing some other
things...but here is what is left:

Public ReadOnly Property NewEnum() As stdole.IUnknown
Get
'this property allows you to enumerate
'this collection with the For...Each syntax
NewEnum = mCol.GetEnumerator
End Get
End Property

Error is on the NewEnum = mCol.GetEnumerator line, and the error is
that it can't convert iUnknown to iEnumerator. I think I solved this
one by changing the declaration of the proc to ... As
System.Collections.IEnumerator But I don't know if that messed
everything up because I can't run the project to test it because of the
other errors.
That's ok. The usual way is implementing IEnumerable and return
mCol.GetEnumerator in GetEnumerator, while "GetEnumerator Implements
IEnumerable.GetEnumerator".

Finally, is using Option Strict On really that good of an idea if all
you do is do some explicit CType functions? I mean, if, while running
your program, it blows up on something without Option Strict On, it
wouldn't help to have Option Strict on and just CType that same line,
because you are still "going out on a limb" and trusting that the
object you are CTyping really IS the type of object you want...right?

Option Strict Off: runtime error can occur due to wrong explicit casts,
/and/ due to wrong implicit casts or other late binding errors.

Option Strict On: runtime errors can occur due to wrong explicit cast, /not/
due to wrong implicit casts or other late binding errors.
Why enable additional risks by turning Option Strict Off? In a professional
development environment this is usually considered unacceptable - apart from
cases where late binding is recommended, like when being able to use
different office versions for automation - because a main goal is to prevent
and detect faults ASAP.
Armin

[YYZ]

> What is the type of the item in the combobox?

My bad -- still stuck in VB6 -- I coded this combobox a while ago, and
really forgot that all list items have to be an object...so I thought
that ItemKey was a built-in property of the selecteditem property, and
couldn't understand where it went when I turned Option Explicit on.

Situation 2: I've created a collection class (stolen, actually, from
Microsoft I believe) that allows me to have a strongly typed
colleciton. I solved a couple of problems by overloading the remove
method to handle an integer or a string, and also Type-ing some other
things...but here is what is left:

Public ReadOnly Property NewEnum() As stdole.IUnknown
Get
'this property allows you to enumerate
'this collection with the For...Each syntax
NewEnum = mCol.GetEnumerator
End Get
End Property

Error is on the NewEnum = mCol.GetEnumerator line, and the error is
that it can't convert iUnknown to iEnumerator. I think I solved this
one by changing the declaration of the proc to ... As
System.Collections.IEnumerator But I don't know if that messed
everything up because I can't run the project to test it because of the
other errors.

That's ok. The usual way is implementing IEnumerable and return
mCol.GetEnumerator in GetEnumerator, while "GetEnumerator Implements
IEnumerable.GetEnumerator".

Glad to know it will work, and it did after I fixed the other errors
thanks to you and to Marina. However, I honestly never had to learn
the interfaces for com objects, so IEnumberable and IUknown and the
like are still greek to me. Is the way that I'm doing it "incorrect"?
Is there a better way to do it?

Finally, is using Option Strict On really that good of an idea if all
you do is do some explicit CType functions? I mean, if, while running
your program, it blows up on something without Option Strict On, it
wouldn't help to have Option Strict on and just CType that same line,
because you are still "going out on a limb" and trusting that the
object you are CTyping really IS the type of object you want...right?

Option Strict Off: runtime error can occur due to wrong explicit casts,
/and/ due to wrong implicit casts or other late binding errors.

Option Strict On: runtime errors can occur due to wrong explicit cast, /not/
due to wrong implicit casts or other late binding errors.

That makes sense.
Why enable additional risks by turning Option Strict Off? In a professional
No reason at all. I think it was turned off when I got .Net, or maybe
I did while still learning the IDE.
development environment this is usually considered unacceptable - apart from
I am coding in a vacuum, unfortunatley. Just left a larger developer
shop and I'm the lone programmer among a bunch of sales guys doing a
new system for them with a new tool. All the tribal knowledge that
most people get from other co-workers isn't available to me, hence why
I'm spending a couple hours a day on the groups reading old posts.
cases where late binding is recommended, like when being able to use
different office versions for automation - because a main goal is to prevent
and detect faults ASAP.

Absolutely. I'll keep it on from now on. It only took me an hour or
two with the help I received from the group to convert my project to
using Option Strict. Glad I did it NOW instead of in 6 months when I
have 40000 lines of code to go through.

Matt

[Dennis]

In case you don't know it, Directcast is faster than Ctype but the object
type must be the same as what you cast it to in DirectCast since it won't
convert, i.e.,

dim s as Object = "1234"
Ctype(s,integer) will work, Directcast(s,integer) won't.
--
Dennis in Houston
"YYZ" wrote:

Okay, thanks for that. I hadn't looked @ this code in a while and had
just assumed that I was adding strings into the combobox. Actually,
they were my own clsListItem objects, and those did have an ItemKey
property -- so using cType again worked perfectly -- thanks for that!

Finally, thanks for the reason WHY to use Option Strict. That really
helped. I didn't realize it would end up being faster, which in .Net
is always a good thing.

I feel better about using CType, which for a little while there was
making me feel like I was just hiding a bunch of problems instead of
fixing them!

I honestly think this will help me figure out how to use .Net better
now because I'll have to learn the object hierarchy better.

Matt

[Cor Ligthert [MVP]]

YYZ,

As small addition to the fine texts you have got.

Try to avoid using the raw type object. (by instance for passing)

I see that often done by VB6 programmers, try to use the real type.

With that there is much less casting/converting needed.

Cor

[Armin Zingler]

"YYZ" <ma********@gmail.com> schrieb

Had machine problems yesterday, so I couldn't answer earlier.

That's ok. The usual way is implementing IEnumerable and return
mCol.GetEnumerator in GetEnumerator, while "GetEnumerator
Implements IEnumerable.GetEnumerator".
Glad to know it will work, and it did after I fixed the other errors
thanks to you and to Marina. However, I honestly never had to learn
the interfaces for com objects, so IEnumberable and IUknown and the
like are still greek to me. Is the way that I'm doing it
"incorrect"? Is there a better way to do it?

Pardon, better than...?

development environment this is usually considered unacceptable -
apart from

I am coding in a vacuum, unfortunatley. Just left a larger
developer shop and I'm the lone programmer among a bunch of sales
guys

I'm a lone warrior, too (and I'm also the sales guy). :) (one hint:
*never* do what sales guys say ("just this little tiny additional
feature...") ;-) - but you probably know this already)
doing a new system for them with a new tool. All the tribal
knowledge that most people get from other co-workers isn't available
to me, hence why I'm spending a couple hours a day on the groups
reading old posts.

I'm also learning a lot from here. Sometimes by asking, and much more by
answering. Well, I've learned where the table of contents is... ;)

cases where late binding is recommended, like when being able to
use different office versions for automation - because a main goal
is to prevent and detect faults ASAP.

Absolutely. I'll keep it on from now on. It only took me an hour
or two with the help I received from the group to convert my project
to using Option Strict. Glad I did it NOW instead of in 6 months
when I have 40000 lines of code to go through.

Good decision. :-)
Armin

[YYZ]

Interesting. I'll try to figure out when I can use that and when I
can't...

Matt