Anders Melander

"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.

I don't think you can use a parameterized query with a list of values. https://www.google.com/search?q=delphi+query+array+parameters But you can try to ask here: https://support.devart.com/portal/en/community/delphi-data-access-components

Using a TImage for each image will probably consume far to many resources if you have a fair amount of images - or large ones. I would just use a TImageList, a TPaintBox and a TScrollBar: Store a thumbnail of the images in the imagelist. Use the scrollbar to control which image(s) to show. Draw the currently visible image(s) from the imagelist to the paintbox.

The next time you get a leak report from madExcept, double-click in the lower pane on the line that caused the leak and it will open up the unit in Delphi and place the cursor right where the allocation occurs:

The documentation is partly wrong. FindFirst wraps the FindFirstFile Windows API function which documentation more correctly state: So on failure there is nothing to free with FindClose; If you look at the source you will see that FindClose does nothing if the result of FindFirstFile was INVALID_HANDLE_VALUE.

The script language is easy but integrating DWScript into an application is hard; There is zero documentation and the examples are insufficient. I've used DWScript since Delphi 5 but I still find it hard to use.

I disagree. Sleep is only appropriate if the interval is very small and even then I wouldn't use it. The problem is thread termination; If you are using Sleep then the thread cannot be terminated while Sleep is executing. IMO the better solution, as have already been suggested, is to wait on an event with a timeout: If the event times out, do the task. If the event is signaled, terminate the thread. To terminate the thread, signal the event. While waiting on an event is much more complicated than just calling sleep, if one is to use threads one might as well learn how to do these things. Threads are difficult and pretending they aren't will just lead to lessons learned, the hard way, later on.

And thank Flying Spaghetti Monster for that. What a horrible design.

An easy way to introduce new methods and properties to components on a form is to use interposers: type TCheckBox = class(StdCtrls.TCheckBox) private FGroup: string; FValue1: string; FValue2: string; public property Group: string read FGroup write FGroup; property Value1: string read FValue1 write FValue1; property Value2: string read FValue2 write FValue2; end; Insert this in the interface section of your form unit. It must be before the declaration of the form. You can also put it in a separate unit but then you need to ensure that that unit is referenced after StdCtrls. Basically, this trick fools the Delphi DFM loader into creating an instance of your TCheckBox class instead of the standard one in StdCtrls. Note that interposers only enables you to extend a component at run-time. The design-time environment (i.e. the Delphi IDE) knows nothing about this trickery so the new properties will not appear in the property inspector (which is also why I didn't bother declaring them as published). If you want design-time support you will have to create and register a custom component the normal way.