Lars Fosdal

It was not the history folders that I meant. It is the list of files under File | Recent Files. Naturally, I exclude the IDE history folders from VCS.

Several. https://git-scm.com/download/gui/windows

From the other thread FWIW, we don't use the built-in version control integration in Delphi. We tried way back when it was new, but it just didn't work out for us as it didn't allow merges. We use TortoiseSVN, Github Desktop/SourceTree. Update from repository, start Delphi, do the work, exit Delphi, Commit, Merge if necessary. I am a creature of habit, so I have a root checkout folder: C:\src\Programs This contains the branch of my apps that I am currently working on i.e. typicallly trunk in SVN speak, or dev in git terms. C:\src\Programs\App1 C:\src\Programs\App2 C:\src\Programs\App3 C:\src\Programs\Common etc. I also have other versions in separate folders that I update regularily C:\src\Programs.Live C:\src\Programs.Pilot C:\src\Programs.Trunk C:\src\Programs.ThatVersionThatNeverGotReleased If I need to work on f.x. the Live branch, I used the Switch feature in Tortoise to switch the branch in C:\src\Programs. Why don't I just work with the files in their respective check-out folders? Because of Delphi file history. It is so freaking annoying to open a file from the history list and get a file from the wrong folder. With SVN, I commit my changes from C:\src\Programs, and if the changes also should be merged with a different branch, like f.x. Live - I ensure that folder is updated, and merge to it, and then commit it. We are going to make a move to using git for everything, but we are still trying to come up with a robust and easy to use workflow. Git is a little more finickey for us long time SVN users.

Why revision control... - Tracking changes - what is the change history of a unit? (Yes, you SHOULD write commit comments) - Comparing changes between current version with any previous version - Comparing changes between any previous version and another previous version - Automatic merging - ensuring that every little change makes into the other branch - Rolling back to a previous version if your changes turned out to be crap - Linking code changes to your issue management system such as Jira All at a click of a button, no manual tinkering, and not requiring multiple team members Taking it one step further - using f.x. Continua CI which is available in a free version limited to one task at a time, every time you commit a change, you can - Automatically build of each of the changed branches - Automatically run unit tests and integration tests - Automatically do translations, code signing, packaging, deployment to wherever you need to deploy - Export snapshots to your offsite backup system Yes, you can do manual zip archiving of code revisions - but man, they invented the wheel!

We use frames extensively in one of our UI apps, and I've made a FrameTestBench app that has the required plumbing of the main app, but which only instantiates the frame I want to work on. It reduces the compile time a lot. But - as everybody else says - using revision control really is essential. Once the frame "graduates" from the test bench and needs to go into the main app for further testing, I don't want to have that happen in the current live branch since I may need to do fixes in that branch before the new frame is ready for release.

Definitively changes to Notifications from a user perspective, but I can't find any docs with regards to notification API changes. https://news.softpedia.com/news/windows-10-version-2004-new-options-for-managing-app-notifications-530012.shtml Edit: Can it be a permission thing? Do you have to enable notifications explicitly for your FMX app in the Windows 2004 Notification settings?

Add a Caption: string to TResult and try again. It will set TResult.Caption to A, and you get no hint or warning that there is a name space collision. Using inline variable declarations - you can eliminate with without a lot of extra code. procedure TForm1.FormCreate(Sender: TObject); begin var r := GetResult; Caption := r.A; end; var p := GetComponent as TPanel;

I will do that.

What about the queries that provide the data to the report - are they fast if they are run stand alone?

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.