|
I inserted a line #include "secondDll.h" in the first dll. It caused the link error. This worked for calling a dll from .exe file.
#include <stdio.h>
#include <cmath>
#include "secondDll.h"
hli
|
|
|
|
|
Sorry, my code is
#include <stdio.h>
#include <cmath>
#include "dbInsert\DBArea.h"
hli
|
|
|
|
|
The previous posts do not display the #include values. They should be: #include <stdio.h> and #include <cmath>
hli
|
|
|
|
|
that is the problem. when it is linking, with other lib file, it is seeing there are two dll main functions(its own and others).
Try using loadlibray and GetProcAddress it will resolve your problem.
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
Many thanks. May I have a brief sample code for that.
hli
|
|
|
|
|
Or just include the header files for the classes you intend to use instead of the main header for the DLL.
You don't have to use LoadLibrary/GetProcAddress to call methods from one DLL in another. You just have to make sure that both DLLs are built with the same threading library and you properly include header files and link with the libs.
As a side note, make sure you don't create cross-dependencies between DLLs when doing this ... they are NOT fun to work with.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Hi,
Thank both of you first. I am wondering that in my case I have to use LoadLibrary/GetProcAddress. I am attaching the example below which caused the link error. Please let me know if I can use Zac's suggestion instead of LoadLibrary/GetProcAddress approach.
A head file in the second dll project is named as DBArea.h. There are several classes in the second dll that are defined in dataWork.h. So dataWork.h is included in the DBArea.h file. The first dll is designed to use member functions "rowInsert" and "getConnection" in class DBArea.
#include "dataWork.h"
#if !defined(AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_)
#define AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_
#if _MSC_VER >> 1000
#pragma once
#endif // _MSC_VER >> 1000
class DBArea
{
public:
__declspec(dllexport) int rowInsert(char *SQLStr);
__declspec(dllexport) int GetConnection(char *connectionStr);
__declspec(dllexport) DBArea();
__declspec(dllexport) virtual ~DBArea();
protected:
CADORecordset m_pRs;
CADODatabase m_pDb;
};
#endif // !defined(AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_)
hli
|
|
|
|
|
For starters, when you include this file in the DLL that will be calling into it, the __declspec(dllexport) should be changed to __declspec(dllimport). Typically, this is done by defining a macro that checks to see if the file is being compiled as a DLL or as an application; however, since both will be DLLs, you may need to define another macro that doesn't depend on that to check to see which is should use.
Second, you should __declspec the class, not individual methods. You will have a hard time calling these methods because they are exported, but they are part of a class that isn't exported.
Just FYI, you almost never "have" to use LoadLibrary/GetProcAddress. The only time you have to do so is when your requirements call for late-binding DLLs, and even then, there are some other options.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Thank you Zac,
However, I failed to change dllexport to dllimport with a warning: "warning C4273: 'GetConnection' : inconsistent dll linkage. dllexport assumed". So, I changed it back. Did I miss something?
I simplified my case by exporting one function only. Because I am a new VC++ programmer and don't know how to create a macro, I hope you could give me a further suggestion. This project is so import to me. I would very much appreciate if I could get assistance here.
Below is a brief detail. Many thanks.
-----------------------------------
Error message:
nafxcwd.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in firstDll.obj
nafxcwd.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in firstDll.obj; second definition ignored
Creating library Debug/firstDll.lib and object Debug/firstDll.exp
In the second dll (made by MFC), I declared an export function in the header file, DBArea.h.
__declspec(dllexport) int GetConnection(char *connectionStr);
In the first dll (made by stardard C++), I defined FIRSTDLL_EXPORTS in the firstDll.cpp
#include "stdafx.h"
#define FIRSTDLL_EXPORTS /////////////
#include "firstDll.h" ////////////////
I created a class, callSecondDll, and a member function callDll(), which was accessed from firstDll class. The header file DBArea.h (in second dll) was included in the file callSecondDll.cpp
#include "stdafx.h"
#include "callSecondDll.h"
#include "DBArea.h" //////////////////
...............
int callSecondDll::callDll()
{
................
int n = GetConnection(myString);
return 0;
}
hli
|
|
|
|
|
Here is a simplified case of some old code I use to have to work with:
Macro defined for both Dll's
#ifdef __IMPORT_LIBRARY__<br />
#define EXTENDED_MODULE __declspec(dllimport)<br />
#else<br />
#define EXTENDED_MODULE __declspec(dllexport)<br />
#endif // __IMPORT_LIBRARY__
In Dll 1:
EXTENDED_MODULE void myfunction();
In the project settings for DLL2, add __IMPORT_LIBRARY__ to the preprocesser definitions. (NOTE: DO NOT use EXTENDED_MODULE for defining your methods in DLL2 otherwise nothing will be exported from DLL2 -- either create another macro name with the same style build, or use MFC's AFX_EXT_CLASS macro). Included the dll1.h header file where you need to call myFunction(), and add the lib file that is created for the dll to Dll2's link settings.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Let me try it. I will let you know if I need further assistance. Thank you very much.
hli
|
|
|
|
|
Hey guys,
When I'm running my debugger, I am getting a strange problem that keeps occuring. If I click run, the debugger follow throughs the whole source code and gives me an access violation of 0xC0000005. If I do a run to cursor, then I am forced by the debugger to provide the location of CRT0.C. The program runs fine without the debugger, just doesnt output the correct results. Would anyone know the reason for that?
Thanks
Robbie
|
|
|
|
|
capricious_001 wrote: If I click run...
Is that F5 or Ctrl+F5?
capricious_001 wrote: The program runs fine...just doesnt output the correct results.
How can a program run fine but not output the correct results?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
Is that F5 or Ctrl+F5?
With F5 I get an access violation. CTRL+F5 produces no run-time error and the program is executed.
DavidCrow wrote: How can a program run fine but not output the correct results?
It does not fail at run-time, meaning there are no run-time errors, but the results it outputs, say to console, is not whats expected.
|
|
|
|
|
|
SaRath C wrote: check for missing resources.
What do you mean? Resources in the preprocesser directives? The debuggers resources? Or somewhere else?
|
|
|
|
|
there's might have entries in the DoDataExchange function of deleted resources!
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
SaRath C wrote: there's might have entries in the DoDataExchange function of deleted resources!
Hey Sarath,
Do have any good tuts on how to use it, because msdn doesnt provide a good reference and I tried googling it, and the usage of it is vague.
I'm not using MFC, so if there is an alternate way of retreiving the desired output from this function would you know how?
|
|
|
|
|
Hi all,
I created a map file like this :
HANDLE hMap=CreateFileMapping(hFile, NULL, _dwProtect, 0, _dwSize, _strMapName);
but now I need to increase its size and create a new view on it!! does someone know how to to that the right way??
Thank you so much 
|
|
|
|
|
hatemtalbi wrote: but now I need to...create a new view on it!!
To start over, can't you just call UnmapViewOfFile() followed by CloseHandle()?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Yes, I did all that. But when I call mapViewOfFile() the secon time the whole size of the maapped file !!!
|
|
|
|
|
hatemtalbi wrote: But when I call mapViewOfFile() the secon time the whole size of the maapped file !!!
Your sentence is incomplete. What happens when you call MapViewOfFile() the second time?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
for example when I resize the file from 4KB to 8KB, I expect that MapViewOfFile() return a buffer size of 8KB but I get only 4KB !!!
|
|
|
|
|
This is to be expected - that is how file-mapping objects work.
You should use the ZwResizeSection native-API if you want to resize the file-mapping object. Lots of info on google about this.
James
http://www.catch22.net
|
|
|
|
|
Sorry, I typed ZwResizeSection in google but I didn't get any results !!
please could you check the word orthography
thank you
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
