Porting XE3 apps to XE4

Porting XE3 apps to XE4

Work in progress…

Will add comments as I find stuff that breaks.

21 thoughts on “Porting XE3 apps to XE4


  1. #1 [dcc32 Fatal Error] PSDBase.pas(4003): F2084 Internal Error: C1769


    Cause: “ad hoc” declaration of generic class?


    TSomeClass = class


      FDict: TDictionary; 


    property Dict: TDictionary;


    end;




    i := SomeClassInstance.Dict.Items[ix].BaseClassFunction;  // <– error


    Workaround:


    TDictClass = class(TDictionary<Integer, TBaseClass)


      function WrapperFunction(const ix: Integer):Integer;


    end;


    TSomeClass = class


      FDict: TDictClass 


    property Dict: TDictClass;


    end;




    TDictClass.WrapperFunction(const ix: Integer):Integer;


    var


      BaseClass: TBaseClass;


    begin


      BaseClass := Items[ix] as TBaseClass;


      Result := BaseClass.BaseClassFunction;


    end;




    i := SomeClassInstance.Dict.WrapperFunction(ix);  


        


  2. #2 [dcc32 Fatal Error] PSDListViewSelection.pas(945): F2084 Internal Error: G9874


    Interesting!


    Cause: Assigning a different generic list type?  Worked in XE3.


    TSomeClass = class


    strict private


      FList : TList;




    constructor TSomeClass.Create;


    begin


      Inherited


      FList := TObjectList.Create;  // <- Internal error


  3. #3 Indy events ><


    Had to add idGlobal to unit.


    Had to change event handler from


    procedure TServerPingThread.OnReceiverRead(


      AThread: TIdUDPListenerThread;


      AData: array of Byte;


      ABinding: TIdSocketHandle);


    to


    procedure TServerPingThread.OnReceiverRead(


      AThread: TIdUDPListenerThread;


      const AData: TidBytes;


      ABinding: TIdSocketHandle);


    and all TBytes references from TBytes to TidBytes.


  4. #4 Projects really don’t like units that have not been added to the project – which I think is a good thing.


    I’m an idiot.  Missing semicolon in Library path made the units disappear 😛


  5. Do you mean that if you have a library with 100 units, of which only 1 is in your uses (and which uses the 99 other units), you have to place the 100 units in the project?


  6. #5: [dcc32 Warning] PSDLocation.pas(620): W1057 Implicit string cast from ‘RawByteString’ to ‘string’


    Cause:


      RegEx.RegEx := UTF8Encode(Loc.NetworkRegExp);


    Workaround – what do I do?


    Opting for:


      RegEx.RegEx := String(UTF8Encode(Loc.NetworkRegExp));


  7. #6 [dcc32 Warning] PSDReceiveGoodsHTTPServer.pas(1476): W1000 Symbol ‘ToUpper’ is deprecated: ‘Use TCharHelper’


    Cause


      BooleanVar := (ToUpper(HTML.ParamValue[‘unknownlot’]) = ‘ON’);


    Breaking change:


      BooleanVar := (HTML.ParamValue[‘unknownlot’].ToUpper = ‘ON’);


  8. Eric Grange  Not entirely sure, but it certainly looks that way. Don’t know if there is a difference between units referred in the Interface section vs Implementation section.


  9. Eric Grange / Heinz Toskano – Ref. Unit inclusion in project.


    I’m an idiot.  It was a missing semicolon in the Library path that made one of my $(COMMON) directories “disappear”.


  10. There – now it all builds without hints and warnings.


    So – how are the statistics?


    96 units in total


    2 had Generics related internal errors 


    3 units had “deprecated” warnings – which require breaking changes to suppress.


    – StrPas / StrCopy / StrPLCopy has moved to AnsiStrings unit


    – Indy: TBytes ->TIdBytes


    – ToUpper(str) -> str.ToUpper


    1 unit had a result type change causing a implicit cast warning


    – Non breaking: UTF8Encode -> String(UTF8Encode)


    Less than 40 lines of change – including a small rewrite to work around the Generics Internal Error – out of about 200.000 lines of code.


    Not too bad – but – breaking changes are still breaking.

Leave a Reply