According to MSDN documentation, the DllMain function is "an optional entry point into a dynamic-link library (DLL)." [http://msdn.microsoft.com/library/default.asp url=/library/en-us/dllproc/base/dllmain.asp]. Therefore a DLL does not seem to need the DllMain function.
"The wizard isn't creating the DLLMain entry point in the cpp file"
But what does the wizard add in the cpp file Are you sure you are using the DLL wizard
"but the calling program (in VB) still is able to call the dll function"
Do you mean that you are calling DllMain from VB explicitly ! You should not do this, it's the system's job to do it.
The cpp file is as follows:
// q.cpp : Defines the initialization routines for the DLL.
//
#include "stdafx.h"
#include "q.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
//
// Note!
//
// If this DLL is dynamically linked against the MFC
// DLLs, any functions exported from this DLL which
// call into MFC must have the AFX_MANAGE_STATE macro
// added at the very beginning of the function.
//
// For example:
//
// extern "C" BOOL PASCAL EXPORT ExportedFunction()
// {
// AFX_MANAGE_STATE(AfxGetStaticModuleState());
// // normal function body here
// }
//
// It is very important that this macro appear in each
// function, prior to any calls into MFC. This means that
// it must appear as the first statement within the
// function, even before any object variable declarations
// as their constructors may generate calls into the MFC
// DLL.
//
// Please see MFC Technical Notes 33 and 58 for additional
// details.
//
/////////////////////////////////////////////////////////////////////////////
// CQApp
BEGIN_MESSAGE_MAP(CQApp, CWinApp)
//{{AFX_MSG_MAP(CQApp)
// NOTE - the ClassWizard will add and remove mapping macros here.
// DO NOT EDIT what you see in these blocks of generated code!
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
/////////////////////////////////////////////////////////////////////////////
// CQApp construction
CQApp::CQApp()
{
// TODO: add construction code here,
// Place all significant initialization in InitInstance
}
/////////////////////////////////////////////////////////////////////////////
// The one and only CQApp object
CQApp theApp;
int CQApp::summer(int num1, int num2)
{
}
Yes, I am definately using the wizard. No, I am not calling the DLLMain function from VB, just the summer function. It works fine without the DLLMain in cpp file and without the _stdcall decorations on the function declarations, but I am not sure if this is acceptable in the long run. I am told by another programmer, and various websites that you need them. I got onother version to work the other day, with the DLLMain function in the cpp file and it did have the _stdcall decoration on it, but the summer function declaration did not have the _stdcall decoration on it. This is more like what I expected to work, but not quite, without the decorations on both functions.
Ah, the return of the summer function
This is a MFC DLL. It does not need DllMain, DllMain is provided by MFC.
And you say that you can call summer from VB !! I have no idea how come that it works. summer function here is a member of a class and for various reasons (calling convention is thiscall and not stdcall or cdecl and the name of the function is decorated) you cannot call this (easily) from any other language than C++.
And what version of Visual Studio are you using This does not look like what VS 2005 generates.
In fact yes. I'm not much of a VB user (be it VB6 or VBA or VB.NET) but as far as I know in VB6 and VBA Integer is 16 bit, not 32 like in VB.NET so I was wrong in the other thread. You need to use Long on the VB part, not Integer. On the C/C++ you can use long or int, it does not matter because both are 32 bit in size.
So in the end the VB part shoud look like this:
Private Declare Function summer Lib "D:\Projects\Tests\Forums\geob\debug\geob.dll" (ByVal num1 As Long, ByVal num2 As Long) As Long
and for the C++ part do the following:
Create a new DLL (Win32, not MFC) and delete everything from the cpp file except the #include "stdafx.h" line if you have one. After that add this to the cpp file (after the #include "stdafx.h" line):
long
__stdcall summer(long a, long b) // I'm using long to be consistent with the VB part but int should also work{
long result;
result = a + b;
return result;
}
One more step for the C++ project, add a .def file with the same name as the project (probably geob.def) and put the following lines in that file:
LIBRARY geob
EXPORTS
summer
This is not much different from the answer you got in the other thread except that I'm trying to keep things simple about the cpp file, no DllMain, no exported classes or variables, it contains only the function that you need. I'd merge these 2 threads but last time I tried this the result was kind of messy so I'll let them be.