Anders Melander

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?

Laziness.

I guess from their perspective the internal ones are the most important, and I guess, rationally, from the customer perspective too. Unless they are going to replicate the existing system of having two different Jira projects (one for the internal issues and one for the publicly visible ones), which I definitely would not recommend (that's how Atlassian does it and it obviously sucks for everybody), I can see how it will be a problem getting everything migrated into one project. I do not envy them this task. However, the optics of dumping years of public issues will be catastrophic to their already strained relationship with the community. I really hope that they get this sorted out somehow.

Atlassian hasn't supported the version of Jira that Embarcadero uses since 2017... https://www.atlassian.com/blog/2017/03/end-of-support-for-jira-6-4 As I interpret that, they will not be migrating data from the old to the new system.

And maybe get rid of the leading T since it isn't really used as a type.

I actually like Jira a lot. There are some things that could be better (wasted screen space, responsiveness, lack of basic features that can only be resolved with 3rd party plugins) but I don't think there's anything else that comes close to it as an issue tracker. Atlassian, however, can go to hell. I've been using their products for 20 years and I've lost count of the number of times I've sworn never to touch any of their products again. So a love/hate relationship basically. If that is the case, and JSM has improved substantially since I last looked at it (and from what I can see in their marketing material, it has), I think this might end up being an okay solution. With regard to loss of existing data, as far as I can tell, the Jira Cloud Migration Assistant (the software that migrates data from server to cloud) only support Jira Server 7.6 or later. Embarcadero's Jira Server is version 6.4, released in 2015 - and it's probably been customized... There are ways to solve that but it's a painful and fragile process involving incrementally upgrading the server to reach a supported version: 6.4 -> 7.0 -> 7.6 -> Cloud

That's not quite true. Jira Server is EOL in february this year but there's still Jira Data Center which is also on-prem (and extremely expensive). So the question is what "limited" means. Jira is licensed per-user and I'm guessing that they're not going to buy a license for each of their Delphi users. Instead they might be going with Jira Cloud internally and Jira Service Management (JSM, formerly Service Desk) externally. JSM is licensed per agent (internal user) with unlimited externals users (called "external customer" in JSM). I trialed JSM many years ago for external support but back then it was still licensed per external user and didn't really work that well, compared to something like ZenDesk. As far as I know JSM does not allow one external user to see the issues raised by other external users. I.e. it's a support system; There's no interaction between external users. So if JSM is the solution they are going for I don't see it as an improvement. As I customer I don't really care about what goes on behind the curtain. From my POW it seemed to work fine but I guess you point was that it only seemed that way. I wish I could have your admirable optimism.

Why is it definitely a good thing? The current system seems to work fine. I can understand why they would want to migrate away from their old, unsupported Jira server but without knowing what they are going to replace it with it's hard to say if it will be an improvement. Don't count on it. The last time they switched system all the existing data were left behind and lost.

Yeah. I could maybe forgive them their general incompetence as it's probably caused by a lack of resources - but that lie is just insulting.