TÉMA:

Így már tényleg működik, ha a rekordot is "packed"-re állítom. Tömörítve mind a két verzió egyformán kezeli a tömböket és a rekordokat. Köszönöm a megoldást!

Mellesleg jegyzem meg, hogy a konverzió készítése közben fedeztem fel, hogy az 1.6.0 a CopyFile és a DelTree függvényeknél sem kezeli a magyar ékezetes betűket. Kezdek kiábrándulni...

Hmm. Mind a két Lazarus verzióval nyomjál már egy SizeOf-ot a rekord típusodra. Én próbáltam összehozni egy ilyen rekordot, és az 1.4-es 1824 byte, az 1.6-os alatt 1796 byte volt a visszaadott érték.
Ha a rekordtípust az alábbira módosítottam mind a két verzió alatt, akkor nem volt gond a visszaolvasással SizeOf-ra pedig egységesen 1794 byte-ot kaptam:
Én azt csinálnám, hogy az 1.4-essel csinálnék egy programot, ami átkonvertálja ezt az adatbázist a fentebbi rekordtípus szerint, így már az 1.6-os verzióval fordított program sem fog problémázni az adatokkal.

A "packed" kiegészítés sem segített, sajnos. Ékezetes adatokat sikeresen visszaolvas a tömb előtt.

Köszönöm az ötleteket.

AnyagNev : packed Array [1..6] of String[250];
AnyagDarab : packed Array [1..6] of Byte;
AnyagAr : packed Array [1..6] of Integer;

Ha így alakítod a rekordban a tömböket az 1.6-os alatt? Vagy próbálj meg ékezetek nélkül felvinni adatokat a string tömbbe, hogy akkor visszaolvassa e. Ha igen, akkor talán közelebb jutottunk a probléma megoldásához.

Amíg nincs tömb használat, addig rendben visszaolvassa az adatokat. A "kiadva ügyfélnek" pipa egy Boolean típus. Ez még rendben visszajön és ez nincs tömbbe foglalva. A "megnevezés", "darab", "ár" mezők adatai vannak tömbben tárolva.

Az első kép az eredeti...

Ha másolnál ide egy rekordot (személyes adatok nélkül), hogy mi az eredetileg mentett és mi az amit visszaad helyette az új változat az sokat segíthetne a hibakeresésben...

A gondolat kiváló, én is próbáltam, de sajnos nem oldja meg a dolgot. A problémát nem a változók kezelése okozza, szerintem a rekord és a tömb kezelés a gond, de nem találtam megoldást.

Esetleg egy {$PACKRECORDS 32 c} fordítódirektíva? ( freepascal.org/docs-html/current/prog/progsu60.html#x67-660001.2.60 )

Ez alapján:
RTTI for Records

Old behavior: Records RTTI stored field Offsets as 32bit integers.
New behavior: Records RTTI stores field Offsets as platform-dependent integers (the same size as pointers).
Reason: Internally the compiler stores Offsets as platform-dependent integers. The new behaviour is Delphi-compatibile.
Remedy: You need to adjust your code if you used field offsets of record RTTI. This is also true if your code processes any vInitTable field within the VMT of a class.

Elsőre azt mondanám, hogy az Integer típus mérete okozhatja a problémát, mely nem minden fordító üzemmódban ugyanaz. Az alapértelmezett (FPC) módban az Integer típus mérete 16bit, míg az ObjFPC és Delphi módokban 32bit. Lásd: Predefined integer types

Próbáld úgy fordítani a programodat, hogy az egyszerű Integer helyett SmallInt vagy LongInt típust használsz. Szintén segíthet a {$MODE xxxx} direktíva megfelelő paraméterrel történő használata a forráskód elején.

A programot alapból {$MODE ObjFPC}{H+} kapcsolókkal készítettem, így az Integer típust alapból LongInt-ként kezeli a fordító. Átalakítottam a szükséges dolgokat, hogy {$MODE FPC} kapcsolóval elinduljon a progi, de ez sem hozott eredményt. A Delphi mód eleve kizárva, mivel pont a Delphi-vel való kompatibilitási változtatások (FPC 2.6.4 -> 3.0.0) okozzák a gondomat.

Magyar ékezetes betűk szerepeltek a string-ben? A karakterek különböző kódolásai a freepascal verzióváltásnál okozhat meglepetéseket. A régi Ansi-ként menthette le, az új meg UTF8-ként próbálná értelmezni, és ez pl. magyar ékezetes karakterek esetén nem lesz sikeres. Ha ez a helyzet, akkor WinCPToUTF8 függvénnyel lehetne egyszer átkonvertálni a fájl string tartalmát magyar Ansi-ről UTF8-ra.

Egy esetben jelentkezett ez a probléma, amikor MessageBox függvényt használok. WinCPToUTF8 függvényt nekem nem talált a fordító. Nem nagy gond, MessageBox helyett QuestionDlg tökéletesen működik.

Magyar ékezetes betűk szerepeltek a string-ben? A karakterek különböző kódolásai a freepascal verzióváltásnál okozhat meglepetéseket. A régi Ansi-ként menthette le, az új meg UTF8-ként próbálná értelmezni, és ez pl. magyar ékezetes karakterek esetén nem lesz sikeres. Ha ez a helyzet, akkor WinCPToUTF8 függvénnyel lehetne egyszer átkonvertálni a fájl string tartalmát magyar Ansi-ről UTF8-ra.

Elsőre azt mondanám, hogy az Integer típus mérete okozhatja a problémát, mely nem minden fordító üzemmódban ugyanaz. Az alapértelmezett (FPC) módban az Integer típus mérete 16bit, míg az ObjFPC és Delphi módokban 32bit. Lásd: Predefined integer types

Próbáld úgy fordítani a programodat, hogy az egyszerű Integer helyett SmallInt vagy LongInt típust használsz. Szintén segíthet a {$MODE xxxx} direktíva megfelelő paraméterrel történő használata a forráskód elején.

Sziasztok!

Egy típusos fáljban tárolok adatokat. A fájl típusául szolgáló record, leegyszerűsítve:

Adat = Record
SorSzamEv : Word;
SorSzam : Integer;
Nev: String[250];
Adatmentes : Boolean;
AnyagNev : Array [1..6] of String[250];
AnyagDarab : Array [1..6] of Byte;
AnyagAr : Array [1..6] of Integer;
end;

Az adatok feltöltése Lazarus 1.4.4-gyel fordított programmal történt. A gond ott kezdődik, ha ugyanazt a forráskódot lefordítom Lazarus 1.6-tal, akkor az adatok visszakérdezése hibás. Sejtem, hogy a FPC 2.6.4 és 3.0.0 között történt változás a változók kezelésében, de olvasgatva a változáslistát, abból nekem nem derült ki, hogy hogyan lehetne ezt orvosolni.

Valaki találkozott hasonlóval, esetleg van megoldás is?

Windows rendszer alatt fejlesztek.

Előre is köszönöm a válaszokat.

Ottó