首先
dllhandle:=loadlibrary(...); //加载dll文件,成功
funcaddr:=getprocaddress(...); //获得函数地址,成功
WorkClass:=GetWorkClass(...); //调用函数成生类,成功
WorkClass.Work(...); //让类工作,成功
WorkClass.Free; //释放类,成功;
//!!!!!!!!!!!!!!!
Freelibrary(dllhandle); //释放dll,不成功,为什么??????
//!!!!!!!!!!!!!!!
有没有人遇到同样的情况呀?给小弟我一个解决的办法吧.谢谢先.
5 个解决方案
#1
不会吧?
应该可以的,自己在研究了
应该可以的,自己在研究了
#2
不要返回对象实例,返回接口!
我以前也经常遇到你的情况,使用接口后一点问题都没有了。
我以前也经常遇到你的情况,使用接口后一点问题都没有了。
#3
DLL的接口不要使用Delphi特有的东西,这样会出问题的
DLL是跨语言的:)
DLL是跨语言的:)
#4
根据个人的猜测。因为你的TWorkClass类在内存中有两个实现。一个存在于主程序中,一个存在于Dll中。你在Dll中创建类的实例调用了Dll中的那个实现的构造函数,最后释放的时候调用的其实是主程序中的析构函数,估计问题就出在这里。
至于为什么调用Work没有问题。大概是因为Work方法在两个实现中的偏移地址相同,而且大概没有跨模块的内存操作,所以不会出现异常。
作为中庸之道,你可以试着从Dll中导出一个专门用来施放对象的DeleteObj函数,把一个在Dll中创建的对象作为参数传给该函数,然后该函数直接调用obj.Free方法释放内存,这样一来调用的就是在Dll中那个类实现的析构,所以应该不会出问题。
没有测试过,你可以试一下。多导出一个函数不会太费事的。
至于为什么调用Work没有问题。大概是因为Work方法在两个实现中的偏移地址相同,而且大概没有跨模块的内存操作,所以不会出现异常。
作为中庸之道,你可以试着从Dll中导出一个专门用来施放对象的DeleteObj函数,把一个在Dll中创建的对象作为参数传给该函数,然后该函数直接调用obj.Free方法释放内存,这样一来调用的就是在Dll中那个类实现的析构,所以应该不会出问题。
没有测试过,你可以试一下。多导出一个函数不会太费事的。
#5
问题解决了.在dll类中要显示模态窗体,把application.handle传递过去了,在类关闭的时候加上一句:application.handle:=0就可以完美的解决这个问题了.
谢谢各位的参与.
谢谢各位的参与.
#1
不会吧?
应该可以的,自己在研究了
应该可以的,自己在研究了
#2
不要返回对象实例,返回接口!
我以前也经常遇到你的情况,使用接口后一点问题都没有了。
我以前也经常遇到你的情况,使用接口后一点问题都没有了。
#3
DLL的接口不要使用Delphi特有的东西,这样会出问题的
DLL是跨语言的:)
DLL是跨语言的:)
#4
根据个人的猜测。因为你的TWorkClass类在内存中有两个实现。一个存在于主程序中,一个存在于Dll中。你在Dll中创建类的实例调用了Dll中的那个实现的构造函数,最后释放的时候调用的其实是主程序中的析构函数,估计问题就出在这里。
至于为什么调用Work没有问题。大概是因为Work方法在两个实现中的偏移地址相同,而且大概没有跨模块的内存操作,所以不会出现异常。
作为中庸之道,你可以试着从Dll中导出一个专门用来施放对象的DeleteObj函数,把一个在Dll中创建的对象作为参数传给该函数,然后该函数直接调用obj.Free方法释放内存,这样一来调用的就是在Dll中那个类实现的析构,所以应该不会出问题。
没有测试过,你可以试一下。多导出一个函数不会太费事的。
至于为什么调用Work没有问题。大概是因为Work方法在两个实现中的偏移地址相同,而且大概没有跨模块的内存操作,所以不会出现异常。
作为中庸之道,你可以试着从Dll中导出一个专门用来施放对象的DeleteObj函数,把一个在Dll中创建的对象作为参数传给该函数,然后该函数直接调用obj.Free方法释放内存,这样一来调用的就是在Dll中那个类实现的析构,所以应该不会出问题。
没有测试过,你可以试一下。多导出一个函数不会太费事的。
#5
问题解决了.在dll类中要显示模态窗体,把application.handle传递过去了,在类关闭的时候加上一句:application.handle:=0就可以完美的解决这个问题了.
谢谢各位的参与.
谢谢各位的参与.