Lars Fosdal

What other things than the refactoring code is .NET dependent in the IDE?

If I can avoid it, and I usually can, I do not modify third party code. It adds to the maintenance burden.

Remember to start an elevated CMD before running the patch bat file.

Basically, this case needs the nullable types that we have been promised for some time.

Having proper logging of the context of the error is a must - but if they are routinely producing crap data, and rarely take corrective action - the problem definitively is upstream. A specification must exist that describes the appropriate action on erroneous data. Having worked with live data from external sources all my life, I can say with some weight that replacing erroneous data with "neutral/zero" data can have negative effects downstream. There is no joke in the old saying: Garbage in, garbage out. Without knowing the nature of the data, I would say that the only viable option with regards to simply halting, would be to omit import of data that fails validation and instead properly log what fails. The problem here is how much will need to be discarded. This is something that needs to be agreed on. Example for data that are hierarchical: Orders can have a order head, one or more delivery heads, with one or more order lines. If one order line fails, do you fail just that delivery and its order lines, or the entire order? If a delivery head fails, do you fail just that delivery and its order lines, or the entire order? If the order head fails, are you able to eliminate all the deliveries and order lines? Example of data that are sequential: If each line is a time series item, and one line in the series fails - do you fail just that line or the entire series?

We are fighting a memory leak, but neither FastMM nor EurekaLog reports what is leaking. This is a service without a GUI, which uses COM objects, sockets and FireDAC databases. Is there a non-UI FastMMUsageTracker anywhere that could shine light on if this is a fragmentation issue? Are there other things that I should be looking at using?

We don't use direct Windows heap allocations at all. Nor do we use C DLLs. I starting to suspect that we have stale objects lingering in lists, which gets cleared at app exit - hence no leaks.

Both report something, but it is just a few K data which are all known leaks related to startup configuration.

1) The COM objects are ancient and provided by the ERP system. No new versions have been introduced for years. We have very little code that uses interfaces. 2) We have an object hierarchy that tracks allocations and deallocations - and on app close, we report the stuff that has not been properly disposed of. There is nothing in the list that stands out as gobbling memory. 3) I am familiar with tools for inspecting memory, but there are simply so much movement in memory that it is not viable. 4) We are logging threadid and FastMM allocation size throughout the logfile. using this function function MemoryUsed: cardinal; inline; var MMS: TMemoryManagerState; Block: TSmallBlockTypeState; begin GetMemoryManagerState(MMS); Result := MMS.TotalAllocatedMediumBlockSize + MMS.TotalAllocatedLargeBlockSize; for Block in MMS.SmallBlockTypeStates do Result := Result + (Block.UseableBlockSize * Block.AllocatedBlockCount); end; LineNo {Time (ThreadId) Memory} Logged text 4331737 {10:44:39,145 (10488) 970150k} TPSDTask_HandleServerNotifications - End (id:113072) The allocated memory that FastMM reports stays approx in tune with what the system reports. 5) We use TObjectList<T> - not arrays, and mostly for actual objects. We have control over initial size and growth strategy, and adapt it to the respective usages by overriding virtual methods. function TPSDBaseList<T>.DefaultCapacity: Integer; begin Result := 32; end; function TPSDBaseList<T>.DefaultGrowBy: Integer; begin Result := 32; end; It seems that the problem appeared when we started using 10.3.3 - but then again - we made a LOT of other changes for that release, so it may not be relevant.

So, some input is invalid. What would you put instead of that corrupt value? Are the data line by line? Is there a sequence among those lines that gives interdependency (f.x. main/detail, header/line, etc)? Can you skip a line without corrupting the import? I agree that the specification should contain instructions on handling empty or invalid fields. If it doesn't - letting it crash and burn and returning that fact to the client is appropriate.

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.