I've been working with these controls for about 2 weeks now and first off they look great.
But i have just worked out that the controls and objects only have
dispatch interfaces defined, so they can only be late bound. So the VB
compiler cannot check for correctness when working with these controls.
There is no way i can compile and ship quality code if the compiler
is unable to guarantee code will at least execute. This is one of the things
compilers do, make sure the code will run. If there is a way to get the
vb compiler to check against disp interfaces please let me know.
I discovered this because i was getting runtime errors that should have
been detected by the compiler. So I used ole view from visual studio 6
to look at the type lib for the report and command bar controls. It
shows that all interfaces are defined as dispinterface .
If I examine the type lib for the ocx from the competitor control i used to use their
interfaces are defined as "interface", derived from IDispatch and marked
as "dual" so they can be used by late and early binding. So the
compiler can ensure the code will work.
This is a serious floor in the controls. I need to be able to deliver a
product used by hundreds of people in a broadcast media company where
reliability is all important. But I now fear i cannot deliver that
level of quality using your controls without a large additional testing
effort to ensure that all lines of code that use your controls are
executed. This is normally what the compiler does, using your controls
i need to get a person to do.
These controls look great and do some amazing things but the
poor documentation means it takes longer than it should to work out how they
work. And the lack of compile time
checking puts them in the same league as old fashion ASP for shipping quality product.
Can someone please let me know if the proposed release at the end of
January will include dual interfaces so the compiler can check the code.
thanks
aaron
|