Leaderboard

And I still think Idera has the math all wrong. If they sold Delphi Developer at 1/3 the current price, I believe they'd more than triple their sales. As a hobby developer I'd be prepared to spend that instead of using the CE, which I'm currently using. Edit: At the very least Idera should do some market research and ask CE users what they'd be prepared to spend for the Developer edition. Heaven forbid, they might even attract some new developers instead of just bleeding their current user base.

Hi, Sherlock, I disagree with you. I don't think styles are a toy or a waste of EMB time and money. Styles are a necessary tool to allow us developers to modify our apps. I agree that massive changes are ill-advised and will confuse the user. But many modern apps (including the IDE) have a dark mode, which is what we are using styles for. We're not going to make massive changes to the UI that would confuse the user.

It shouldn't work, though. This is just straight up undefined behavior, since the TMemo.Lines property does not point at a TStringList object, it points at a TMemoStrings object instead. And TSStringList overrides Add() whereas TMemoStrings does not, so even the vtable contents are different. Don't write code like this. The correct solution is to make FillStrings() take a TStrings instead: function FillStrings(aStrings: TStrings): boolean; begin aStrings.Add('a'); aStrings.Add('b'); end; ... FillStrings(Memo1.Lines); Correct, because FillStrings() expects a TStringList specifically, not a TStrings generally. Nope. Nope.

We still don't realize what exactly the asker intends to achieve 🙂

Grijjy have a wrapper for the ZeroMQ Majordomo protocol at https://github.com/grijjy/DelphiZeroMQ. There's a lot of reading to do if you want to learn all about ZeroMQ, but Grijjy supply a simple Client, Worker and Broker to start from, which work 'out-of-the-box'. The advantage to using a Broker app is that you do not have to sniff around to discover everyone's IP address; each party registers their name and role with the broker and then the broker ensures that messages can be sent to and from each named entity. You can also combine this with Grijjy's 'protocol buffers' to send almost any type of data that the sender and recipient apps agree upon. I have started to explore this myself and have not yet discovered any major snags.

No need to export anything - JIRA has excellent charting - examples:

I didn't make a claim. I asked a question. You answered. I asked if there was a mathematical proof that supported your answer. The other thread I mentioned seems to indicate that prime sizes have a purpose, so I'd like to understand. This is off topic for this thread, so please respond in the other thread or in DM.

The capacity implementation of the RTL dictionary is a bit stupid. Typically the capacity is the number of items you can store in a collection without a reallocation/grow happening. However that is not the case here (in Spring4D we actually implemented it that way - so if you want to store 100 items without a grow happening you pass capacity 100 - the internal mechanism handles overallocating to satisfy the max fill factor). The RTL implementation takes the passed value, calculates the next power of 2 greater than the passed value, allocates as many buckets and sets the grow threshold to 75% of that value. In the benchmark code above that means from the passed 200 it calculates 256 and sets the threshold to 192 which means you can store 192 items before it will grow.