|
Moujan wrote: If I offended anyone I am sorry.
I can't speak for others, but I would hardly get offended at someone for asking a homework question. I was simply pointing out to you what a better protocol would be.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
While it would be very easy to tell you the answer to your homework problem, it wouldn't help you much to do so. Instead, go to Bjarne's book (The C++ Programming Language) and use the index to look up "try-catch", "exceptions", and "exception handling".
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
|
|
|
|
|
Zac, you don't need to be rude. I explained it in my earlier respond.
Thanks, Moujan
|
|
|
|
|
Rude? What part of that response was rude?
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
|
|
|
|
|
1 is true
2 is usually true, however I think it's legal to goto out of a try block, in which case execution resumes at the target of the goto
3 is false - there's no such thing
4 cannot be determined. A function called in a try block may have thrown an exception, but contained a catch that caught and processed the exception.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
Thanks Mike for the explenation.
I still don't know when we use "try block" and why (this is not a homework question)! It is not in my assignments, so I don't know and I like to learn.
Thanks again,
Moujan
|
|
|
|
|
|
The answer is language dependent.
"Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
|
|
|
|
|
Hi,
Does anyone have experience on this issue. I tried to call a vc++ 6 FMC dll from a regular vc++6 dll. I got a link error "afxcw.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in usersec32.obj", where usersec32.obj is the calling object. It seems to me _DllMain is defined in both dll.
I am wondering whether it is possible to call a dll from a dll. If possible, what do I have missed?
Very appreciate if I get assistance. Thanks in advance.
hli
hli
|
|
|
|
|
Are using that header file or other dll for compilation? or loading using "GetProcAddress" ???
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
