October 22, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

The COM Course - Part 3

  • November 19, 2002
  • By Karl Moore
  • Send Email »
  • More Articles »

So far on our journey, we've explored using classes in ActiveX DLLs. That's all fine and dandy, but no COM course would be complete without a brief look at the naughty little brother of DLLs ActiveX EXEs.

Now when it comes down to actually coding an ActiveX EXE project, there's very little difference between the two. Actually, there's no difference. You just fire up Visual Basic, choose 'ActiveX EXE' instead of 'ActiveX DLL' - then start creating your classes as usual.

So why should I even bother mentioning it, I hear you ask? Well, even though you use them in the same way, they work slightly differently.

The first difference involves something called 'process space'. When any Windows program starts, be it Microsoft Word or Oliver Reed's Multimedia Guide to 20th Century Beer, it has a process space. This is like desk space to your program. It's a chunk of computer memory it uses to 'run' and 'work on' and stuff.

Now when you use ActiveX DLLs in your project, the DLL runs inside the process space of the program using it whereas an ActiveX EXE works outside of that space. In other words, an ActiveX EXE has a 'desk' of its own. But what use is that? Let's ponder over the advantages and disadvantages...

For a start, if your ActiveX DLL goes wild and crashes, the program using it is usually set alight and dramatically burnt to smithereens, often complemented by the devilish Blue Screen of Death. That doesn't happen with EXEs. They have their own 'process space' so if they crash, only their own desk is burned. Of course, your program then has to graciously recover having 'lost' that bit.

'Course, in the real world, nothing ever really crashes anyway (hah, who said technology journalists were 'out of touch'?)

Another difference is the load speed. Because a DLL loads within the existing process space, it's can nip up pretty quickly. On the other hand, EXEs take a few extra nanoseconds due to them having to quickly knock up their own process space and so on.

But is there any real difference? Hmm, yes. Two 'real to life' differences.

First off, if you're using certain Windows tools to complement your ActiveX components, you may be forced to use a particular type of project. For example, if you're using MTS, you have to create DLLs. If you're using DCOM, you have to use EXEs. Don't worry if you aren't sure about any of these acronyms right now they're just tools for power users, widgets to bring in when you want COM to work 'remotely'. We'll have tutorials on such technologies coming later on VB-World.

And now enter stage the second real difference.

I once needed to create an application that continuously checked whether something had happened in a database. I first tried doing this with some sort of 'timer' in my program. Every ten minutes or so, everything fired up and the database would be checked. The problem was that when this happened, all regular code in the same process space had to stop and wait for my database check.

Now one really great thing about ActiveX EXEs is that they have their own process space. So if you add a timer to do something there, it buzzes away in its own process space and doesn't affect the program using it. That means I could add an ActiveX EXE to the above project which, whilst checking the database, doesn't freeze the nuts off the program using it. Then if a message needs to be returned to the using program, it can be sent back by raising an event.

Top Tip: This method of running code 'away from' the regular program and raising events to talk to the using application is called asynchronous processing. You can use asynchronous processing when you need to either perform periodic e-mail or database checks, or perhaps when you need to run a long report or calculate big time statistics.

Surprisingly enough, everything we've covered on this page can be summarised in just one sentence. And here it is:

  • ActiveX DLLs run 'in-process' and ActiveX EXEs run 'out-of-process'

Dazzling, isn't it?

Top Tip: For more information on which type of ActiveX project is best suited to your project, check out this Microsoft document

In the next section, we'll knock up our very own ActiveX EXE and acquire the little-known skill of 'asynchronous processing'. After that, we'll uncover a wonderful little thing called instancing (which I accidentally-on-purpose forgot to tell you about earlier), plus find out how you can take your mega COM knowledge to the next level.

So izzy wizzy, let's get busy!

<Reader: Groan >





Page 3 of 9



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel