Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The disadvantage of the second approach is that you have to add some extra information to the class definition, and you have to add some extra project defines to each and every APP (or hand coded project) that uses the class DLL, and if you get any of this wrong your app will almost surely GPF. The advantage is that if you make a change to the class that doesn't affect any of is existing exports, you don't need to recompile all the apps that use that class. You just drop in the new DLL.

An ABC example

Here's a typical ABC class header:

...

Info

I've only touched on two uses of the LINK and DLL attributes - linking classes into a DLL, and using classes exported from such a DLL. There are other possibilities such as linking in classes in an OBJ or LIB, but these aren't very common. I strongly suspect that almost everyone who reuses classes does so by exporting from one DLL and then using those exported classes in other DLLs and EXEs. This is the scenario I'm addressing.

A better way

The DCL uses what I like to think is a much better way. It's certainly a lot simpler and less error-prone. 

...

Now there's just one equate that needs to be added to a project, and it only needs to be added if you actually want to compile the classes; otherwise it's assumed that you're using the classes as compiled into the DCL DLL. 

The easiest way

It's still a hassle typing in LINK and DLL attributes when creating a class for the first time. Or it used to be. I now use John Hickey's brilliant ClarionLive! Class Creator, part of the ClarionLive utilities pack. Just set up a set of INC and CLW base class files, and Clive (as I like to call him) will do the rest. Fantastic! 

Summary

For years I've found the DLL and LINK attributes to be a huge pain, and on more than one occasion I've either forgotten to add them or added them incorrectly, with predictably ugly results.

...