Get Ready to Unleash the Power of UCanCode .NET

UCanCode Software focuses on general application software development. We provide complete solution for developers. No matter you want to develop a simple database workflow application, or an large flow/diagram based system, our product will provide a complete solution for you. Our product had been used by hundreds of top companies around the world!

"100% source code provided! Free you from not daring to use components because of unable to master the key technology of components!"

Q: How to build a resource-only DLL?
A: On the 'Project Menu', select 'Settings'. Select the 'Link' tab of the 'Project Settings' dialog, then in the 'Project Options' box, add the '/NOENTRY' option. '/NOENTRY' prevents the linker from linking a reference to '_main' into the DLL; this option is required to create a resource-only DLL.

1. Add the .RC file to an empty DLL project.

2. Build the DLL.

No MFC is involved in this process. If your application needs to access the resources from the DLL, it is easier to use the Win API functions to access these resources than MFC. You need to call 'LoadLibrary()' with the name of resource DLL, and then the Windows API 'FindResource()'/'LoadResource()'/'LoadBitmap()' etc. functions to find and load the resource.

The reason why the API functions are easier to manage than MFC is that the API functions require that you give it the handle to the loaded DLL (the return value when you called 'LoadLibrary()'), while the MFC functions do not have this parameter. Requiring the DLL handle allows much more flexibility, since you can have multiple resource DLL's loaded, and you don't have to fool around with the 'AfxSetResourceHandle()' function (for example, compare the MFC 'LoadBitmap()' with the Windows API 'LoadBitmap()'). When you call 'AfxSetResourceHandle()', you are globally making a change to which resources your application is going to reference, which I do not like, so I don't ever use that function.

If you want to use the MFC functions after using the API function to load your bitmap, just call the 'Attach()' method, and then the 'Detach()' method.

Visual C++ DLL: How to build a DLL to be used from another programming language?

Q: How to build a DLL to be used from another programming language?

A: When you create a DLL with Visual C++, and you want to use the DLL with other languages, there are a few things that you should do (creating a DLL isn't just compiling code).

1. Make sure your exported functions are declared as extern "C". The reason for this is so that the C++ name mangling is not used on the exported function names.
   

2. Make sure your exported functions use '__stdcall' calling convention. The reason for this is that most other Window's languages assume the exported functions retrieve parameters starting from the rightmost parameter, and that the function called is responsible for stack cleanup on return. By default C and C++ functions assume '__cdecl' calling convention.
   You won't know when this problem exists until you call the exported function in your Delphi program. You did not declare
   your function as '__stdcall', so your [insert porgramming language, other than C/C++, here] program would have crashed as soon as you called the function.
   

3. Use '__declspec(dllexport)'. This is so that the function can be exported (of course).
   

4. Use a module definition file (.def-file). This removes the "@x" decoration that appears at the end of VC++ exported function names, where "x" is the total number of bytes in the arguments passed to the function. When the user of the DLL is using another language, the programmer would rather call "tempest", not "tempest@4". Yes, many of these other languages have an "aliasing" features so that you can access the function by a different name, but it is a pain in the neck. Just use a .def-file to remove the additional decoration and you won't have to do anything else.

Note: Just exporting the name does *not* remove all the decoration - you must follow steps a) *and* d). A lot think that you only need to do a) and b) and c). This is if you plan on using the DLL in only Visual C++. If you leave the module definition file out of these steps, you will get what you're seeing now -- an exported name that is not what you expect.

If you do a search on CodeGuru, your question has been ucancode.neted many times in various ways, and the reason for the problem is almost always that step d) was left out.
Here is a sample of a module-definition fie (DEF file).

The LIBRARY command must match the name of your DLL. So if your DLL is named YOURDLL.DLL, the LIBRARY command is followed by YOURDLL.

The DESCRIPTION is any description you feel is appropriate for your DLL. The actual description is preceeded by a single quote (').

The EXPORTS lists the functions that you exported, along with an ordinal number. It doesn't matter what ordinal numbers you use, so long as you maintain different numbers for each function, and you shouldn't change the ordinal numbers when you create an upgraded version of your DLL -- persons preferring to use ordinal numbers to call your functions will get angry.