> Thanks,
> Henryk

> Thanks,
> Henryk

> i actually had the recent occasion to have to go the other way around
> because of things that VB can do that C# can't - at least not without
either
> a lot of ugly casting or writing a wrapper class that would then have to
be
> updated with future releases of a component.
> we needed to work with a 3rd party (ibm) com component written with vb in
> mind which almost exclusively uses generic objects rather than properly
> typed objects - this was a real pita in c# but a no brainer in vb.  ie.
most
> ( but not all ) objects could be declared and instantiated using their
> proper types , however any methods / properties that return references to
> any of these objects always does so as 'object' rather than the proper
type
> and there are a number of critical & common objects that could only be
> accessed via methods of other objects and for which a cast to the proper
> type was illegal according to the c# compiler !!!.
> imagine a string class where every method returns another string except
that
> the returned strings are always objects rather than strings and you get
the
> idea of how much casting is then inolved.

> what should be simple thing :
>   xString x = new xString("some text");
>   xString y = x.SubStr(1,1).Upper();

> ends up more like :
>   xString y = ( (xString) ( (xString) x.SubStr(1,1) ).Upper() ) );

> because xString::SubStr() & xString::Upper() both return the type object
> rather than the documented type xString

> if there is a simple solution to this 'object' problem in c# , feel free
to
> educate me , it would be appreciated.

> > Any idea ?
> > I need this to move a VB-programmer to C#.
> > I haven't found an article on MSDN.

> > Thanks,
> > Henryk

> "Get better components" is the one which comes to mind, I'm afraid. If
> you use daft libraries which don't tell you what they return properly,
> you just *won't* be able to do safe compile-time type checking
> (obviously!).

> And that is a daft answer that just evades the issue. What if this component
> is the only, or best, one that meets the client's requirements, even though
> it's design may be less than perfect? What should the client do? Rewrite it
> from scratch? Perhaps they cannot afford to do that. Spend 2 years waiting
> for another company to provide a better component? Perhaps they cannot
> afford to do that either.

> > > if there is a simple solution to this 'object' problem in c# , feel
free
> to
> > > educate me , it would be appreciated.

> > "Get better components" is the one which comes to mind, I'm afraid. If
> > you use daft libraries which don't tell you what they return properly,
> > you just *won't* be able to do safe compile-time type checking
> > (obviously!).

> And that is a daft answer that just evades the issue. What if this
component
> is the only, or best, one that meets the client's requirements, even
though
> it's design may be less than perfect? What should the client do? Rewrite
it
> from scratch? Perhaps they cannot afford to do that. Spend 2 years waiting
> for another company to provide a better component? Perhaps they cannot
> afford to do that either.

> Unsurprisingly, I disagree. I fully accept that it won't always be
> possible to find a replacement, but it's still worth *trying* - and also
> complaining to the vendor that what they're providing just isn't
> suitable for anything other than use within VB. Of course, if they're
> only claiming to support it on VB, then it's the company's fault for
> moving away from VB. It would be like me complaining to Jakarta that
> they're not providing a C# interface for Tomcat...

> > a very real 'problem' with components in the real world is that you are
> > often stuck with what you are given.

> And if you just accept that with no complains, nothing will change.

> > you hit it right on the head - there is only one component available and
we
> > don't have any choice other than to use it.  re-writing is out of the
> > question as it is not ours to re-write.  this component has been around
for
> > many years and has been re-released/upgraded a number of times, the most
> > recent being within the last year , it seems that the vendor ( currently
> > ibm ) just does not see this as an issue.

> I would argue that they will *continue* not to see it as an issue while
> people still buy it regardless. Can I ask whether or not you've actually
> complained about this yet?

> > one point that is missed here is that this type of design is not
necessarily
> > 'daft'.  there are a huge number of components out there that do this
very
> > thing for the simple reason that they were written with VBesque
languages in
> > mind where this situation is not an issue.

> That explanation just won't wash in the .NET era, where cross-language
> support is vital. Component vendors who supply components which will
> only work with one language will hopefully be overtaken by those who
> design components with cross-language support in mind. It doesn't sound
> like it would be terribly difficult for IBM to do, in this case, either
> - you just need to make enough of a fuss for them to see that it's an
> issue for you.

> Depending on the type of component, you might also consider the wrapper
> idea I mentioned in another post. I had to write something similar
> recently. I was using a library which *should* have worked in both VB
> and VC++, but mysteriously failed in VC++. Even the vendor's sample app
> failed (which did make me wonder somewhat about their QA department...)
> In the end I had to write a small VB COM wrapper where each method just
> called the "real" one. I then wrote most of the app in VC++ as normal.
> Ugly, but it worked. Whether or not something similar is appropriate
> depends very much on the case in point though.

> --

> http://www.pobox.com/~skeet/

> what really won't wash in the .NET era is assuming that there is a .NET era.
> it will a very long time before all traces of 'old' technologies disappear.
> i agree .NET is great , but it is not everything.  assuming that you will
> always be able to operate in 100% complete islolation is naive to an
> extreme.

> so in the end my original point was valid and your solution was very naive
> as obviously you yourself have run into the same situation and decided to
> make do with a 'daft' component by simply switching langauges.

> That depends on the situation, of course. Sometimes it will be the best
> solution. Sometimes it won't. As I asked Kevin, what do you do when the
> library decides to reboot your machine randomly? Is that enough of an
> issue to make you look elsewhere for a different library? In *some*
> circumstances, that may be a slighter issue than being forced to use a
> particular language to interface with a library.

> > And that is a daft answer that just evades the issue. What if this
component
> > is the only, or best, one that meets the client's requirements, even
though
> > it's design may be less than perfect? What should the client do? Rewrite
it
> > from scratch? Perhaps they cannot afford to do that. Spend 2 years
waiting
> > for another company to provide a better component? Perhaps they cannot
> > afford to do that either.

> Then you have a problem. You can take one of three unpalatable routes:

> o Write C# code which is full of casts
> o Rewrite the library
> o Use VB against the company policy (or whatever else is saying to use
>   C#)

> One potential alternative which *might* be more palatable would be to
> write some a .NET component which wrapped the library up in a better
> API. That may or may not be possible depending on the component.

> Seriously though - is "get a better library" always a daft answer? What
> about other flaws, such as: "It reboots the machine once a month,
> unpredictably"? All of the rest of your criteria might still be met. I
> don't think that looking for a better library is a daft answer, to be
> honest.