how to stop late binding

[Boni]

Dear All,
I would like to allow a conversion of types (i.e. double to int)
but prohibit a late binding (because obfuscators don't support this).

i.e.

obj as object
obj=yyy
obj.AAA <-----//Compiler should complaint

Is it possible to configure the compiler this way?
Thanks
Boni

 

[Herfried K. Wagner [MVP]]

I would like to allow a conversion of types (i.e. double to int)
but prohibit a late binding (because obfuscators don't support this).

Enable 'Option Strict On'. However, this will require explicit conversion
of double to integer too (i = CInt(d)').

 

[Boni]

Or at least make number of reported errors on strict on bigger.
So that compiler don't stop complaining after 100 errors (this way I can at
least review all of them and check if it is a bug or a feature)

 

[Boni]

Hallo Herfried,

Enable 'Option Strict On'. However, this will require explicit conversion
of double to integer too (i = CInt(d)').

I hate this. Even in C++ it is possible to convert double to int
implicitely. Is it absolutely unflexible? I need only to switch off late
binding. I have a huge project and I would like to avoid unnessesory
changes.Or at lease go thru project and look myself. But compiler stops
complainig after 100-th bug. Can I switch this off?

 

[Boni]

BTW it is not only int to double. Even dynamic casts of derived classes must
be done explicitely then.

 

[Jay B. Harlow [MVP - Outlook]]

Boni,
As Herfried suggests. Option Strict On.

If Option Strict On is too strict, then you may try the using the "Project
Properties" in VB 2005 to selectively set the notification level (Error,
Warning, None) for late binding, implicit conversions, implicit type & a
number of other conditions...

However I find including Option Strict On in each .vb file to better explain
what that .vb file expects.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Dear All,
| I would like to allow a conversion of types (i.e. double to int)
| but prohibit a late binding (because obfuscators don't support this).
|
| i.e.
|
| obj as object
| obj=yyy
| obj.AAA <-----//Compiler should complaint
|
| Is it possible to configure the compiler this way?
| Thanks
| Boni
|
|

 

[Armin Zingler]

BTW it is not only int to double. Even dynamic casts of derived
classes must be done explicitely then.

IMO, if you want to cast, you should cast. It's safer to enable option
strict because otherwise you can write casts that you do not want, and that
lead to errors that take you more time than you safed before due to implicit
casts. I'd always go the safe way. Have the compiler help you as much as
possible by avoiding as many errors as possible. The option is for free -
the time you have to spend to find an error is not.


Armin

 

[Herfried K. Wagner [MVP]]

I hate this. Even in C++ it is possible to convert double to int
implicitely.

'Option Strict On' enforces explicit casts everywhere where a type
incompatibility could occur or where information would get lost when
casting.

Is it absolutely unflexible? I need only to switch off late binding. I
have a huge project and I would like to avoid unnessesory changes.Or at
lease go thru project and look myself. But compiler stops complainig after
100-th bug. Can I switch this off?

I do not think it's unflexible. You can turn on 'Option Strict On' on
per-file basis and add the necessary cast operators to the source code.

 

[Cor Ligthert [MVP]]

Boni,

I agree with you, there is not really in VBNet a kind of middle part that
shift automatically obvious type converting and non obvious type converting.

I would find it a great advance if the IDE would autocomplete the obvious
type converting itself.

As long as this is not, than I prefer as the others wrote the Option Strict
on.

I have it forever as preference and in the very seldom case I don't use I
set in top of my program Option Strict Off. I was hoping that this version
was already setting it standard to Option Strict On. Maybe the next does.

Just my thought,

Cor