Anders Melander

Seems like there's a bug in the documentation. Unfortunate.

Very clear. Thank you.

Turns out there's good explanation for that 😕 But at least the UI has a "Windows 7" skin.

Hmm. Okay, I'll defer to your expertise then 🙂 - but I can't tell, from looking at the call stack, if the thread was created from Delphi code or from something injected into the process from the outside. I was hoping there was some obvious clue that I had missed. More hmmm. Doesn't really tell me much with regard to the source of the thread.

Nice! I didn't know that one. Too bad about the XP skin though 🙂

How can you tell?

There are other ways for a thread to get started, but ignoring that and assuming it was created with CreateThread, one could simply place a breakpoint on the CreateThread import in Winapi.Windows and investigate the call stack as the threads gets crated.

If so then it would probably be better if they implemented a proper rate-limiting mechanism. Looking at the Threading unit, it's rare to see professional code with this few comments. Is there some sort of rule within Embarcadero against commenting the code?

Okay then. I doubt you will have any luck with getting this resolved unless you can provide additional details - which will require an effort on your part. Also, Embarcadero doesn't run this forum and probably doesn't follow what goes on here. If you want them to take notice of the problem you will have to report it to them (which isn't possible at the moment).

I haven't analyzed the problem at all, and I have no solution for you, but a few things struck me when I read the description of your problems. The default property directive only has meaning for published properties and is only used by the VCL streaming mechanism to determine if a property needs to be written to the DFM or not. It has no practical purpose here. I can only think they included it so it's easier to see what the default value is when looking at the source. It doesn't already have a default value. The default value is the one being set in the constructor, hence: True. It isn't set to False. If you are setting to False, then it must be after the constructor has executed. You do you believe that the worker threads being increased is unnecessary? I don't know but I would guess that growing the pool beyond the limit is done to try to avoid the deadlock that could occur in some scenarios if the limit it was a hard limit (e.g. all threads blocked waiting for something that can only be produced by another thread which can't be created because the limit has been reached). Exactly where? If it's an access violation then there must be an invalid pointer. I can see 3 different candidates in that line of code: Self, FThreadPool and FThreadPool.FMonitorThreadWakeEvent. You should be able to determine which one it is with the debugger.

Okay. Can't help you, sorry.

Are you asking if any version of Delphi supports Windows 7?

As designed. Look at the source of TStringHelper.ToUpper in SysUtils. Try using ToUpperInvariant instead.

Another thing to try: Use SysInternal's Process Explorer to inspect the call stack the threads in the process while it's running in the debugger. Might give you a clue about what it's doing. Run Delphi in a debugger (you can use another instance of Delphi to do that). Then run your application in the other Delphi and break so you can examine the call stack.

Okay but it's installed in the IDE by default and it affects the design-time performance of forms and datamodules. Give a try; It's one of the first things I do when I install Delphi.

"the check is in the mail" 🙂 It is for us. Some of our projects are huge, with lots of integer math optimizations involving bit shifts and funky multiplications and divisions and we simply cannot risk it when the compiler has known bugs in that area. So basically Delphi 12 has been DOA for us.

I'm sure the scenarios he outlined as a reason for moving to the cloud (basically cost of hardware) and then moving off it again is true for a lot of cases. It doesn't however resonate with any of the scenarios I've been or am involved with; We've moved systems to the cloud not because of hardware cost (which I can't remember having ever been an issue) but because of the cost of managing on-premise servers, providing the required infrastructure (storage, network, recoverability, know-how, etc) and securing global availability. I think the size of a company is a big factor in whether cloud makes sense or not. If you're already paying for the "overhead" of having dedicated, competent IT staff service your on-premise clients, then it might not make sense to outsource stuff to the cloud. Of course the nature of the services being outsourced also has to be taken into consideration, but I can't see hardware cost being a factor.

Try disabling the livebinding design time packages (unless of course you're using livebindings).

https://bitbucket.org/anders_melander/drag-and-drop-component-suite/src/master/ or https://github.com/landrix/The-Drag-and-Drop-Component-Suite-for-Delphi

What events does the analyzer show? Hmm. The D&D suite disables the Delphi IDE as a drop target during debugging to avoid the deadlock that would occur if the application being debugged was the drop source and the IDE the drop target. You can try to uninstall the D&D suite design time package to see if that is the cause.

The Drag and Drop Component Suite contains a demo application that can be used to diagnose a drop target (there's one for drop sources too, fwiw). You could use that to determine the exact interaction between the drop source and target. There is also a demo of WM_DROPFILES, including the handling of ChangeWindowMessageFilter*. The screenshot below shows the Drop Target Analyzer dropping CF_HDROP data (i.e. a file) onto the WM_DROPFILES demo, which is running elevated.

Point taken. I apologize. Although I have great interest in you project I haven't gotten involved at all because I simply don't have spare time or room in my head for yet another project. Anyway, it's not my area of expertise but I would have thought that existing solutions to distributed chain-of-trust could be used. I don't really have time to think that through to an actual solution though, so I can't claim that what I ask (no SPOF) is doable at all.

Providing critique. Are you opposed to that? Okay then. I know this was originally designed as something else but IMO, if this is to be the package manager, in the sense discussed here, it would be smart to base it on a distributed architecture with no SPOF.

Fixed it for you... Am I wrong?