Anders Melander

I'm not sure if I understand your UI architecture fully, but here's what I would do: Use actions - always. One actionlist per form/frame. Replace forms with frames if possible. If you're embedding the forms then you should use frames. The form events are convenient but they are meant for more or less autonomous forms. Forms can be embedded but they are not designed to be so. Unlike frames. Move the activation/deactivation logic from the form to the container. Have the container notify the frame when it's activated and deactivated. Disable the frame actionlist when the frame is deactivated. Enable it when it's activated. Might not be necessary though as the actionlist is smart about not handling actions for controls that aren't visible.

No. I don't know you anything about you. I'm arguing the points you make as I understand them. Nothing personal in that. I agree that things could be better (to put it mildly) with regards to the quality of the compiler, the RTL, the VCL and FMX. Is that because Embarcadero is not doing their best? I have no idea. I don't know enough about their financial situation, their business domain, their strategy or most of the factors that must affect their decisions. And I bet you don't either. We all make mistakes and we all write code that could be better. Those that have worked with me know that I have no problem with ripping someone a new a*hole, in public, if they make mistakes because they're lazy or if they don't own up to their mistakes. Like I said I don't know enough about the internals of Embarcadero to judge why they make mistakes, but they certainly could be better at acknowledging them and taking responsibility for them.

True but as I read the documentation, with those settings, all it would take is a system crash at an unfortunate moment. I have not used SQLite3 in productions systems so I don't really know what I'm talking about. Yes, I agree. I missed that point.

Me disagreeing with you or not understanding what your point is, and saying so, is hardly trolling but feel free to ignore me if that's more convenient to you. I don't mind constructive criticism of Delphi, Embarcadero, me or my work at all. I can deal it as good as any, when I get in the mood. But please do try to focus your critique a bit. When you start listing all the things you're upset about about it just become off topic ramblings. I too would like a better compiler and a more optimized RTL, but I do think that the compiler is the more important. The RTL is a general purpose library and as such I expect it to be generally usable but I don't expect it to be optimal. For that would always roll my own. It would be nice if I didn't have to, but I've never used a tool where this wasn't the case. I'm guessing your point here is that they should've acquired RTC instead of Parnassus? Apart from the fact that RTC is a special purpose library (with limited relevance to the majority of Delphi users) while Parnassus is a general use utility, you do realize that acquiring the ownership of a third party product is probably the easiest and cheapest part of the process. The hard part is integrating it into your own product, documenting it and finding the resources to maintain and enhance it. It's sooo easy to sit on the side line and say why didn't they do this and why didn't they do that, when you're not the one responsible for the product. If they bundle Nexus Quality Suite with Delphi (which I wouldn't mind) then it becomes their responsibility to document and support it and to make sure that it works. Hardly comparable to hosting a CodeRage youtube video about Deleaker if that's what you're referring to.

I'm afraid your experience of "professionals" differ from mine. Supposedly the original implementation was written by "professionals".

I disagree. TMonitor is cross platform and the ~16ms timeout granularity is a Windows limitation, which can (but very seldom should) be modified with timeBeginPeriod. It would be better to document the current behavior on Windows - and maybe also why it's there.

And be prepared to lose all your data.

It seems to me that these failures have more to do with the test not properly taking the timer resolution into account, than any possible remaining problems with TMonitor. Like it has already been mentioned it's perfectly normal, and expected, for a wait function to return early: https://docs.microsoft.com/da-dk/windows/win32/sync/wait-functions?redirectedfrom=MSDN#wait-functions-and-time-out-intervals

I would think RTFM is all he needs:

The Old New Thing: Paint messages will come in as fast as you let them

Bad morning? 🙂 On the bright side, and speaking of JIRA, Embarcadero are saints compared to Atlassian. The worst thing you can experience when trying to find out why something doesn't work in an Atlassian product is that it's already been reported and is in their JIRA. Because then you know that it's been there for ten years and will sit there for at least 5 more. Regardless of the thousands of votes and increasingly angry comments. I love the Atlassian stack but GodDamnThemToHell they're slow.

Kudos for that report Stefan. Very well written.

FWIW I missed it too and will have to do a reinstall. I also never install Delphi under Program Files.

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.

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.

You are right about that but they can fix TMonitor (the ABA problem) by using a private, correct implementation of InterlockedCompareExchange128 without breaking DCU compatibility. They could also just implement a temporary fix for InterlockedCompareExchange128 that maintains the incorrect return type (bool) but returns the correct value.

Not fixed in 10.4: InterlockedCompareExchange128 EventCache Push and Pop ABA problem I guess we were too late 😞

It depends. Next question.

Which the TPicture.Graphic help also clearly state: ...and the TPicture.Assign help is also pretty clear:

I think you are. You are not presenting the subject in a neutral way and your arguments are all over the place. I'm not biting.

One important thing to keep in mind is that once a customer (i.e. a subscriber) becomes a non-customer, then you have to get rid of any identifying data. Anonymizing the data is Okay. Basically you must not store any personal data that is not vital to servicing the customer. Even if the data is "nice to have", might come in handy or whatever. Exactly. GDPR is not something you ask to have explained in some forum. You need to read up on and understand the issues involved because it's your responsibility to make your software compliant.

Yes, so you can revert your change in RSP-28272. They copy the result back to the ComparandResult parameter (or rather the 128 bit value it points to). See the InterlockedCompareExchange128 documentation: Because the stress test does not use return value in the ComparandResult parameter. My test code (see an earlier post) includes a test of InterlockedCompareExchange128 which does validate that ComparandResult is set correctly.

Thanks for the update. Note that more threads does not necessarily result in a higher likelihood of failure. More threads means more overhead (context switching and so on) and less time spent actually exercising the code we want to test. I think the the goal should be to loop as fast as possible (i.e. perform as many operations as possible), utilizing all available CPUs, with as few context switches and as little kernel mode as possible.

Is something preventing you from posting a minimal project that reproduces the problem, so we can avoid this pointless guesswork?