Slashdot Mirror
Visual Basic and ActiveX?
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?"
Um, the only type of dll that vb 5.0/6.0 can create is a COM/ActiveX/Automation Server DLL (whatever it is being called this week). There is no way to create other types in vb and there isn't a check box to turn it off.
If you need generic dlls make them ActiveX Dlls & talk to them via COM or use a different language (such as delphi).
There's no way to build a non-ActiveX DLL with VB. This is considered a feature rather than a bug by MS. I've used VB nearly every day for the last four years (I'm not necessarily proud of that!). Once we did a project where a non-ActiveX component called our VB ActiveX DLL, it was a pain and a hassle to build the necessary wrappers for calling in to the ActiveX world. If you email me, I might be able to dig up an example. If performance isn't enormously critical, you might try the UNIX idea of building VB modules that do what you want based on command line parms and calling them that way. It's old-fashioned, but it will be quicker to develop and much less heartache, trust me please.
You state that your project will be using different languages, in that case, simply use C for C-style DLLs.
To use those C-style DLLs, simply write Declare statements in VB, just as if you had been making Win32 API calls.
John
The drops of water don't know themselves to be a river; and yet the river flows.
...as I understand it is that you have a bunch of code in VB already that you need to leverage from other languages which don't support ActiveX (or do they?). Some of this may be redundant to what's been suggested already, but here's my list of ideas:
.NET. Language interoperability is real strength there. However, adopting .NET in your project may be untenable, so YMMV big time on that one. On the other hand, VS.NET and .NET are still in RC status, so considered yourself warned.
1. Just use the VB ActiveX DLL from the other languages using those languages' COM abilities. This makes the most sense, but can it be done in your situation? This has the disadvantage of complicating all the other components of your system that have to talk to the VB components.
2. Build a wrapper around the VB components (probably in C++) such that the other programs/DLLs access the wrapper via straight DLL calls and the wrapper itself talks COM to the VB component. This is not elegant and rates a big "yuck" from me, but it is possible. I don't have any examples for you, but you might find one out on MSDN. Related to the above disadvantage, any component that uses the VB component(s) via this method won't really be complicated by that relationship anymore. On the other hand, you now own a DLL which will contain some very gross code (IMO anyway) because of memory management and COM.
3. Port the VB code to another language that can compile to straight DLLs. IIRC, you can easily port VB to PowerBasic and compile PB down to straight DLLs, which are then accessible to anything. I've never tried this, but my understanding is that it is possible and not too esoteric either. Once you've done this, you can use the PB compiled DLL from VB with the use of the VB Declare statement. Another option along this line would be to port the VB to C/C++. Obviously, that's much more costly, but you could give yourself a nice performance boost and maybe even platform portability to boot.
4. You probably can't do this for several reasons, but I would examine if the languages in question are covered by
That's all I can think of right now. I hope it helps.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
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.
VB.NET can use COM(Active X) components. There is a COM interop layer so old com objects can call VB.NET through COM and VB.NET stuff can call old COM objects.
http://www.desaware.com/SpyWorksL2.htm