David Heffernan

Selecting text in an edit control is for sure a use case where this is needed.

Amazing work. Well done!! Thank you. Although it can't be compiled in older versions, presumably it works with programs built with older versions of Delphi? And do you have plans to support 64 bit?

I don't think this is true. TEdit is the Win32 EDIT control. What are you doing with strings that need to know what you are asking about? What's your usage scenario?

Why would you need to know this, unless you are rendering the text

Isn't that going to claim a global lock 31 times?

Put the labels in an array, and then access them by index, or Use a single label, and include linebreaks in the caption, or Create the labels dynamically, or Probably some other solutions that I have not thought of.

It's always a good idea to minimise contention on process wide locks, which is why it is best not to call SetLength over and over when that can readily be avoided.

Thus can't work. You need both sides of the interface to use the same memory allocator and the same dynamic array implementation. Which ties you to specific delphi versions. That forces your plugins writers to use Delphi. Amongst other requirements.

Really? Contention on a lock has the same impact irrespective of how many items are in the collection.

Well, won't they suffer when you make lots of reallocations. That's always been my experience.

What about multithreaded programs?

That's nice. But it's off topic here.

I don't think you understand. You talked about a .net class, but we are talking about the Delphi RTL.

Well yeah, that's to be expected. And it's not just QPC. If the processor runs in a slower mode, then you code will be slower. And of course when you measure it, that will be reflected, no matter how you measure it.

No, that's not what you said. You were quoting an MS document that was talking about the .net System.Diagnostics.Stopwatch class.

You said that you were replacing TStopwatch with QPC, but TStopwatch is implemented using QPC. So this entire effort is pointless. That's my point. TStopwatch.Frequency comes from a call to QPF. TStopwatch.GetTimeStamp is QPC. And TStopwatch.ElapsedTicks is the difference between QPC when you started the stopwatch, and QPC when you called ElapsedTicks. I guess you were previously calling TStopwatch.ElapsedMilliseconds and wanted more precision. Which you can get by switching to TStopwatch.ElapsedTicks.

There aren't any options with QPC. It just returns a 64 bit int. Which TStopwatch passes on to you. And the performance counter frequency is also available. The only possible explanation for this entire thread is that @Mike Torrettinni has not realised this. I guess he is blocking me because otherwise he would read my posts and realise this.

Why don't you use OnMouseDown?

Am I the only one who finds it odd that we have a two page thread on replacing TStopwatch with QPC when in fact TStopwatch is QPC. Perhaps somebody else could point out to @Mike Torrettinni that when he says It's actually what he had originally with TStopwatch.

I don't understand why you don't just use TStopwatch......

You really should not be trying to manage allocation manually. Your should try to avoid that.

Uff, I didn't read your code properly. I assumed you were using TList. So, yeah you just declare a local variable of the record type, populate it, and add it. As Stefan says, clarity on value vs reference semantics is key.

You would destroy those items using Dispose, since you made them with New. But that's the wrong solution. Use TList<TReminderItem> which will give you a type safe collection whose items are allocated and destroyed by the list itself.

TStopwatch is implemented on Windows using QueryPerformanceCounter......

Doesn't seem like ProcessMessages is really relevant here. Nothing is calling ProcessMessages.