Delphi7-ből string átadás DLL-nek (UTF8 hiba?)
2014-04-30T07:02:13+02:00
2014-05-07T23:00:38+02:00
2022-08-08T20:15:32+02:00
mandula
Sziasztok !

 Van egy (XE3 alatt fordított) DLL fájl, amit eddig simán el tudtam érni a Delphi7-es programomból. Pár dolog át lett benne írva, újra lett Build-elve és most már nem jutnak át az AnsiString -ek.

TDSX_LoadFromFile = Function (Const Obj:PDSXObject; Const FileName:AnsiString):Integer; Cdecl;

A DLL-be bele lett írva egy MessageBox, ami kiírja, mit kap változónak, és egy nagy "" az eredmény. Ha XE3 alatt fordítok egy EXE-t, azzal simán!

Nekem ez totál UTF8 konverziós hibának tűnik, csak akkor nem értem, hogy:
1. eddig miért ment jól? (több éven át)
2. Talán nem jó az AnsiString? Át kellene a HEADER-eket és a DLL-t is írni mindenhol WideString-re? És eddig csak valami véletlen folytán működött?
Mutasd a teljes hozzászólást!
Persze, mert nem kompatibilis a ketfele D7 es a D2009+ string egymassal. Probald atszenvedni PAnsiChar-al vagy PWideChar-al es ha nem akarsz terminal 0-kat keresgelni, akkor kuldened kell még a lenght-et is.

Ez amiatt van, mert bôvült a string header -> A Delphi String-ek

Abban az esetben, ha az XE-s programot nem tudod modositani/ujraforditani, akkor le kell szimulalnod az XE stringjeit: Az klassikus ansistring (D7-ben string) kodlapja 1252 es az elementsize pedig 1 (byte).
Mutasd a teljes hozzászólást!

  • Hogyan próbáltál debuggolni? Különös tekintettel a View/Cpu részre?
    Mutasd a teljes hozzászólást!
  • Persze, mert nem kompatibilis a ketfele D7 es a D2009+ string egymassal. Probald atszenvedni PAnsiChar-al vagy PWideChar-al es ha nem akarsz terminal 0-kat keresgelni, akkor kuldened kell még a lenght-et is.

    Ez amiatt van, mert bôvült a string header -> A Delphi String-ek

    Abban az esetben, ha az XE-s programot nem tudod modositani/ujraforditani, akkor le kell szimulalnod az XE stringjeit: Az klassikus ansistring (D7-ben string) kodlapja 1252 es az elementsize pedig 1 (byte).
    Mutasd a teljes hozzászólást!
  • (Nem ismerem a Delphit, ezért hadd kérdezzem meg: effektíve ugyanaz a típus-név más belső adatszerkezetet jelent az új verzióban?)
    Mutasd a teljes hozzászólást!
  • Pontosan, eloszor a pascalban a 'string' alias a 256 byteos statikus string-et jelentette, aztan Delphiben ugyanaz a 'string' alias a dinamikus 8bites ansistring lett, es vegul a D2009 ota dinamikus akarmilyen stringet jelent (16bit kodlap es 16bit elementsize hatarozza meg a formatumot. Pl utf8 tamogatas is van teljesen automatikusan, meg lehet akár 32bites unicode is).
    Szoval ossz 2 durva jelentesvaltozas volt.
    De jol kitalaltak, mert C-vel valo kompatibilitas semeddig sem tart mivel implicit trailing 0 van es maga a string pointer nem a string elott levo 12byteos headerre mutat, hanem a string elso karakterere.
    Mutasd a teljes hozzászólást!
  • A Brief History of Delphi Strings
    Ez egész jól összefoglalja...

    Egyébként még attól is függ, hogy a STRING típus mekkora, hogy 32bit, vagy 64bit alatt fordítod XE+ alatt.

    A kérdés viszont sajnos még mindig az, hogy :

     - hogyhogy eddig működött AnsiString-gel a dll meghívás, most meg már nem?
    Van esetleg XE3 alatt valami olyan fordítói direktíva, ami felülbírálja az AnsiString-et?
    Mutasd a teljes hozzászólást!
  • Köszönöm real_het !
     De igen, újra tudom fordíttatni az XE3-as DLL-t.

    Szóval azt mondod, hogy a sima AnsiString nem jó?

    Azt írtad, hogy: PAnsiChar vagy PWideChar ... nem inkább PAnsiString vagy PWideString?
    hiszen ezek csak egyetlen karaktert tartalmazhatnak... nem?
    Mutasd a teljes hozzászólást!
  • > hogyhogy eddig működött AnsiString-gel a dll meghívás, most meg már nem?

    Azon töprengek, hogy esetleg az is közre játszik, hogy eddig másik memória-kezelőt használt a fejlesztő srác. Még nem kaptam választ, hogy most mire váltott, de mintha említette volna, hogy kicserélte.
    Mutasd a teljes hozzászólást!
  • Némi keresgélés után azt hiszem, választ kaptam a kérdésemre:
     - nem lehet ezt olyan egyszerűen megcsinálni :(

    Embarcadero Discussion Forums:

    Exchanging strings (PChar) between a Freepascal compiled DLL and a Delphi compiled EXE
    Mutasd a teljes hozzászólást!
  • Olyan nincs, hogy nem lehet, mert legrosszabb esetben asmozhatsz is :D (ja, most latom, hogy egyszeruen nem lehet... hát ja.)

    Ha a .dll XE-s, akkor emulalni kell azt a stringet, amit az kezel.

    Ha kuldesz egy D7 stringet az XE-nek, akkor az XE a kodlap es az elementsize helyén memoriaszemetet fog talalni.

    Ha a D7 dll-nek kuldesz egy XE stringet, akkor a D7 nem fogja nezni az XE-ben bevezetett +4 byteot es ansikent fogja kezelni azt a stringet még akkor is, ha az unicode es ebben az esetben feleannyi byte hosszu lesz a string, hibas mukodes.

    Az igazan nagy galiba meg akkor lehet, ha a dll szabaditja fel azt a stringet, amit az exe-tol kapott (vagy forditva), mert akkor nemlefoglalt pointert akarna freezni a 4 byte csuszas miatt.

    En csinalnek ra egy TXEstring classt, ami gondoskodik az XE-vel kompatibilis string emulalasarol es a referencia counttal mindig lockolja a stringet, hogy semmikeppen se fordulhasson elo, hogy a dll felszabaditsa.
    Mutasd a teljes hozzászólást!
  • >"Olyan nincs, hogy nem lehet, mert legrosszabb esetben asmozhatsz is :D"

    Mi az az ASMOZ-ás?

    Egyébként a fejlesztő srác egyszerűen kicserélte mindenhol az AnsiString-et WideString-et, és azóta simán csodásan működik! :D
    Mutasd a teljes hozzászólást!
  • Az viszont nekem is most utott be, hogy az egyetlen string, ami kompatibilis maradt, az a widestring. Amit ha mas miatt nem is, de az 'E
    xcel'-el valo kompatibilitas miatt nem valtoztattak meg. :D Szoval jo otlet volt
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd