|
netsharq wrote: ...why should i include ddaoxxd.lib in settings?
I never indicated you had to change your project's settings. I simply stated that you need to link with the appropriate DAO library. Whether you do that implicitly or explicitly is up to you.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Sorry, if i have hurt you..
I mean, i tried using _dbdao.h
i gave the path which is available in c:\program files\common files\msvisualstudio\include\_dbdao.h
but still i get this linker error
|
|
|
|
|
netsharq wrote: Sorry, if i have hurt you..
I don't recall being hurt.
You seem to be very confused on the basics of C programming. #include is a preprocessor directive that pulls in the contents of the specified file, _dbdao.h in this case, as if those contents had appeared in the source program at the point where the directive appears. This has nothing to do with linking.
You can link in one of two ways: implicit (compile-time) or explicit (run-time). With implicit linking, you link to an import library (.LIB file). The OS loads the DLL when the executable using it is loaded. The executable calls the DLL’s exported functions just as if the functions were contained within the executable. With explicit linking, the executable using the DLL must call LoadLibrary() and GetProcAddress() to access the DLL’s exported functions. The executable must call the exported functions through a function pointer.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
OK.Agreed,
but when you explictly link using AfxLoadLibrary,
we have to mention the header file where the declarations of the functions available in DLL are present in our source program.
Can we explicitly link without including the header file.
|
|
|
|
|
netsharq wrote: but when you explictly link using AfxLoadLibrary,
we have to mention the header file where the declarations of the functions available in DLL are present in our source program.
Not normally.
netsharq wrote: Can we explicitly link without including the header file.
Yes, and this is usually the reason for doing so (when a .h file is not available).
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
i tried to typecast the following i am getting error
typedef CdbEngine* (*PFNCreateA1)();
|
|
|
|
|
netsharq wrote: i am getting error
Which is?
netsharq wrote: typedef CdbEngine* (*PFNCreateA1)();
My guess is it should be:
typedef CdbEngine* (PFNCreateA1)();
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
I have in a CDialog class:
protected:
afx_msg void OnDestroy();
afx_msg void OnSize(UINT nType, int cx, int cy);
DECLARE_MESSAGE_MAP()
};
Then I have
void CTargetInfo::OnSize(UINT nType, int cx, int cy)
{
CDialog::OnSize(nType, cx, cy);
CRect cRect;
GetClientRect(&cRect);
if( NULL != m_listTgtInfo.GetSafeHwnd() )
{
m_listTgtInfo.MoveWindow(10, 10, cRect.Width()-15, cRect.Height() - 15);
}
}
but code never steps into this function even as I resize the CDialog in debug mode (breakpoint in function)
Am I missing some crucial step?
thanks,
sb
|
|
|
|
|
didn't you forget something like :
BEGIN_MESSAGE_MAP(CTargetInfo, CDialog)
ON_WM_SIZE()
END_MESSAGE_MAP()
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Indeed I did.
Thanks for the pointer.
|
|
|
|
|
I finally finished my project. So I thought I would test it on a neighbours computers, just in case. And it doesn't work :'(
I have narrowed the problem down to the importing and initialising of an activeX dll. But I can't find out why it works on my machine and not on another (with identical configuration).
Here is the code:
_clsXLPtr xls;
try {
CoInitialize(NULL);
xls.CreateInstance(__uuidof(clsXL));
xls->Visible(&vis);
The CreateInstance call is failing, but why?
|
|
|
|
|
If the DLL registered on your neighbors computer?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
|
|
|
|
|
waldermort wrote: xls.CreateInstance(__uuidof(clsXL)); // failing
Had you bothered to check the return value of CreateInstance() , you would have likely seen it was -2147221164, which indicates a class has not yet been registered. You'll need to use regsvr32 for this.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Thanks for the quick replies. Could you possibly explain why this works on my machine and not on others?
|
|
|
|
|
waldermort wrote: Could you possibly explain why this works on my machine and not on others?
Because of lack of registration.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Now I'm getting error's when trying to register. "ExCom.dll was loaded, but the DllInstall entry point was not found.".
|
|
|
|
|
Which indicates DllInstall() does not exist or has not been (properly) exported.
See here for more.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
WinExec("regsvr32 ExCom.dll",SW_SHOW);
"DllRegisterServer in ExCom.dll Succeeded".
Yet CreateInstance() is still failing on the other machine.
|
|
|
|
|
waldermort wrote: Yet CreateInstance() is still failing on the other machine.
What is it returning?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
-2147221164.
#import "ExCom.dll" no_namespace
WinExec("regsvr32 /s ExCom.dll",SW_SHOW);
try {
CoInitialize(NULL);
long foo = xls.CreateInstance(__uuidof(clsXL));
char *val = new char [100];
ltoa(foo,val,10);
MessageBox(NULL,val,0,0);
delete val;
xls->Visible(&vis);
} catch(_com_error &e) {
data.error = e.Description();
MessageBox(NULL,_com_util::ConvertBSTRToString(data.error),0,0);
}
I'm sorry about this, and I thank you for your kind replies.
|
|
|
|
|
I don't know how or why but it's seems to be working now. I deleted every file including the dll's and libs apart from the source files and completely rebuilt everything. And hey presto it works. I have a feeling that choosing 'clean' and 'rebuild all' from the menu wasn't producing the same result.
Maybe it's time I got a newer version of my compiler.
Thanks for your help.
|
|
|
|
|
I suspect it was that call to WinExec() . You should be able to turn the error on and off by simply unregistering the DLL (from a command prompt not WinExec() ).
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
waldermort wrote:
WinExec("regsvr32 ExCom.dll",SW_SHOW);
Why are you doing this programmatically? Do it once from the command prompt.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
This would go into the installer.
I was sending the file to my neighbour so he can test it for me, therefore I wanted to make it as simple as possible for him.
|
|
|
|
|
But it is potentially a timing problem where your program is trying to use the DLL before it has been registered. By registering at a command prompt, or through an actual install-type program, you've eliminated this possibility.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|