Slashdot Mirror

← Back to Stories (view on slashdot.org)

Visual Basic and ActiveX?

Posted by Cliff on from the does-one-need-the-other dept.

Dylbert asks: "Putting aside my gripes about using Microsoft products in the workplace (or anywhere, for that matter), I was wondering if any Slashdot users have found ways to overcome the forced use of ActiveX when creating DLLs in Visual Basic. Because my work uses a few seperate programming languages to write code in, the use of ActiveX would mean we will have to convert all our existing code to the same ActiveX architecture which I believe is unnecessary. Any suggestions?"

1 of 33 comments (clear)

  1. A shameless, offtopic plug by fm6 · · Score: 5, Informative
    OK, the question you're asking is "How do I avoid using ActiveX?" But it suits my purposes to pretend that you're asking, "How can I live with with ActiveX." And who knows, maybe that's the real question.

    My motivation is that I work for Borland. ActiveX isn't my area, but there's a certain feeling (not only by people who work here!) that our support for ActiveX is better than MS's.

    A lot of people prefer Delphi (which uses an OO variant of Pascal in place of VB's pseudo-OO BASIC) because Delphi produces smaller, faster, and more reliable object files. The differences in syntax take some getting use to, but people who have used both much prefer Delphi for creating ActiveX components. It probably makes a big difference that component architecture is an afterthought in MS's toolset, but a basic part of the Delphi design.

    Then for C++ diehards, there's C++Builder, which co-exists with Delphi a lot better than Visual C++ co-exists with VB. And there are those who think it supports ActiveX, MFC, and ATL better than VC does. Most of all, C++Builder treats ActiveX components as components, not some weird entity you have to kludge into your app.

    Perhaps I can make up for such shameless spamming by suggesting that your real problem is a resistence to component-based programming. This is a powerful programming model, and VB's success is based on its semi-support for it. Perhaps converting your existing code base to this model would improve productivity enough to pay for the conversion.