-
-
Couldn't load subscription status.
- Fork 324
TDynamicDLL as a separate unit + improvements #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
...pas (without other modifications)
...reateInstance, CreateInstanceAndLoad - creates an instance of the dll + MapDll (abstract virtual), CallMapDll - CallMapDll will be called in AfterLoad + LoadDll - now a function instead of procedure, returns validity. + DoOpenDll - use default dllname if empty string is passed; fix for loading dlls in subdirs (previous method would fail depending on its depended DLLs) + Import now accepts UnicodeStrings + Import2 for handling STDCall on 32bit + DllPath now writes via a function SetDllPath + DllFullFileName added a property that returns the full path of the dll PythonEngine.pas - TPythonInterface + AfterLoad - split functionality between TPythonInterface.MapDll and TDynamicDll.CallMapDll + GetDllPath - add the special behavior for the PythonDLL (IsPythonVersionRegistered) which has nothing to do in TDynamicDll + MapDll - added functionality from TPythonInterface.GetDllPath; Import now accepts UnicodeString and not AnsiString
Hi,
I'm wondering if you're considering this pull request or should I keep this class in a different repo.
Idan.
I am still pondering about this. I would like to have a closer look to both of your PRs but I have been quite busy. Sorry for taking so long...
Hi there!
I'm wondering if I should fork DynamicDLL.pas as I'm using it to import a different DLL.
https://github.com/talos-gis/gdal4delphi
Are you still considering this PR?
Feel free to do that.
I'm using your TDynamicDll as a base for other dlls that I use.
Here are some additions and fixes to make TDynamicDLL more generic