David Heffernan

Silent failure as you propose does not seem very useful to me. Surely better to use RaiseLastOSError in case an API call fails.

Why did you decide that 2 is the answer?

Hmm, rather perplexing conclusion. How did you arrive at it?

https://stackoverflow.com/q/11785963/505088

You might consider buying the book if you want it.

No need to hook anything. And in any case, what would you hook? Every process in the entire system? The system raises WMI events when processes are created and destroyed. https://stackoverflow.com/questions/47147099/is-there-a-way-to-recieve-a-event-about-a-process-starting-in-windows

This looks mighty cool. Kudos to you once again. In my codebase at work we use an in-house bespoke wrapper of libyaml. The big difference from yours, I suspect, is that we needed to support very large files, and opted for a SAX type interface.

But actually, that turns out to be completely wrong. At least in XE7 malloc is implemented as function malloc(size: size_t): Pointer; cdecl; begin Result := AllocMem(size); end; which is pretty lame because AllocMem is zeroising the memory. And potentially throwing an exception. So, a somewhat bogus attempt to implement malloc. Perhaps what is really going on is that GetMemory is the function that you need to call if you want to allow GetMemory(0) to return a pointer to a block of memory, ie. that GetMemory(0) <> nil. But I'm not convinced by that either since the C standard demands that malloc(0) returns a value that cannot be dereferenced, which may or may not be null. Or perhaps it is just a function that returns nil in case of error rather than raising an exception.

I'd read that as "GetMemory exists so that the Crtl unit can implement malloc".

Sure, if you ask for an audit, then you want to see the outcome no matter what. But a program that yaps when it manages the to successfully save a file is poor UI. In fact, I've never ever seen such a program.

Much more valuable is not to show any dialog at all and not to ask them to make a choice about whether they want to see it, and just have the program do the right thing.

Last thing I want to see from an application is a modal dialog telling me that the app just did what I told it to.

You can read the C standard to find out how it handles that enum. Then double check with a compiler. I mean you surely aren't going to commit this without double checking with a C compiler?

So TParallel doesn't service the synchronize queue?

As for that zip file, you synchronise the pop but not the push. Anyway, replace the code with a lock and take it from there.

There are other forms of locks that you might use. For cross platform code you'd use a monitor.

It could still be related to the code that you have, which we don't have. Anyway, it's a bad idea to force the code onto the main thread just to serialise it. Use a lock instead.

Hard to say with incomplete code. We can only guess as to what PopNode and PushNode do, not to mention the code that operates on the nodes.

Type that word into Internet search engine.....

Put madExcept in the IDE via a package and then use madTraceProcess to find out what it is doing whilst saving.

The classic way to do that is a page control where every tab has TabVisible set to False

Antagonising your customers and making them hate you is never a good business plan.

If this is true, you can't even buy what they claim you need. You have to purchase new licences. You can't purchase maintenence once it has expired.

The component vendor is applying a development methodology known as "wishful thinking". FastMM4 doesn't get this wrong.

The reason you don't call FileExists is that CreateFile will fail and GetLastError will tell you that the file does not exist. You have tell us why you believe that CreateFile should fail in the scenario that concerns you. Another program already opened the file? With what flags? Rather than have us spend time trying to guess how to recreate the problem, can you provide a complete console app that reproduces the issue.