Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2005-06

Typed file problem.

7 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Inpromptu

Hi.

I have developed a console app, wich use a typed file. I use Lazarus to make the GUI, but there is some problem with the typed file generated by the console app. The GUI app does not read the file correctly. Specially with the string vars.

Is it a problem with the delphi mode compilation (some diference handling typed files)? How can I do to detect the problem in compilation time?

My workaround is to compile the console part first, and then compile the GUI in Lazarus. But I think that there is a better solution. I can't recompile all the software with Lazarus, because I have a lot of cgi apps (no GUI) that reads the typed files.

Thanks in advance! Lazarus is great !

Inpromptu.

(excuse my english...)

_______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com

Reply by email

Michalis Kamburelis
to Inpromptu
Inpromptu wrote 14 lines
Hi. I have developed a console app, wich use a typed file. I use Lazarus to make the GUI, but there is some problem with the typed file generated by the console app. The GUI app does not read the file correctly. Specially with the string vars. Is it a problem with the delphi mode compilation (some diference handling typed files)? How can I do to detect the problem in compilation time? My workaround is to compile the console part first, and then compile the GUI in Lazarus. But I think that there is a better solution. I can't recompile all the software with Lazarus, because I have a lot of cgi apps (no GUI) that reads the typed files. Thanks in advance! Lazarus is great ! Inpromptu. (excuse my english...)

First of all, Lazarus and GUI/non-GUI difference has nothing to do here. Lazarus allows you to compile non-GUI programs without any problems, if you want. Of course, the same compiler and the same RTL is used to compile GUI (i.e. LCL) and console programs.

As far as I understand, by "typed file" you mean that you use file variable of type like "file of TSomeType". This is not any magic format for a file, it just reads/writes a series of TSomeType values from/to a file.

Are you sure that exactly the same definition of TSomeType is used when you compile GUI and console version of your program ? Maybe some structures are aligned differently when you compile GUI and console version of your program ? Are you sure that the unit where TSomeType type is declared is always compiled in the same FPC $mode ? Maybe you use "string" inside your TSomeType and sometimes it's understood as "ShortString" and sometimes as "AnsiString" ?

The one thing that you can check is to print SizeOf(TSomeType) from your program, once from the GUI version and then from the console version. They should be equal. If they are not, you know where your bug is. You must ensure that your units are always compiled with the same options, both for console and for GUI version.

Otherwise, I think that we could help more if you would show some code snippets how exactly do you read/write your file.

Michalis

Reply by email

Inpromptu
First of all, Lazarus and GUI/non-GUI difference has nothing to do here. Lazarus allows you to compile non-GUI programs without any problems, if you want. Of course, the same compiler and the same RTL is used to compile GUI (i.e. LCL) and console programs.

Ok !

Show quoted text 5 lines
As far as I understand, by "typed file" you mean that you use file variable of type like "file of TSomeType". This is not any magic format for a file, it just reads/writes a series of TSomeType values from/to a file.

Yes.

Show quoted text 9 lines
Are you sure that exactly the same definition of TSomeType is used when you compile GUI and console version of your program ? Maybe some structures are aligned differently when you compile GUI and console version of your program ? Are you sure that the unit where TSomeType type is declared is always compiled in the same FPC $mode ? Maybe you use "string" inside your TSomeType and sometimes it's understood as "ShortString" and sometimes as "AnsiString" ?

This seems to be the problem. Is there any way to stop the compilation of the non-delphi part, to avoid string problem ? Is there anyway to force ShortStrings in the console app ?.

Show quoted text 10 lines
The one thing that you can check is to print SizeOf(TSomeType) from your program, once from the GUI version and then from the console version. They should be equal. If they are not, you know where your bug is. You must ensure that your units are always compiled with the same options, both for console and for GUI version. Otherwise, I think that we could help more if you would show some code snippets how exactly do you read/write your file. Michalis

I will write some simple code...

Thanks !!

Inpromptu.

_______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com

Reply by email

Michalis Kamburelis
to Inpromptu

Inpromptu wrote:
[...]

Show quoted text 14 lines
>Are you sure that exactly the same definition of TSomeType is used >when you compile GUI and console version of your program ? Maybe >some structures are aligned differently when you compile GUI and >console version of your program ? Are you sure that the unit where >TSomeType type is declared is always compiled in the same FPC $mode >? Maybe you use "string" inside your TSomeType and sometimes it's >understood as "ShortString" and sometimes as "AnsiString" ? > This seems to be the problem. Is there any way to stop the compilation of the non-delphi part, to avoid string problem ? Is there anyway to force ShortStrings in the console app ?.

