Lars Fosdal

TBH, I am not sure that can be implemented without either digging into the debugger or using techniques like those in EurekaLog where it appears they inject their own exception class that is thread aware? It was more of a wish list for the debugger team, than for GExperts.

I'd like "Disable break on exception this thread" "Disable break on exception in other threads" - limiting the breaks to the current thread or threads spawned in the current thread.

Neat! Did it survive patch 2?

Indeed. Such a warning should also apply to parameters and local variables. program WhyNotWith; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; type TParam = class private FBar: Integer; FFoo: Integer; public constructor Create; virtual; property Foo: Integer read FFoo write FFoo; property Bar: Integer read FBar write FBar; procedure Dump(const Title: string); end; TOuter = class(TParam) public constructor Create; override; procedure Process(const Param: TParam; var Bar: Integer); end; { TOuter } constructor TOuter.Create; begin Inherited; end; // No warnings to be seen procedure TOuter.Process(const Param: TParam; var Bar: Integer); var Foo: Integer; begin Foo := 0; Bar := 7; With Param do begin Bar := Bar * Bar; Foo := Foo + Bar; end; Writeln('Process', ' Foo:', Foo, ' Bar:', Bar); end; { TParam } constructor TParam.Create; begin Foo := 2; Bar := 5; end; procedure TParam.Dump(const Title: string); begin Writeln(Title, ' Foo:', Foo, ' Bar:', Bar); end; procedure Test; var Param: TParam; Outer: TOuter; Bar: Integer; begin Bar := 9; Param := TParam.Create; Outer := TOuter.Create; Outer.Process(Param, Bar); Param.Dump('Param'); Outer.Dump('Outer'); Writeln('Bar ', Bar); end; begin try try Test; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; finally Write('Press Enter: '); Readln; end; end.

It doesn't need to be complicated. If the type of the variable you reference by with contains a field or property that has the same name as a local field or property - you do not get a hint or a warning, but the property set will be the on the with reference, not on the class instance doing the with reference.

"over there"? Huh? What? I give up.

Are you able to compile a fresh new FMX project? If you compare the project file between the old project and the new one, are there any discrepancies that stand out?

The actual compiler output after your changes in the second post would be informative. If they are just "cannot resolve" errors, you need to check your .dproj file for invalid paths

Details are important. Without accurate details, you might as well be posting "something is wrong".

...ponders if he should guess what kind of error, but decides not to...

I very rarely use with. Too many pitfalls.

Have a good vacation and stay healthy.

That is still very much an open-ended question, especially if you consider the power of the Mac Pro. https://www.theverge.com/2020/6/23/21296365/apple-mac-arm-processor-silicon-chips-performance-power-speed-wwdc-2020

ARM is an architecture, not a brand. The Apple chips are ARM based.

OMG, Yes!

Well, the next MacBook Pro will be ARM64. If that exercise works out, will any of the Macs remain x64? There already is a Windows for ARM64. The only constant is change.

Like the rest of us. Meanwhile, we make the best of it until we or it retires.

A language dies when it is no longer in use. COBOL is alive and kicking, but good luck finding young COBOL programmers. There is no shortage of things that can be improved in Delphi. I wish they would do more with the language. Especially generics constraints need more love. Attributes are still somewhat half-baked. I wish they would do more to improve the generated code for efficient memory access and math / vector math. I'd love an ARM64 compiler for Windows, as well as Linux/R pie. I wish the debuggers just worked and kept working and were smarter with regards to multi-threaded code. I wish the IDE would do incremental background compilation so that running your edited code was near instantaneous. But, in the mean time I code... And rant.

As I said, they need to spend more resources on testing.

I agree, it is not something you easily add as an afterthought. That said, when modifying or refactoring legacy code - unit testing and integration testing is more than a little helpful. Testing is the only way to ensure that you have achieved only the changes you intended and haven't inadvertently introduced something unfortunate. When writing new code, writing unit tests helps you write testable code. It is extra work, but it really pays off.

When you sit on millions of lines of code, in projects with several developers, implementing thousands of functions, and integrating with numerous systems, you need automated unit testing, automated integration testing and dedicated testers with proper test plans. We are not talking about one-man toy projects here.

We usually hold off moving to new major versions until Update 1 is out, but we do make the move. As far as I am aware, nobody on my team has ever had a problem with moving their IDEs to new hardware after XE4, and we use the regular named user licenses w/o any license server. Apart from the quality of the initial release, my biggest Idera/EMBT gripe at the moment is understanding why the f..k they keep spamming me with emails suggesting that I order 10.4 with a discount. Not only do I get these from EMBT, but also from the local reseller. I am on a subscription, FFS!

IMO, the development resources are probably sufficient, but as for most organizations, there simply isn't enough resource dedicated to testing - manual or automated.

That reminded me of

If you cannot say more, you should not have said anything in the first place, IMO. If you are making statements based on "private" information, you are betraying someone's trust. Nothing constructive comes from posts like these. None of the commentary here will affect Idera/Embarcadero's way of doing business what so ever.