Cristian Peța 122 Posted Wednesday at 01:31 PM (edited) Using arrRect.SetBounds() you avoid a call to AlignObjects because TControl.SetBounds is checking some things before a call to AlignObjects Avoid setting TPosition.X Edited Wednesday at 01:32 PM by Cristian Peța Share this post Link to post
domus 2 Posted Wednesday at 01:33 PM 1 minute ago, Cristian Peța said: Avoid setting TPosition.X No kidding! Share this post Link to post
Patrick PREMARTIN 141 Posted Wednesday at 06:05 PM 4 hours ago, Cristian Peța said: Using arrRect.SetBounds() you avoid a call to AlignObjects because TControl.SetBounds is checking some things before a call to AlignObjects Avoid setting TPosition.X Thanks @Cristian Peța I've updated my sample project on https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-3711 Hope they found a way to optimize this for 13. 2 Share this post Link to post
Cristian Peța 122 Posted 21 hours ago Just wanted to try a fix in FMX.Forms and I found it already there but commented 🤔. First two lines will exit and AlignObjects() will not be called if used Form.BeginUpdate. The Realign will be done anyway after Form.EndUpdate. procedure TCustomForm.Realign; begin // if FDisableAlign or (FUpdating > 0) then // Exit; ... more code if FCanvas <> nil then begin AlignObjects(Self, Padding, FCanvas.Width, FCanvas.Height, FLastWidth, FLastHeight, FDisableAlign); RecalcControlsUpdateRect; InvalidateRect(ClientRect); end; end; Share this post Link to post
domus 2 Posted 21 hours ago Now, that's odd. As if someone forgot to uncomment before release... Share this post Link to post
Cristian Peța 122 Posted 21 hours ago I updated the report https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-3711 2 1 Share this post Link to post
Lajos Juhász 322 Posted 4 hours ago Maybe it is commented out to fix some strange issue/bug. In that case the developer that has commented out the code should include the report number in the comment to document the change in behavior. Share this post Link to post
Patrick PREMARTIN 141 Posted 3 hours ago (edited) 40 minutes ago, Lajos Juhász said: Maybe it is commented out to fix some strange issue/bug. In that case the developer that has commented out the code should include the report number in the comment to document the change in behavior. It's probably done on the commit comment with an internal ticket number. No reason to put it in the source file on the comment visible by the public (= us). Edited 3 hours ago by Patrick PREMARTIN Share this post Link to post
Lajos Juhász 322 Posted 3 hours ago 37 minutes ago, Patrick PREMARTIN said: It's probably done on the commit comment with an internal ticket number. No reason to put it in the source file on the comment visible by the public (= us). Most probably yes. It would be easier if we could get that information. I do hate when on codebase I am working on changes like this does not have a comment with a proper description or ticket number. Searching in repository for the specific change can be time consuming. Share this post Link to post