You can always just write "ShortString" instead of writing "string", then you know that you're for sure using ShortStrings. Also, you can use compiler directive {$H-} to say that "string" should mean "ShortString". {$H+} means that "string" is "AnsiString". The default state of $H depends on FPC $mode that you use.

Note that ShortString length is limited to 255 characters. Usually you shouldn't use ShortString at all in new programs, unless you're really sure that your data will always fit within these 255 characters.

However, storing AnsiStrings in a file cannot be done using Pascal typed files (because AnsiString is a special pointer, so you can't simply read/write it to a file). So if it sounds like you don't want to actually use ShortString, you may want to drop using typed files.

Michalis

Reply by email

Inpromptu

I've found the problem... !

if the record is

Myrecord=record
         MyInteger:integer;
         Mystring:string;
         end;

compiled with c:\lazarus\pp\bin\i386-bin\ppc386 without any other parameter, sizeof(Myrecord.Myinteger) shows 2.

compiled inside Lazarus sizeof(Myrecord.Myinteger) shows 4 !

Because of this, Mystring is readed wrong from the file.

I think this is a trivial problem, but I don't know how to force MyInteger to be 2 bytes long inside and outside Lazarus... Or 4 bytes long ?

Thanks !

Show quoted text 44 lines
Inpromptu wrote: [...] > > >> Are you sure that exactly the same definition of TSomeType is >> used when you compile GUI and console version of your program ? >> Maybe some structures are aligned differently when you compile >> GUI and console version of your program ? Are you sure that the >> unit where TSomeType type is declared is always compiled in the >> same FPC $mode ? Maybe you use "string" inside your TSomeType >> and sometimes it's understood as "ShortString" and sometimes as >> "AnsiString" ? >> > > > This seems to be the problem. Is there any way to stop the > compilation of the non-delphi part, to avoid string problem ? Is > there anyway to force ShortStrings in the console app ?. > You can always just write "ShortString" instead of writing "string", then you know that you're for sure using ShortStrings. Also, you can use compiler directive {$H-} to say that "string" should mean "ShortString". {$H+} means that "string" is "AnsiString". The default state of $H depends on FPC $mode that you use. Note that ShortString length is limited to 255 characters. Usually you shouldn't use ShortString at all in new programs, unless you're really sure that your data will always fit within these 255 characters. However, storing AnsiStrings in a file cannot be done using Pascal typed files (because AnsiString is a special pointer, so you can't simply read/write it to a file). So if it sounds like you don't want to actually use ShortString, you may want to drop using typed files. Michalis _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com

Reply by email

Michalis Kamburelis
to Inpromptu
Inpromptu wrote 19 lines
I've found the problem... ! if the record is Myrecord=record MyInteger:integer; Mystring:string; end; compiled with c:\lazarus\pp\bin\i386-bin\ppc386 without any other parameter, sizeof(Myrecord.Myinteger) shows 2. compiled inside Lazarus sizeof(Myrecord.Myinteger) shows 4 ! Because of this, Mystring is readed wrong from the file. I think this is a trivial problem, but I don't know how to force MyInteger to be 2 bytes long inside and outside Lazarus... Or 4 bytes long ?

Size of Integer depends on FPC $mode used. See
[http://www.freepascal.org/docs-html/prog/progap4.html]. So you can force Integer to be of specific size by making sure that FPC always uses the same $mode, whether you compile console version or GUI version from Lazarus.

Or you can use "SmallInt" or "LongInt" (depending on what you want -- 2 or 4 bytes ?) to be sure that, regardless of $mode used, your MyInteger has always the same size. See
[http://www.freepascal.org/docs-html/ref/refsu5.html].

Michalis

Reply by email

Inpromptu

Problem solved !

Thank you very much !

Show quoted text 39 lines
Inpromptu wrote: > I've found the problem... ! > > if the record is Myrecord=record > MyInteger:integer; > Mystring:string; > end; > > compiled with c:\lazarus\pp\bin\i386-bin\ppc386 without any other > parameter, sizeof(Myrecord.Myinteger) shows 2. > > compiled inside Lazarus sizeof(Myrecord.Myinteger) shows 4 ! > > Because of this, Mystring is readed wrong from the file. > > > I think this is a trivial problem, but I don't know how to force > MyInteger to be 2 bytes long inside and outside Lazarus... Or 4 > bytes long ? > > Size of Integer depends on FPC $mode used. See [http://www.freepascal.org/docs-html/prog/progap4.html]. So you can force Integer to be of specific size by making sure that FPC always uses the same $mode, whether you compile console version or GUI version from Lazarus. Or you can use "SmallInt" or "LongInt" (depending on what you want -- 2 or 4 bytes ?) to be sure that, regardless of $mode used, your MyInteger has always the same size. See [http://www.freepascal.org/docs-html/ref/refsu5.html]. Michalis _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com

Reply by email