今天有客户的程序编译不过,来找我们共同探讨一下。
背景如下:客户的程序本来是EVC开发的MFC程序,并且调用的动态库其中有一个是MFC的动态链接库。客户现在想换一个平台,并且顺应趋势准备用VS2005开发,就是这个平台的转化带来了问题,导致程序编译不过。
一、编译
首先从编译不过的原因入手,出问题的就是那个MFC动态链接库,而其他的非MFC动态链接库是非常正常的,编译提示MFC动态链接库链接失败,通过他们的代码可以看出是隐式调用,并且这种方式也非常好用跟静态库调用一样方便。从代码上来说没看出问题,于是看MFC动态链接库,百思不得其解,于是自己随便添加一个无参数的函数导出,结果调用完全OK,此时怀疑是参数的问题,客户的函数参数有两种类型:Double和CString,结果一个一个的试果然猜中是CString的问题,去网上搜原因,有人说是不可以,不知道为什么还望高手指点迷津 ,于是采取了惹不起还躲不起吗的策略,把CString用Char *代替,然后再实现函数里在用CString做转换。这苦了客户了,有n多个地方,呵呵,抱歉。不过后来的方式带来了福音。。。
二、测试
编译完了之后,测试结果令人大失所望,只要调用MFC动态库中的东西就Game Over,什么也不会给你响应,调试会出现那句烦人的“。。。管道的另一端无程序在运行”,顾名思义是程序没起来,郁闷。。。,没办法程序给你个冷屁股,你必须得热脸相应,否则会有第二个第三个冷屁股,呵呵。最终决定自己建立个MFC的库试试,在建智能设备的MFC动态库的时候有三种,我用的默认的第二种,我也试过第一种,我觉得他们两个的唯一区别是,第一个在建完工程后,项目 属性 常规中是在共享DLL中使用MFC ,而第二种是在静态库中使用MFC,第三种不知道有什么区别,但是感觉第三种跟非MFC动态库很像,有DLLMain(),呵呵,不知道分析的是否正确,供各位大侠指正 。最终我是用的第二种方式即默认的方式建立,建完写个小函数一试果然一样,都是不能执行,奇怪,当然用的隐式调用,最后无奈用了显示调用,结果OK了,怪了怪了。
我再重新试一下客户的,结果显示也不行,能打开界面,但是点一个按钮调用MFC动态库中的函数时,要么打不开,要么调用DLL错误。最终对比发现也就是项目 属性 常规中的MFC的调用方式不同,把它改为静态调用MFC,果然好了。真搞不懂。。。
最终用显示调用,试了下CString作为参数,好了,无语。。。
另外调用MFC动态链接库的应用程序如果是MFC编写的也必须在项目属性常规中改成在静态库中使用MFC,否则会出现该死的“无法启动程序“”。管道的另一端上无任何进程”
总结:建立MFC动态库,建立默认的即带静态链接MFC的规则DLL,如果你没有在引用的函数前加任何的导出符号,就用.def文件导出,然后调用的时候用显示调用并且调用程序也必须是静态库中使用MFC,方法如下:
CString name=_T("ddd");
typedef void (WINAPI * TESTDLL)(CString name);
HINSTANCE hmod;
hmod = ::LoadLibrary(L"//NandFlash//xx.dll");
if(hmod==NULL)
{
MessageBox(L"ddd",L"dd",0);
}
TESTDLL lpproc;
lpproc = (TESTDLL)GetProcAddress(hmod,L"ShowDialog");
if(lpproc!=(TESTDLL)NULL)
(*lpproc)(name);
FreeLibrary(hmod);