(possible to make feature request here ?)
linking to fixed DLLName like
function CkSFtp_Create: HCkSFtp; stdcall; ... implementation
function CkSFtp_Create; external DLLName;
is unhandy because of some reasons:
the path must be in search path and you can't give a specific location f.e. in a config-file if needed for several applications in different paths.
if the dll cannot be loaded the application will abort immediately without error message.
if you need a certain functionality f.e. SFTP or MAIL just only in seldom concrete situations then only on first use of that will be nessary to load the DLL and link the DLL-Entries. But in the actual implementation the DLL is loaded on EVERY start which slows down the start of the application.
will there be any chance to switch this to dynamically loading ? f.e.
function CkSFtp_Create: HCkSFtp; procedure CkSFtp_Dispose( handle: HCkSFtp);
TFkt_CkSFtp_Create =function : HCkSFtp; stdcall; TFkt_CkSFtp_Dispose =procedure( handle: HCkSFtp); stdcall;
_lcl_init:Boolean = true; _fkt_ptr_arr: array [0..266] of Pointer; function _Map( k:Integer; n:String):Pointer; begin Result:= _fkt_ptr_arr[k]; if Result = nil then begin Chilkat_GetProcedureAddress( Result, n); _fkt_ptr_arr[k]:= Result; end; end; function CkSFtp_Create: HCkSFtp; begin Result:= TFkt_CkSFtp_Create(_map( 0, 'CkSFtp_Create')) ( ); end; procedure CkSFtp_Dispose( handle: HCkSFtp ); begin TFkt_CkSFtp_Dispose(_map( 1, 'CkSFtp_Dispose')) ( handle); end;
and in chilkat_DLL_loader something like:
function Chilkat_CanUse:Boolean; procedure Chilkat_GetProcedureAddress(var P; ProcName: string);
uses windows, sysutils;
DLLPath = '...';
var ModuleName: String;
function Chilkat_LoadModule:HModule; var S: String; begin S:= DLLPath;
ModuleName:= S + '\ChilkatDelphiXE.dll';
ModuleName:= S + '\ChilkatDelphiXE64.dll';
Result:= GetModuleHandle(PChar(ModuleName)); if Result = 0 then Result:= LoadLibrary(PChar(ModuleName)); end; procedure Chilkat_GetProcedureAddress(var P; ProcName: string); var ModuleHandle: HMODULE; begin if not Assigned(Pointer(P)) then begin ModuleHandle := Chilkat_LoadModule; if ModuleHandle = 0 then raise Exception.Create('Library not found: ' + ModuleName); // + ' ' + WLastError); Pointer(P) := GetProcAddress(ModuleHandle, PChar(ProcName)); if not Assigned(Pointer(P)) then raise Exception.Create('Function not found: ' + ModuleName + '.' + ProcName); end; end; function Chilkat_CanUse:Boolean; begin Result:= Chilkat_LoadModule <> 0; end;
I transformed each chilkat source in that way, but I think it would be better chilkat will provide the dynamically loading if other users will also need that kind of loading (?)
Thanks! I'll see what can be done... (I can't promise anything for now..)
Please see my post - http://www.chilkatforum.com/questions/11380/error-when-using-upx-with-chilkat-delphi
There is a valid reason you would want to add this enhancement.
Thanks! I'll try my best to get this in the v22.214.171.124 release. I'll likely post a pre-release here for you to test.. It should be this week..
I wrote a parser last night to reformat the code, I'll email the refactored units to support. If you're interested in it, you're free to use any or all parts of it.
Here's a build where the .pas files use the dynamic loading scheme you suggested: http://chilkatdownload.com/prerelease/chilkat-9.5.0-delphi-dyn.zip
This is v126.96.36.199. I released v188.8.131.52 on the chilkatsoft.com site, and it still uses the old. I gave this a quick test and it looked OK. If you find any issues, please let me know.
Assuming all is OK, the next version released will contain the .pas files w/ this dynamic loading..
I did a diff of the code and found some issues:
Atom.pas - several entries still have the stdcall directive on the methods in the interface section - ie. CkAtom_AddEntry.
Cache.pas - the CkCache_AddRoot has it also.
Cgi.pas - getAsyncBytesRead, AsyncPostSize, getSizeLimitKB, putSizeLimitKB and GetUploadSize used to be type LongWord, now they are Integer, not sure which is correct. CkGgi_AbortAsync and SleepMS have the stdcall directive
SocksProxy.pas existed in the old version but is missing from new one, intentional?
I stopped there as I see that there are a number of other units that still have the stdcall directive on some of the calls. I would guess that however you're creating these headers, once you fix whatever is causing this it'll resolve it in all the units.
Thanks, this new build fixes it:
Also, the Cgi class is deprecated and in any case, I don't think the Cgi class would be of any use in Delphi. It's not like a Delphi program would be running on a web server receiving incoming HTTP requests.
Also, the SocksProxy class was removed long ago. The Delphi .pas wrapper was still leftover, but couldn't have been used anyway..
Did a code review of this latest version, looks good to me.
It was a good exercise looking through all of those units, gave me some ideas on various other 3rd party software we use that we can replace with things implemented in ChilKat.
Thank you! Rich