I am convert component from delphi 5 to delphi xe5`.
I build it completely but still while installation
following error come
The procedure entry point SymGetSymFromAddrW could not be located in
the dynamic link library IMAGEHLP.DLL
SymGetSymFromAddrW has been superceded by SymGetSymFromAddr64 on modern Windows versions. You need to use it instead. It has a very similar definition as SymGetSymFromAddr - just redefine it yourself, and use your version instead:
function SymGetSymFromAddr64(hProcess: THandle; dwAddr: DWord64;
pdwDisplacement: PDWord64; var Symbol: TImagehlpSymbol): Bool; stdcall;
function SymGetSymFromAddr64; external ImagehlpLib name 'SymGetSymFromAddr64W';
See the documentation for SymGetSymFromAddr64 for more info.
Related
I have an app that uses winrar (unrar64.dll). In delphi 10.3 the code runs fine, but running it under Delphi 11, it throws an access violation on this line
RARSetCallback(RARArchiveInstance, HandleRarCallBack, Integer(Self));
This function is in the dll header file as
TRARSetCallback = procedure(hArcData: THandle; Callback: TRARUnRarCallback; UserData: longint); stdcall;
The second param is a function defines as such
TRARUnRarCallBack = function(msg: Cardinal; UserData, P1, P2: longint): integer; stdcall;
I assume the data types may have changed from 10.3 to 11. but cannot figure out where the issues lie. Thank you
All of the longints declared in your code are wrong. They should be LPARAM which is pointer sized.
You should refer to the official header file to make sure the types are defined correctly across your code. My guess is that you have an old Pascal header translation. You can either fix it yourself or search for a new one.
For cross-platform development with Internet Direct (Indy), it can be useful to enable iconv support instead of the OS-specific Windows character conversions.
This would allow to continue developing and testing code on Windows in the Delphi IDE, but still be able to find conversion related issues before compiling the code on a different platform.
Indy 10 already includes code to use the iconv API on Linux and Windows.
On Windows, some preparation is required:
copy the iconv API DLL to the app folder or the search path
define the use_iconv conditional symbol
The intention of this question is to help getting started with iconv on the Windows platform.
If I have a quick look at the iconv.h I found with the gettext for windows sourceforge project, and if I understood the C code correctly, a wrapper-unit for iconv.dll could look like this, and could be used on the input and output of Indy components.
unit iconv;
interface
//based on version 1.9.1 https://sourceforge.net/projects/gettext/
type
TIconv = pointer;
function iconv_open(const PAnsiChar:tocode; const PAnsiChar:fromcode): TIconv; cdecl;
function iconv(cd:TIconv; var inbuf:PAnsiChar; var inbytesleft:integer; var output:PAnsiChar; var outbytesleft:integer): integer; cdecl;
function iconv_close(cd:TIconv): integer; cdecl;
const
ICONV_TRIVIALP =0; // int *argument
ICONV_GET_TRANSLITERATE =1; // int *argument
ICONV_SET_TRANSLITERATE =2; // const int *argument
ICONV_GET_DISCARD_ILSEQ =3; // int *argument
ICONV_SET_DISCARD_ILSEQ =4; // const int *argument
type
TiconvlistDoOne=function(namescount:cardinal; const names:PAnsiChar; data:pointer): integer; cdecl;
function iconvctl(cd:TIconv; request:integer; argument:pointer): integer; cdecl;
procedure iconvlist(do_one:TiconvlistDoOne; data:pointer); cdecl;
procedure libiconv_set_relocation_prefix(const orig_prefix:PAnsiChar; const curr_prefix:PAnsiChar); cdecl;
implementation
function iconv_open; external 'iconv.dll';
function iconv; external 'iconv.dll';
function iconv_close; external 'iconv.dll';
function iconvctl; external 'iconv.dll';
procedure iconvlist; external 'iconv.dll';
procedure libiconv_set_relocation_prefix; external 'iconv.dll';
end.
Free Pascal has an iconv header (package iconvenc), and that either is delphi compatible or should be easily updatable. Get it from FPC websvn interface module iconvenc or the latest RC (2.6.2rc1), since it might have updated since the year old 2.6.0.
But it is more complicated than just providing the header, since iconv on windows doesn't support errno, and thus can't handle EILSEQ and EI2BIG, so you need to properly allocate memory up front (like 4*charsize).
I got code how to handle non errno iconv targets PHP, but it hasn't been tested very well. (see src/iconvert.inc)
In Delphi XE UxTheme unit there is the following declaration
function DrawThemeTextEx(hTheme: HTHEME; hdc: HDC; iPartId: Integer; iStateId: Integer;
pszText: LPCWSTR; cchText: Integer; dwTextFlags: DWORD; pRect: PRect;
var pOptions: TDTTOpts): HResult; stdcall;
external themelib name 'DrawThemeTextEx' delayed;
My Windows XP Professional with SP3 does not have such function in the uxtheme.dll (checked with dllexp.exe from http://www.nirsoft.net/utils/dll_export_viewer.html)
It seems like my application does delayed loading of the procedure and fails runtime with the following error:
Project mtgstudio.exe raised exception class EExternalException
with message 'External exception C0FB007F'.
The issue was encountered in JVCL as well but resolved there as per http://andy.jgknet.de/blog/2009/09/once-upon-a-delayed-jvcl-time/
I need UxTheme fixed because they are used by the DevExpress components as well.
Is there a way to patch/fix the UxTheme.pas DrawThemeTextEx declaration to be non-delayed?
The fundamental problem is that this API was introduced in Vista and is not available in XP.
The whole point of the delayed keyword is to allow functions like this to be made available easily to developers who want to take advantage of newer API functions. But to do so the developer typically must also provide fallback implementations for older OS versions, which DevExpress appear to have failed to do.
The bug is therefore not in UxTheme.pas, but in the DevExpress component that calls an API that is not implemented on the platform. The fix is to re-work the DevExpress code to avoid calling this API on XP.
I suggest you contact DevExpress who quite probably already have a fix in their latest versions.
I need to initiate a call using TAPI from Delphi 2006. I'd like it to be as simple as possible. Any suggestions for a simple component? Is it in JEDI?
you can use the TurboPower Async Professional, some time ago I used this library and worked perfect, you can find more info about tapi and the AsyncPro component in this link.
Here is a list of components some freeware some shareware
http://www.torry.net/pages.php?id=199
Thanks
To use Tapi and delphi all you need is 2 things.
a. import the dll and create the tlb file.
in the delphi menu, go to componenets, then choose import components, then choose import type library, type "tapi3" and pick the tapi3.dll.
b. with the dll created to make a call you simple need to use
procedure TForm1.Button1Click(Sender: TObject);
var
Request:ITRequest;
dispatch:ITDispatchMapper;
begin
Request := CoRequestMakeCall.create;
Request.MakeCall('555-5555','Tag','client name','Comment');
end;
and replace the '555-5555' with the user input file number, as string.
Add this line before the implementation
function tapiRequestMakeCallW(DestAddress: PWideChar; AppName: PWideChar;
CalledParty: PWideChar; Comment: PWideChar): LongInt; stdcall;
external 'TAPI32.DLL';
after that call tapiRequestMakeCallw like that
TapiSonuc:=tapiRequestMakeCallw(Phone,'', comment, Comment);
I have to use an existing dll, but got a problem with it.
Here's how I try to use it:
unit u_main;
...
implementation
procedure getUserData(var User, Pass: string); stdcall; external 'Common5.dll';
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
var
u, p: string;
begin
getUserData(u,p);
end;
...
end.
When I press the button the get the userData, I get an EInvalidPointer exception.
The dll is registerd and in some other projects it's in use and work. any ideas?
EDIT:
The DLL was created in Delphi7 and is now used in a Delphi 2009 project.
Maybe there's a problem with unicode strings or something like that?
You need to rebuild the Delphi 7 DLL, make it follow the WinApi standard of getting PChar and BufferLen parameters. You've got multiple problems with the current implementation:
string is platform-specific, it's implementation may change between delphi versions (and did change). You're not supposed to use string outside the platform!
You're passing the parameters as "var", suggesting the DLL might change the value of user and/or pass. String is an special, managed type, changing it requires allocating memory for the new string. This in turns requires you to share the memory manager between the DLL and the EXE (using sharemem.pas and BorlandMM.dll - or variants). The trouble is, sharing the memory manager between different versions of Delphi is an unsupported configuration! (gotton from embarcadero forums)
The Delphi 7 is hoping to receive an simple AnsiString (1 byte chars), while the Delphi 2009 exe is sending Unicode strings (2 bytes per char).
Along with using PChar, be sure to pre-allocate the space before you call GetUserData. i.e. if you assign 'foo' into a pchar that's empty, you'll blow up. So either use static length PChar/PAnsiChar arrays, or use this technique:
var
s : AnsiString;
begin
setlength(s,256);
MyDLLProc(PAnsiChar(s));
end;