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?"
If some queer format is your only choice for DLLs, and your application wouldn't suffer much for lack of shared memory, don't even target DLLs. So long as you can create a stand-alone app, there's nothing to stop you from creating a free-standing application which uses standard Windows message passing to communicate with other applications.
Alternatively, there's nothing to stop one DLL from loading another. If you still need a DLL, you could make a thunking DLL which loads the ActiveX DLL and handles whatever nastiness the ActiveX DLL brings with it, providing a cleaner interface to the user. This should take a supporting Visual C programmer virtually no time at all.
You are not forced to use ActiveX in VB. It's a DLL compile option. If that gives you trouble, I seriously recommend getting a book on VB (it will at least explain the IDE and it's various options)...
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.
If your point involves making sure you can glue several languages together, why not just use one of the other languages for the dll? Visual Basic itself is going to mean a performance hit over and above dll usage, and not using ActiveX limits your choice of references (including no ado) and pretty much eliminates the visual controls.
In the meantime, using ActiveX actually opens up a bunch of options, because an ActiveX dll, once created, can be called from within VB, VC++, ASP...
-------------------------------------------------
charlton heston is more of a man than yo
With Visual Basic.NET, ActiveX is being quietly put on the shelf to collect dust with other dated technologies. AFAIK, VB.NET (or any other .NET language) will NOT support the creation or use of (without COM work arounds) ActiveX components. The cross-language features of .NET will provide precisely what you need.
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.
I don't quite understand your problem here. When you build an ActiveX DLL in VB, you are creating a COM DLL that can be used by anything that supports COM. I've even called ActiveX DLLs created by VB from _PERL_!
ActiveX DLLs created in VB look no different to programs than any other DLL created by any other language that creates COM-compatible DLLs.
What _doesn't_ work?
-jbn
This is funny, I just ran across this today and bookmarked it to try someday.m l
http://home.t-online.de/home/Martin.Both/vborb.ht
You can write CORBA servers and clients, call EJB's whatever, looks like. Open Source (guy doesn't even offer a binary download). Looks cool, but I haven't even looked at it.
DO NOT DISTURB THE SE
This is a plug! This is spam! You're supposed to mod me down! Oh well.
I am by no means a great programmer (at least by /. standards), but I managed to get an old Fortran program talking to an VB ActiveX component via a wizard in Digital Visual Fortran. It does what I wanted it to do, but the code that was added, which looks like some sort of interface declaration, was completely cryptic to me.
YMMV
-"The early bird catches the worm, but the late bird sleeps the most"
I haven't done COM in a few years, so I may be out of date.
...forget the Interface but the one that returns more error information. If you want to call to a flat, non COM dll, you don't get error reporting. Your only choices there are Wrapping in the C layer and Wrapping in the VB Layer Create a COM component with the same interface. No, you cannot raise a WIN32 exception and expect VB will handle it. I tried.
I assume the problem you are having is the fact that for error reporting in VB, it expects an HRESULT and then a call to
How about a little more info about the limitations you are worried about. Are you going from VB to C/ADA/Pascal? And lookingto USE VB as Glue?
Open Source Identity Management: FreeIPA.org
Now that post was offtopic! Have you no shame?
http://www.desaware.com/SpyWorksL2.htm
ActiveX is just a super-enhanced COM object (basically, it supports a lot of standard interfaces, which allows you to do some neat stuff with any object).
But it's still COM, and COM is totally language blind.
I don't think that you'll find a programming language targeting win32 without some COM binding. It's a must for Win32 programming.
Granted, it may be a bit ugly to work with ActiveX via IDispatch on C (shudder!), but there are ways to go around it with wrappers.
--
Two witches watched two watches.
Which witch watched which watch?
As I said before, I don't have any experience with that myself. But users of Visual C++ tell me it's not very easy. I'm only a casual user of MFC, and my knowledge of ATL is superficial. But neither seems very good at using components. Certainly the Microsoft tutorial on the subject (click on Part 6) is fairly involved. In C++Builder it's a simple drag-and-drop operation.
"my work uses a few seperate programming languages to write code in"
.NET and Mono. KDE has a component based archietecture, I just can't remember it. Mozilla has its XPCOM/XPConnect.
ActiveX/OLE/COM's main purpose is to allow objects created in one compiler/language to be used by another at runtime.
CORBA is another solution. SOM is a solution IBM had on OS/2. Bonobo on GNOME is a great solution for Linux and other UNIX-like operating systems, but even the great guru of GNOME sees great potential in
What is wrong with component based programming?
ActiveX is the best solution for component based porgramming on the Win32 platform.
Ok... I modded up the article you point to in your sig. Now quityerbitchin. ;)
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!