Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello. I did try using aligntoqword() but without luck, I only get crash at loading. It is very sad but I dont have the skill to fix this and mse depends of a guru with brave heart to make it compatible with fpc 3.3.1. Anyway, many thanks Martin for your light. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello Martin.
Wow.
Indeed, I did a check in mse code and only exists, in msearrayutils.pas:
function aligntoptr(p: pointer): pointer; inline;
begin
{$ifdef FPC_REQUIRES_PROPER_ALIGNMENT}
result:= align(p,sizeof(p));
{$else FPC_REQUIRES_PROPER_ALIGNMENT}
result:=p;
{$endif FPC_REQUIRES_PROPER_ALIGNMENT}
end;
And nothing about aligntoqword()
I dont know if a function aligntoqword(p: pointer): pointer; inline;
must be added in msearrayutils.pas.
I will try using aligntoqword() of fpc and adapting mse code for it (ti:=
aligntoqword(ti);
If you see a other way, please advice.
Many, many, many thanks.
Fre;D
-
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
On 02/02/2020 04:22, fredvs via fpc-pascal wrote:
Hello everybody.
Good time to go back with that problem and fix it forever the right way!
The problem is isolated and is fixed "hardcoded".
From rev 42375, in msegui function dynarrayelesize(const typinfo:
pdynarraytypeinfo): sizeint; inline;
the result is always = 0.
I do not know if fpc has an official way to get the size of an array
element from the typeinfo.
But comparing the internals:
{$ifdef VER3_0}
typeInfo:=aligntoptr(typeInfo+2+PByte(typeInfo)[1]);
{$else VER3_0}
typeInfo:=aligntoqword(typeInfo+2+PByte(typeInfo)[1]);
{$endif VER3_0}
So alignment changed, which is why the old code no longer works
mse always does
ti:= aligntoptr(ti);
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello everybody.
Good time to go back with that problem and fix it forever the right way!
The problem is isolated and is fixed "hardcoded".
From rev 42375, in msegui function dynarrayelesize(const typinfo:
pdynarraytypeinfo): sizeint; inline;
the result is always = 0.
This function is used in additempo() function, used mainly in the
msestat.pas file.
This is used to restore, for example, the position and size of windows.
To fix with a turn-around, I did first compile mseide with fpc 3.2.0 to know
what is the value of dynarrayelesize(typeinfo).
It is always 16 and then I use that constant instead of
dynarrayelesize(typeinfo).
It works like charm and can use now fpc 3.3.1 without problems.
Great but, for the Champions, would it be somebody that can explain why the
result is always = 0 from rev 42375 ?
Here the problematic function:
function dynarrayelesize(const typinfo: pdynarraytypeinfo): sizeint; inline;
var
ti: pdynarraytypeinfo;
begin
ti:= typinfo;
{$ifdef FPC}
inc(pointer(ti),ord(pdynarraytypeinfo(ti)^.namelen)+2);
ti:= aligntoptr(ti);
result:= psizeint(ti)^;
{$else}
inc(pchar(ti),length(ti^.name));
result:= ti^.elsize;
{$endif}
end;
-
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Oops, sorry, fake news. It was my mistake, I did compile with fpc 3.0.4. So, no, with last commits, it does not fix the problems. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello. Great news! With last fpc commits, msegui is fpc compatible again! (And I am very curious what was the problem, if you can explain what you did it would be super.) Anyway, perfect and many thanks. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello Sven. > I can't see any difference in that procedure to the one in Classes.TReader > except for the ifdefs and a few extensions for events and UTF-8 strings, > so the problem must be somewhere else. Ha, we are going forward. so maybe TReader is not the problem. Ok, I will try to investigate a different way. Thanks Sven. Fre;D PS: If you see some other things that could be the guilty, dont hesitate to say it. - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
fredvs schrieb am Fr., 6. Sep. 2019, 22:23: > Hello everybody (included Sven). > > It seems that the problems come from > /mseide-msegui/lib/common/fpccompatibility/mclasses.pas. > > In procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo: > Pointer), IMHO there is something not compatible with rev 42375. > > It would be wonderful if somebody could detect what is wrong with typinfo > (I > did not find it yet). > > Here the code (I guess) with problem: > I can't see any difference in that procedure to the one in Classes.TReader except for the ifdefs and a few extensions for events and UTF-8 strings, so the problem must be somewhere else. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
fredvs schrieb am Mi., 9. Okt. 2019, 12:00:
> Could it be possible to simplify the life of rtl-users and add methods with
> same parameters as previous version and make it compatible with new
> features?
>
Working with the RTTI simply is *not* simple, because you're interfacing
with binary data that is represented by Pascal records.
> Other wishes:
>
> It seems that the updates done to rtl were necessary because of some
> arm-compatibility.
>
> OK, but now, for the same code, the binary-result compiled program is +- 30
> % bigger that same code compiled with fpc 3.0.4 or fp 3.2.0 (on the
> contrary fpc 3.2.0 gives binary 10 % less big than with fpc 3.0.4).
>
> Would it not be better to play with "{$ifdef cpuarm}" and so not make
> things
> heavier for all others cpu that do not need those arm-extension?
>
This size increase is not ARM related, but related to a new feature.
The alignment fixes you mention are in fact necessary for all non-x86
targets.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello everybody.
Sorry to come back with this but I am lost (and all my stock of Aspirina is
dead).
Could it be possible to simplify the life of rtl-users and add methods with
same parameters as previous version and make it compatible with new
features?
Other wishes:
It seems that the updates done to rtl were necessary because of some
arm-compatibility.
OK, but now, for the same code, the binary-result compiled program is +- 30
% bigger that same code compiled with fpc 3.0.4 or fp 3.2.0 (on the
contrary fpc 3.2.0 gives binary 10 % less big than with fpc 3.0.4).
Would it not be better to play with "{$ifdef cpuarm}" and so not make things
heavier for all others cpu that do not need those arm-extension?
Fre:D
-
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello everybody (included Sven).
It seems that the problems come from
/mseide-msegui/lib/common/fpccompatibility/mclasses.pas.
In procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo:
Pointer), IMHO there is something not compatible with rev 42375.
It would be wonderful if somebody could detect what is wrong with typinfo (I
did not find it yet).
Here the code (I guess) with problem:
-
procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo: Pointer);
const
NullMethod: TMethod = (Code: nil; Data: nil);
var
PropType: PTypeInfo;
Value: LongInt;
{ IdentToIntFn: TIdentToInt; }
Ident: String;
Method: TMethod;
Handled: Boolean;
TmpStr: String;
TmpStr8: utf8String;
begin
if not Assigned(PPropInfo(PropInfo)^.SetProc) then
raise EReadError.Create(SReadOnlyProperty);
{$ifdef FPC}
PropType := PPropInfo(PropInfo)^.PropType;
{$else}
PropType := PPropInfo(PropInfo)^.PropType^;
{$endif}
case PropType^.Kind of
tkInteger:
if FDriver.NextValue = vaIdent then
begin
Ident := ReadIdent;
if GlobalIdentToInt(Ident,Value) then
SetOrdProp(Instance, PropInfo, Value)
else
raise EReadError.Create(SInvalidPropertyValue);
end else
SetOrdProp(Instance, PropInfo, ReadInteger);
{$ifdef FPC}
tkBool:
SetOrdProp(Instance, PropInfo, Ord(ReadBoolean));
{$endif}
tkChar:
SetOrdProp(Instance, PropInfo, Ord(ReadChar));
tkWChar{$ifdef FPC},tkUChar{$endif}:
SetOrdProp(Instance, PropInfo, Ord(ReadWideChar));
tkEnumeration:
begin
ident:= ReadIdent;
Value := GetEnumValue(PropType, ident);
if Value = -1 then begin
if assigned(fonenumerror) then begin
fonenumerror(self,proptype,ident,value);
end;
end;
if Value = -1 then begin
raise EReadError.Create(SInvalidPropertyValue);
end;
SetOrdProp(Instance, PropInfo, Value);
end;
{$ifndef FPUNONE}
tkFloat:
SetFloatProp(Instance, PropInfo, ReadFloat);
{$endif}
tkSet:
begin
CheckValue(vaSet);
SetOrdProp(Instance, PropInfo,
{$ifdef FPC}
FDriver.ReadSet(GetTypeData(PropType)^.CompType));
{$else}
FDriver.ReadSet(GetTypeData(PropType)^.CompType^));
{$endif}
end;
tkMethod:
if FDriver.NextValue = vaNil then
begin
FDriver.ReadValue;
SetMethodProp(Instance, PropInfo, NullMethod);
end else
begin
Handled:=false;
Ident:=ReadIdent;
if Assigned(OnSetMethodProperty) then
OnSetMethodProperty(Self,Instance,PPropInfo(PropInfo),Ident,
Handled);
if not Handled then begin
Method.Code := FindMethod(Root, Ident);
Method.Data := Root;
if Assigned(Method.Code) then
SetMethodProp(Instance, PropInfo, Method);
end;
end;
{$ifdef FPC}
tkSString, tkLString, tkAString:
{$else}
tkString, tkLString:
{$endif}
begin
if proptype = typeinfo(utf8string) then begin
TmpStr8:=Readutf8String;
if Assigned(FOnReadStringProperty) then begin
tmpstr:= tmpstr8;
FOnReadStringProperty(Self,Instance,PropInfo,TmpStr);
tmpstr8:= tmpstr;
end;
SetStrProp(Instance, PropInfo, TmpStr8);
end
else begin
TmpStr:=ReadString;
if Assigned(FOnReadStringProperty) then
FOnReadStringProperty(Self,Instance,PropInfo,TmpStr);
SetStrProp(Instance, PropInfo, TmpStr);
end;
end;
{$ifdef FPC}
tkUstring:
SetUnicodeStrProp(Instance,PropInfo,ReadUnicodeString);
{$endif}
tkWString:
SetWideStrProp(Instance,PropInfo,ReadWideString);
tkVariant:
begin
SetVariantProp(Instance,PropInfo,ReadVariant);
end;
tkClass:
case FDriver.NextValue of
vaNil:
begin
FDriver.ReadValue;
SetOrdProp(Instance, PropInfo, 0)
end;
vaCollection:
begin
FDriver.ReadValue;
ReadCollection(TCollection(GetObjectProp(Instance, PropInfo)));
end
else begin
If Not Assigned(FFixups) then begin
//FFixups:=TLinkedList.Create(TLocalUnresolvedReference);
FFixups:= tlocalfixups.create;
end;
// With tfixups(FFixups).newreference(instance,propinfo) do begin
With TLocalUnresolvedReference(tlocalfixups(FFixups).add) do begin
FInstance:= Instance;
FRoot:= Root;
FPropInfo:= PropInfo;
FRelative:= ReadIdent;
end;
end;
end;
tkInt64{$ifdef FPC}, tkQWord{$endif}:
SetInt64Prop(Instance, PropInfo, ReadInt64);
else
raise EReadError.CreateFmt(SUnknownPropertyType,
[Ord(PropType^.Kind)]);
end;
end;
Fre;D
-
Many thanks
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
> sounds like you need a copy of the files before and after so you can easily diff them and see where the difference is... Are you talking about the .sta file? Good, idea, I will see if it is different at saving. But I have doubt because using a fpc < rev 42375 all is ok, even after saving the .sta file with fpc >= rev 42375. Anyway many thanks for the tip, I will check it. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
On 8/31/19 11:15 AM, fredvs wrote: And rev 42375 was the guilty, before that rev, all is working ok. Do you get a compile error, or do the files no longer read/write properly ? No, no compile error, it is only he files no longer read/write properly. sounds like you need a copy of the files before and after so you can easily diff them and see where the difference is... then you can adjust the code as needed... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
fredvs schrieb am Sa., 31. Aug. 2019, 22:00: > Hello Sven. > > > Just look at the changes: ... > > OK, but before I have to check my stock of aspirin. > I think I'm going to need a lot this time. > > Many thanks Sven to help me in that complete darkness. > Alternatively try alcohol. ;) And I suggest you to extract code into small test programs so that you can test them independently of msegui and play around more easily. Maybe try to retrieve the necessary information yourself without using the msegui code to get a feeling for the RTTI - you'll need it. ;) Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello Sven. > Just look at the changes: ... OK, but before I have to check my stock of aspirin. I think I'm going to need a lot this time. Many thanks Sven to help me in that complete darkness. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Am 31.08.2019 um 18:24 schrieb fredvs: Hello. Type information contains reference to attribute table Old behavior: The first field of the data represented by TTypeData is whatever the sub branch of the case statement for the type contains. New behavior: The first field of the data represented by TTypeData is a reference to the custom attributes that are attributed to the type, only then the type specific fields follow. Reason: Any type can have attributes, so it make sense to provide this is a common location instead of having to parse the different types. Remedy: If you use the records provided by the TypInfo unit no changes should be necessary (same for the Rtti unit). If you directly access the binary data you need handle an additional Pointer field at the beginning of the TTypeData area and possibly correct the alignment for platforms that have strict alignment requirements (e.g. ARM or M68k). Aaargh, it seems that msegui uses direct access so the second remedy is needed. Every advice how to use that remedy, tips where to look, how to do, is, of course, very welcome. Just look at the changes: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/typinfo.pp?r1=42373=42375 If you have code that tries to access the type information you need to take that field into account. Same for properties, where especially this one is important: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/typinfo.pp?r1=42358=42365 When you iterate from one PPropInfo you need to take that into account or use the appropriate functions of the TypInfo unit. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello. > Type information contains reference to attribute table > Old behavior: The first field of the data represented by TTypeData is > whatever the sub branch > of the case statement for the type contains. > New behavior: The first field of the data represented by TTypeData is a > reference to > the custom attributes that are attributed to the type, only then the type > specific fields follow. > Reason: Any type can have attributes, so it make sense to provide this is > a common > location instead of having to parse the different types. > Remedy: >If you use the records provided by the TypInfo unit no changes should be necessary (same for the Rtti unit). > If you directly access the binary data you need handle an additional > Pointer field > at the beginning of the TTypeData area and possibly correct the alignment > for platforms that have > strict alignment requirements (e.g. ARM or M68k). Aaargh, it seems that msegui uses direct access so the second remedy is needed. Every advice how to use that remedy, tips where to look, how to do, is, of course, very welcome. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello Sven. > I assume your code in msegui directly accesses the RTTI instead of using > the types provided by the TypInfo unit. IMHO, after check, it seems that msegui uses the types provided by the TypInfo unit. In each "uses" section of a msegui unit was added "typinfo". So maybe it should be something there that was changed. But if so I do not understand why your commit 42375 breaks compatibility because you did not change anything in typinfo. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello Sven. > I assume your code in msegui directly accesses the RTTI instead of using > the types provided by the TypInfo unit. Ha, ok, I will jump into mse + TypInfo and see what it says. Thanks. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Am 31.08.2019 um 14:31 schrieb fredvs: Hello everybody and specially Sven Barth. With last trunk of fpc, msegui is no more compatible with fpc. After big fight, it appears that commit of Sven Barth on Jul 13 2019, rev 42375 breaks compatibility ---> "as attributes can be part of any type they are best suited in a common part of TTypeData" Could you give some light what to change to restore compatibility? The problems are with loading files, some structure are no more recognized. Note that there are no error message at compilation, nor when loading the files (so difficult to debug). Do you have a plan to give some infos of all what is changed in fpc and how to restore compatibility? https://wiki.freepascal.org/User_Changes_Trunk#Type_information_contains_reference_to_attribute_table I assume your code in msegui directly accesses the RTTI instead of using the types provided by the TypInfo unit. This is bound to break here and then when the RTTI is extended. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
> Yes, but that does not tell me why a change in RTTI info would stop this from working. Same for me, I absolutely dont understand why a change in RTTI info would stop this from working. It is why I did the "explorer" way to debug the problem: doing regression from last fpc trunk until a revision without error appears. And rev 42375 was the guilty, before that rev, all is working ok. > Do you get a compile error, or do the files no longer read/write properly > ? No, no compile error, it is only he files no longer read/write properly. Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
On Sat, 31 Aug 2019, fredvs wrote: What is a sta file ? "sta" file is a stat-like file that contains some infos about msegui widget behavior (and much more if you want). For example you may use mse-sta file as ini (or json) file, used to store parameters of layout of forms of your mse application. You may use also mse-sta files to store db data, it is fast, has seek feature and the mse-sta file is very light in size. Yes, but that does not tell me why a change in RTTI info would stop this from working. Do you get a compile error, or do the files no longer read/write properly ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
> What is a sta file ? "sta" file is a stat-like file that contains some infos about msegui widget behavior (and much more if you want). For example you may use mse-sta file as ini (or json) file, used to store parameters of layout of forms of your mse application. You may use also mse-sta files to store db data, it is fast, has seek feature and the mse-sta file is very light in size. > I know nothing of mse. Hum, you should try it, mse is the best mirror of what fpc can do. ;-) Fre;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
On Sat, 31 Aug 2019, fredvs wrote: Hello Michael. Can you be more precise ? I would like! It appends when reading mse sta files. with that types: tstatreader = class; tstatwriter = class; With rev 42375, some sections of the sta-file are no more recognized, like "layout" section. What is a sta file ? I know nothing of mse. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Hello Michael. > Can you be more precise ? I would like! It appends when reading mse sta files. with that types: tstatreader = class; tstatwriter = class; With rev 42375, some sections of the sta-file are no more recognized, like "layout" section. I have to confess that I am in the dark here, I do not see where to look, what was changed, is it about variable assigned as pointer now, or something else in data structure...? The only concrete thing that I can see is that mseide compiled with last fpc trunk dont load the layouts as wanted. By the way, is there a plan to release fpc 3.2.0. and when? Thanks. Fe;D - Many thanks ;-) -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
On Sat, 31 Aug 2019, fredvs wrote: Hello everybody and specially Sven Barth. With last trunk of fpc, msegui is no more compatible with fpc. After big fight, it appears that commit of Sven Barth on Jul 13 2019, rev 42375 breaks compatibility ---> "as attributes can be part of any type they are best suited in a common part of TTypeData" Could you give some light what to change to restore compatibility? The problems are with loading files, some structure are no more recognized. Can you be more precise ? Directly loading files of such data is not supposed to be supported. They are internal data structures, subject to change at any time. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
