Wagner Landgraf 43 Posted May 27, 2020 Share here what you liked the most about 10.4 Sydney, be it new features or bug fixes you were waiting for. For issues and complains, use this topic: https://en.delphipraxis.net/topic/2885-your-rad-studio-104-sydney-issues/ Share this post Link to post
Lars Fosdal 1792 Posted May 27, 2020 The new Error Insight is GREAT! It works really well! After years of red squigglies for things that are not wrong, it is really nice to only see squigglies when something actually is wrong. 6 Share this post Link to post
Dalija Prasnikar 1396 Posted May 27, 2020 This one is rather important fix - it is fixed for both LSP and Classic Code Insight Code completion does not work inside anonymous methods https://quality.embarcadero.com/browse/RSP-23252 2 Share this post Link to post
pyscripter 689 Posted May 28, 2020 (edited) Right now the quality portal is updated at a frenetic rate. There was a very large number of fixes, I think more than in any other previous version, and I was quite pleased that quite a few of my reports have been resolved, some of the unexpectedly: System.AnsiStrings AdjustLineBreaks not exported Memory leak in TInvokeableVariantType.DispInvoke Optimize TInvokeableVariantType.DispInvoke Wrongly premultiplied TWICImage when assigning a Bitmap with aDefined TButtonedEdit is not styled properly System.Threading got some attention with the famous Cancel and Wait issue resolved. Issues I would like to see fixed now and consider critical are: TThreadedQueue and TMonitor issue, possible solution InterlockedCompareExchange128 doesn't restore RBX Threading - Incorrect calculation of IdleWorkerThreadCount Edited May 28, 2020 by pyscripter 1 Share this post Link to post
pyscripter 689 Posted May 28, 2020 (edited) Also the improvements in Vcl.Styles and DPI awareness are welcome. There are still a few outstanding issues: InputQuery scaling and styling issues Styled menus DPI scaling TCustomizeDlg not fully VCL styled Edited May 28, 2020 by pyscripter Share this post Link to post
Tommi Prami 130 Posted May 28, 2020 I am pretty interested in hearing what are people thinking of implementing with Managed records. -Tee- Share this post Link to post
David Heffernan 2345 Posted May 28, 2020 6 hours ago, pyscripter said: Right now the quality portal is updated at a frenetic rate. There was a very large number of fixes, I think more than in any other previous version, and I was quite pleased that quite a few of my reports have been resolved, some of the unexpectedly: System.AnsiStrings AdjustLineBreaks not exported Memory leak in TInvokeableVariantType.DispInvoke Optimize TInvokeableVariantType.DispInvoke Wrongly premultiplied TWICImage when assigning a Bitmap with aDefined TButtonedEdit is not styled properly System.Threading got some attention with the famous Cancel and Wait issue resolved. Issues I would like to see fixed now and consider critical are: TThreadedQueue and TMonitor issue, possible solution InterlockedCompareExchange128 doesn't restore RBX Threading - Incorrect calculation of IdleWorkerThreadCount On the plus side these can be readily fixed yourself for your programs. I mean, I've been running with a patched RTL for years that fixes all the design flaws in handling of floating point control flags. At least we have access to the RTL source code and so can apply fixes easily using code hooks. Share this post Link to post
pyscripter 689 Posted May 28, 2020 (edited) 4 hours ago, Tommi Prami said: I am pretty interested in hearing what are people thinking of implementing with Managed records. -Tee- I think there is a serious issue with the timing of finalization of temp managed records which now is ASAP unlike regular records. Please see Timing of finalization of temporary managed records I would love to hear what the experts think about this. @Stefan Glienke @David Heffernan @Marco Cantu etc. Edited May 28, 2020 by pyscripter Share this post Link to post
Stefan Glienke 2002 Posted May 28, 2020 (edited) @pyscripter Looks weird given how other managed types lifetimes are being handled - but since we don't have precise language and design specs as always we can just guess. Apart from that implementing smartpointer that way is wrong anyway because they break whenever there is an explicit or implicit assignment/copy going on. Proper smartpointer need a shared block that holds a reference counter. Shared<T> in Spring is implemented with several optimizations to avoid the overhead of object creation for this purpose using the all known "interface in record" approach and I challenge everyone to come up with a robust implementation using custom managed records to beat that. Edited May 28, 2020 by Stefan Glienke 1 2 Share this post Link to post
Anders Melander 1783 Posted May 28, 2020 1 hour ago, pyscripter said: I think there is a serious issue with the timing of finalization of temp managed records which now is ASAP unlike regular records. I actually prefer that finalization style over the way interfaces etc. are finalized. At least this is by design while the old style seems more like a side effect of an implementation detail. I've always had a problem with this: var Foo: IUnknown; begin Foo := TInterfacedObject.Create as IUnknown; ...some code here... Foo := nil; // This doesn't destroy the object ...more code here... end; // but this does I've not tried it but from the comment by Chee Wee Chua on RSP-28520 is seems I could solve it with a managed record inside a local block. Share this post Link to post
pyscripter 689 Posted May 28, 2020 (edited) 17 minutes ago, Anders Melander said: I actually prefer that finalization style over the way interfaces etc. are finalized. At least this is by design while the old style seems more like a side effect of an implementation detail. I've always had a problem with this: var Foo: IUnknown; begin Foo := TInterfacedObject.Create as IUnknown; ...some code here... Foo := nil; // This doesn't destroy the object ...more code here... end; // but this does I've not tried it but from the comment by Chee Wee Chua on RSP-28520 is seems I could solve it with a managed record inside a local block. Your example is not correct: Try: program Scope; {$APPTYPE CONSOLE} uses System.SysUtils, System.Classes; type TTestScope = class(TInterfacedObject) destructor Destroy; override; end; { TTestScope } destructor TTestScope.Destroy; begin WriteLn('Gone'); inherited; end; procedure Test; var Foo: IUnknown; begin Foo := TTestScope.Create as IUnknown; WriteLn('Do stuff'); Foo := nil; // This does destroy the object WriteLn('Do more stuff'); end; begin Test(); ReadLn; end. Output: Do stuff Gone Do more stuff Edited May 28, 2020 by pyscripter 3 Share this post Link to post
pyscripter 689 Posted May 28, 2020 (edited) @Anders Melander The general rule that has always applied is that managed types (strings, interfaces, records with managed fields, dynamic arrays, etc,) are finalized at the end of the scope in which they are introduced. This included temp variables. The newly introduced managed records breaks this rule. Whether you like it better or not, it is inconsistent. And a local block does not solve the problem. The temp managed record will still self-destruct at the end of the statement it is used. Edited May 28, 2020 by pyscripter Share this post Link to post
Anders Melander 1783 Posted May 28, 2020 6 hours ago, pyscripter said: Your example is not correct You're right. I tried to simplify the problem and simplified it so much that the problem didn't occur. The actual problem I'm having is with factory methods that returns an interface; A common example is an implementation of the memento pattern that changes the current cursor and restores it when the memento is destroyed: begin SaveCursor(crHourGlass); ...do stuff... end; // Cursor is restored here Works great, but occasionally I want to restore the cursor before the end of the block so I do like this: var SavedCursor: ICursorRecall; begin SavedCursor := SaveCursor(crHourGlass); ...do stuff... SaveCursor := nil; ...do more stuff... end; // cursor is still restored here It's been my understanding that this was caused by a hidden temporary variable that is created by the compiler when you call a function returning an interface, and I've just learned to live with it. The strange thing is that it doesn't always behave like this. Simple cases, like the example above, probably works as expected (i.e. nilling the reference destroys the object), but in more complex code the object is only destroyed when the reference goes out of scope. Share this post Link to post
Guest Posted May 29, 2020 Hide feeds! This was a button in Tokyo and i had to press it each time i started the IDE (and restart and restart). In Sydney it is a link in the bottom and the click on that link is persisted! Neat-o. /D Share this post Link to post
mvanrijnen 123 Posted May 29, 2020 I like the record initialziation/finalization, but i was working on something i can use it for, and got this: procedure THSNullableBooleanSerializer.Serialize(const AValue; const AWriter: IgoBsonBaseWriter); var jsonvalue : THSNullableBoolean absolute AValue; begin // do stuff end; [dcc32 Error] HESI.NullableTypes.pas(158): E2634 Declaring a managed record with absolute directive is not allowed hmz, to bad .... Share this post Link to post