Anders Melander

In my example there's already room for 65 characters in the destination since Delphi strings have an implicit null terminator.

I can't tell from the documentation if SetString copies up to Length characters or always Length characters and it seems to be an intrinsic function so I can't check the source.

You need to use StrLCopy instead of StrPas since there's no guarantee that the source string is null terminated. You actually need a StrLPas function but fo some reason they've never implemented that variant. Also remember that the buffer is a static array[] of Char[0..63] so you need to iterate the outer array somehow. var Buffer: PChar; GetMem(Buffer, PaperCount*SizeOf(Char)); try var p := Buffer; for i := 0 to PaperCount-1 do begin var PaperName: string; SetLength(PaperName, 64); StrLCopy(PChar(PaperName), p, 64); PaperName := PChar(PaperName); // or SetLength(PaperName, StrLen(PChar(PaperName))) ... Inc(p, 64); end; finally FreeMem(Buffer); end;

I haven't used IB in ages but as far as I can tell you can configure it to log query execution to disk. I have no idea what kind of output it produces. What I used to do when I had problems with slow queries was to just look at their plan to see if it matched my expectations. I used Craig Stuntz' free Planalyzer for that but I don't know if it works with current version of IB. I guess all the current commercial tools have similar features. Of course examining the plan requires that you already know which queries to look at but, assuming you can reproduce the problem, you can use the performance monitor to identify those.

If your post isn't meant as trolling then you should phrase your statements in a different way. If you do not want people to respond to your post then you should post it on one-way broadcast media instead. /ignore

I don't quite agree with that. Yes, it shouldn't be your primary source of implementation bugs but presumably the additional resources the testers represent will result in more bugs found. I can't see why that's a bad thing. My experience with the Delphi betas is that at the time they start, the design is already set in stone. My experience is also that the majority of beta tester aren't really qualified to give usable feedback on design and architecture. Things may have improved though.

http://docwiki.embarcadero.com/InterBase/2020/en/InterBase_Performance_Monitor_Window

What entitles you to be the judge of that? I don't think I have ever seen David "discipline" anyone (himself included) that didn't deserve it.

That is some really bad advice. https://devblogs.microsoft.com/oldnewthing/20070219-00/?p=27963 (read all 4 articles in the series)

Show me some evidence based on measurements.

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.