User Changes 2.6.4

From Lazarus wiki
Revision as of 07:39, 6 May 2014 by BigChimp (talk | contribs) (Stringfield type bug)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

English (en) | русский (ru)

About this page

Listed below are intentional changes made to the FPC compiler (2.6.4) since the previous release that may break existing code. The list includes reasons why these changes have been implemented, and suggestions for how you might adapt your code if you find that previously working code has been adversely affected by these recent changes.

All systems

Unit changes


TODBCConnection (odbcconn) No longer autocommit
  • Old behaviour: Autocommit was enabled: Every change was committed to the database at once.
  • New behaviour: Changes must be committed explicitly using Transaction.Commit
  • Reason: Transactions are useless if everything is autocommitted: in particular, rollback is not possible.
  • Remedy: You can enable autocommit by specifying AUTOCOMMIT=1 in the params of TODBCConnection.
TDBF unit deprecation removed
  • Old behaviour: the TDBF units were marked deprecated because the original maintainer of the upstream project stopped maintenance. However, the unit remained in fcl-db and patches were still accepted.
  • New behaviour: the deprecation warning is removed. There is a new upstream project maintainer and FPC database devs support this unit again.
  • Remedy: N/A
MySQL support for transactions added
  • Old behaviour: TMySQLConnection does not have implemented transactions support.
  • New behaviour: Changes must be committed explicitly using Transaction.Commit
  • Remedy: N/A
TStringField types size > 8192 field assignment bug
  • Old behaviour: Assigning data (e.g. with .AsString) to string-type fields (e.g. VARCHAR) of > 8192 bytes worked.
  • New behaviour: String is truncated
  • Reason: Issue #26068
  • Remedy: Workaround in specified bug report

FPCanvas Strikethough property spelling fixed to StrikeThrough

  • Old behaviour: Fonts had a Striketrough property which is a typo.
  • New behaviour: The property has been changed to Strikethrough.
  • Reason: Spelling fix.
  • Remedy: Please rename property calls in your code. FPC 2.6.2 contains both versions so there is a window for adaptation.

shlobj symbols removed from unit Windows

  • Old behaviour: When unit windows was split between the windows and shlobj units, not all shlobj symbols were removed from Windows.
  • New behaviour:
    • Now: the symbols are marked deprecated in the windows unit.
    • Next major version: shlobj symbols will be removed from the windows unit. Code relying on that will fail to compile if it doesn't import shlobj.
  • Reason: shlobj and windows versions were not compatible and lead to errors.
  • Remedy: put shlobj in your uses, if not there already.

StrUtils RomanToInt implementation

  • Old behaviour: Providing an invalid input to RomanToInt would return 0.
  • New behaviour: Providing an invalid input to RomanToInt will raise an EConvert error.
  • Reason: What constitutes "Invalid input" was very arbitrary: only invalid characters constituted an error. Right characters in wrong places would be erroneously translated. Now the implementation has the three usual implementations TryRomanToInt, RomanToIntDef and RomanToInt
  • Remedy: Use RomanToIntDef. The Default value used in case of error is declared with default 0, making the signature and behaviour equivalent to the old function.

Classes.TStringList.InsertItem virtual methods now call eachother

  • Old behaviour: The two InsertItem methods (both Virtual) had their own implementation. This double virtual method is probably an ancient form of default parameter by overloading. If you wanted to override InsertItem, you had to override them both.
  • New behaviour: InsertItem(Index,String) now calls InsertItem(Index,String,nil). This means that users can and should only override the 3 parameter version. In case both methods are overridden, this can lead to duplicate execution of the override code.
  • Reason: Only having to override one method. However this breaks code that overrode both.
  • Remedy: Only override the three parameter version.