Leaderboard

4 😁 Edit: Perhaps it just means re-star-ting? Edit2: It's very easy to rename a repository (via Settings) and you won't lose any stars!

I wish they would just deprecate AlphaFormat. It's an abomination that was supposed to make it easy to draw a 32-bit TBitmap with alpha. I guess it did that but what it also did was make it almost impossible to do anything beyond the single use case they could think of.

Can you be more specific about what "stuck in-limbo" actually means? Recreating the TIdHTTP and TIdSSLIOHandlerSocketOpenSSL objects would work fine. How does it "not help" exactly? If you don't want to recreate the objects, you should be able to just Disconnect() the TIdHTTP and Clear() its IOHandler.InputBuffer if it has any unread data in it before the timeout occurred. That won't make any difference. Besides, TIdHTTP should already be disconnecting the socket if a read error occurs. So really, you might only need to clear the InputBuffer. You should not use the Method and SSLVersions properties together. They are mutually exclusive, setting one updates the other. In fact, don't even use the Method property at all. You don't need to do that manually at all. TIdSSLIOHandlerSocketOpenSSL calls SSL_set_tlsext_host_name() internally for you, and has done so since 2016. 'utf-8' is not a valid value for the 'Content-Encoding' request header. You need to use the 'charset' attribute of the 'Content-Type' header instead (ie, the Request.Charset property). Also, you are not telling the TStringStream to use UTF-8, so it will use the OS default instead, which is ANSI on Windows and UTF-8 on Posix, so you will mismatch your JSON data if it ever contains non-ASCII characters. Use this instead: vJsonToSend := TStringStream.Create(vJsonToPost, TEncoding.UTF8); ... FHTTP.Request.ContentType := 'application/json'; FHTTP.Request.Charset := 'utf-8'; The correct way to detect a read timeout is to check if the caught exception is an instance of the EIdReadTimeout class. Don't rely on parsing the exception's Message: if E is EIdReadTimeout then For that matter, why would you want to recreate the objects only on a read timeout, and not on other errors?

In Norway, Delphi developer salaries are relatively high compared to others - but I guess that is connected to the seniority of the average Delphi devs - We've been around for a long time 😛

Because, once you are using popular toolchains and languages, you have a a significantly larger pool of developers to choose from. If you're using Delphi, it is far harder to find experienced developers. This may or may not be a valid reason to try to replace Delphi in a company, but it is certainly and understandable one.

Hello Andrea, I did already coded a thread for that purpose which seems to work fine for the time being. I will also check AfterInvoke. Thanks.

Just for a reference, a recent blog post on the topic and a shared library by @Darian Miller https://www.ideasawakened.com/post/use-createprocess-and-capture-the-output-in-windows

One may create an issue at the GitHub repository just to ask for licensing.

http://www.isdelphidead.com

I'd say that this is not a very meaningful question. There are still tons of companies running IBM 3050 (?) emulators on 360 emulators on newer systems because the software has been running and stable for decades and the source code was lost a long time ago. Delphi was really popular up until D7, when they made some changes that caused several popular component libraries to stop dead in their tracks, which is why D7 is still popular. The truth is, there are TONS of Delphi apps built in the D4-D7 time-frame that are still running today. I suspect a huge chunk of EMBT's revenues come from such companies who keep their licenses up-to-date just in case they need to hire some folks to fix things. Last place I worked, they had a team of 8 or so Delphi Devs who all quit at one point save two new guys, who were their for another decade. I was hired to replace one who had recently left, and while I was there the other one left. They hired a new guy and transitioned another fellow over from C# who didn't have much trouble learning Delphi, then cut me loose. That facility was on track to be generating $1.5 billion in revenues this year. The entire facility is driven by software written in Dephi between 2006 and 2010. Management there has been trying to replace the Delphi code since 2014, and has refused to allow it to be expanded or extended or anything. It's still their most stable, most reliabe and full-featured platform in the company, and they can't just shut it off without losing hundreds of millions of dollars of revenues. Delphi apps have become the platform companies love to hate -- they want to get rid of them, but they can't afford to. For a decade now, the Delphi code has supported features beyond what their other platforms don't offer, and apparently can't offer. And the Delphi version has not had any new features added in TEN YEARS while the others have been under active development the entire time! Go figure! (They have had 30 devs working on the other platforms, and only two have been maintaining the Delphi code since 2014.) Personally, it makes no sense to me. They've got a huge installed code base that's stable, reliable, and fully debugged. So why go with another platform where all of the code is new, will take a couple of years to get to where the Delphi version was three years earlier, and will be full of bugs for the next several years? Why not build the NEXT version in Dephi, re-use as much existing code as possible (reducing your programming needs to some extent) and save a huge amount on development costs? Like I said, Delphi is the platform that companies love to hate today.