Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Visual Basic and ActiveX? 33

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

Visual Basic and ActiveX? More

Visual Basic and ActiveX?

Comments Filter:
  • Caveat emptor: I'm a game programmer, and I don't use Visual Basic. I don't know about or understand the ActiveX limitation, so I could very well be suggesting overly complex solutions...

    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)...
    • 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).

  • VB DLL's areActiveX Only... (Score:3, Informative)

    by pmorrison ( 513514 ) on Thursday December 27, 2001 @10:17AM (#2754784)
    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.
    • Disclaimer: I don't use VB and I'm too lazy to look it up right now, but maybe I can clarify a few things...

      Most COM/ActiveX objects are easy to use: simply CoCreate the object and start calling the methods. You may have to QI for the appropriate interfaces, but that's no sweat. It's barely harder than using a regular C++ object.

      If the object only supports the IDispatch interface, which is probably the case for VB, then things get a little more tedious. Packaging up DISPPARAMS and calling Invoke() is a PITA. Fortunately there are helper classes. MFC has COleDispatchDriver, and the MFC dependencies can be removed, such as with XYDispDriver [codeproject.com].

      #import will also build the wrappers for you if you have a typelib.

      • Fortunately, if an object supports IDispatch, then you can import it into Visual C++ using class wizard. It handles the wrapping for you by making a nice class that exposes every function with all of the obvious parameters (which must be rebuilt through class wizard if you break binary compatibility).

        Caveat 1: Class wizard will not import any public enums from your VB classes into C++.

        If you want a standard DLL, you can use the C++ class as a wrapper for the ActiveX DLL.

        Caveat 2: You now have the overhead of a DLL that has the overhead of an ActiveX DLL, but if that saves your architecture, it is probably worth it.

        You can write a little script to automate the process of creating wrapper class DLLs if you are really tricky.

        NOTE: I wasn't that tricky. I used Rational Rose and built a template file in Rose that did a wrapper DLL for me. Rose is a very expensive tool if all you are using it for is to generate wrapper classes.

  • 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...
  • 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.

    • Re:Wait till Feb. 2002 (Score:2, Informative)

      by jogbra ( 108487 )
      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.

  • RE: Visual Basic and ActiveX? (Score:3, Informative)

    by dolphinuser ( 211295 ) on Thursday December 27, 2001 @11:33AM (#2755020)
    VB only creates COM/ActiveX DLLs.

    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 problem... (Score:4, Informative)

    by Da VinMan ( 7669 ) on Thursday December 27, 2001 @01:56PM (#2755454)
    ...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:

    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 .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.

    That's all I can think of right now. I hope it helps.

  • A shameless, offtopic plug (Score:5, Informative)

    by fm6 ( 162816 ) on Thursday December 27, 2001 @02:46PM (#2755664) Homepage Journal
    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 [borland.com] (which uses an OO variant of Pascal [employees.org] in place of VB's pseudo-OO BASIC [digitalcentury.com]) 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 [borland.com], 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.

    • This is a plug! This is spam! You're supposed to mod me down! Oh well.
    • > It probably makes a big difference that component architecture is an afterthought in MS's toolset, but a basic part of the Delphi design.

      I agree that Delphi is a better language for some things, but I'll have to strongly disagree with you on this statement.
      Component architecture is far beyond being an afterthought for MS.
      To put it mildly, Windows is heavily depended on components. To the point where it wouldn't boot without COM. Certainly wouldn't be able to function.
      New APIs are now more and more COM interfaces rather than C-style functions. (DirectX is all about COM, frex)
      And MS provides some excellent tools (in that, as in pretty much any other development area) for creating compnents.

      What kludge are you talking about, for crying out loud?
      • Component architecture is far beyond being an afterthought for MS. To put it mildly, Windows is heavily depended on components. To the point where it wouldn't boot without COM.
        I wasn't talking about the OS! The topic at hand is development tools. Obviously COM technology is all over the place in Windows. The question is, what's the easiest way to put it there.

        I should confess that I've never built an ActiveX container app using Visual C++. (I did write a couple of small ActiveX components that way, but that was a while ago.) People who have tell me that it is not easy -- the process is complex and poorly documented. With Borland C++Builder, it's little more than a drag-and-drop operation. That's my basis for comparison.

        • It's wrong.
          You should try building an ActiveX in VC6.0
          The whole thing is (mostly) wizard-generated boiler-proof code (ATL) which gives you all you can want (and more).
          This clears up everything that is related to COM itself and leave you dealing with the bussiness logic you are trying to implement, rather than getting distracted in the details.
          • You sound like you're talking about using VC++ and ATL to build the ActiveX components themselves. I agree it's not that hard, even with MFC. (Though building ActiveX components with Delphi or C++Builder is easier.) I'm talking about using an ActiveX component within a C++ container application.

            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) [microsoft.com] is fairly involved. In C++Builder it's a simple drag-and-drop operation.

  • ActiveX == COM (Score:2, Interesting)

    by euphline ( 308359 )
    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.
    http://home.t-online.de/home/Martin.Both/vborb.htm l [t-online.de]
    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.
    • If we're tossing things we haven't looked at yet into the ring, the Kompany [thekompany.com] has some sort of tech for this that is portable between DOS, Windows, Linux and Mac, and is *not* tied to Qt or KDE (which is what the Kompany usually uses). It's a self referential name ?INO, which stands for ?INO is not Ole (where ? = some letter I can't remember), but offers quite a few nice features (keep in mind that I've briefly glanced at the Changelog, and that's about it). It's being used in one of the main products or projects, so it's pretty stable.

      --
      Evan

  • 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
  • I haven't done COM in a few years, so I may be out of date.

    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 ...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.

    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?
  • 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.

Slashdot Top Deals

Your own mileage may vary.

Close