Anders Melander

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.

Clickbait title and the author has no clue about the things he writes about. If it wasn't for the illustrations I'd thought that article was written by ChatGPT.

...or AMD uProf with map2pdb - if your system has an AMD processor.

Nah nah nah nah, can't hear you. I just added support for Alpha AXP to my application with SetPEFlags(IMAGE_FILE_MACHINE_ALPHA). Neat huh?

Yes: Install v23.2.3 There is no "workaround". To support Delphi 12 with an older version you would have to replicate the things they've done in 23.2 and then you might as well just install 23.2

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Overview_of_Generics#Dynamic_instantiation

Yes, you are right - and you couldn't do it with polymorphism.

Format would like a word with you about that.

I tHiNk YoU NeEd To DeBoUnCe YoUr ShIfT KeYs... I think you can get something to compile but even then I have a feeling that, whatever it is you are trying to do, isn't possible. FWIW, this one compiles: type IMyInterface<T> = interface function GetValue: T; function Clone: IMyInterface<T>; end; TMyClass<T> = class(TInterfacedObject, IMyInterface<T>) private FValue: T; private // IMyInterface<T> function GetValue: T; function Clone: IMyInterface<T>; public constructor Create(const AValue: T); virtual; function CloneObject: TMyClass<T>; end; function TMyClass<T>.Clone: IMyInterface<T>; begin Result := CloneObject; end; function TMyClass<T>.CloneObject: TMyClass<T>; begin Result := TMyClass<T>.Create(FValue); end; constructor TMyClass<T>.Create(const AValue: T); begin FValue := AValue; end; function TMyClass<T>.GetValue: T; begin Result := FValue; end;

I don't, but I know how to let the remote work find you: Answer questions on stackoverflow. Answer questions here. Participate in open-source projects. Of course, it helps immensely if you can do that within a narrow field of expertise (to minimize the competition) - or better than most. If you can stomach the self-promoting nonsense in the LinkedIn Delphi group you can also try posting there. I don't use it myself (as I wouldn't be able to behave). ...and start by changing your screen name. I assume your last name isn't 23668... If I wanted to I could live off the remote & freelance offers I get because my name comes up when clients google for info on some special tech they need help with.