Leaderboard

https://www.finalbuilder.com/resources/blogs/code-signing-with-inno-setup-and-signotaur

Yes, yes, we see now. How could we have been so blind? Totally different things. Totally! Now, run along.

Imagine if you would read documentation. Like that for EndDialog. And imagine if the documentation for EndDialog said this: EndDialog does not destroy the dialog box immediately. Instead, it sets a flag and allows the dialog box procedure to return control to the system. The system checks the flag before attempting to retrieve the next message from the application queue. If the flag is set, the system ends the message loop, destroys the dialog box, and uses the value in nResult as the return value from the function that created the dialog box. So yeah, it's exactly the same as the Delphi mechanism. Because that's how modal dialog are implemented in Windows.

I think you may be helped by learning how Win32 development works. This is basic stuff, and I don't mean that in a demeaning way. But it is always a bad approach when you come at an existing framework of 30 years and assume that you know better how it should have been designed, when you clearly haven't even read the basic documentation that comes with it. I linked for you the page of the documentation on ShowModal that explains exactly how this works, in case the source code was not clear enough. Your complaints about how ModalResult works ignore the typical use case where a modal result is assigned to buttons on the form. There is no need to call "close" on a modal form in Delphi, and if you think you should call close on it, you likely have a design flaw or a flaw in your understanding of how it is supposed to work. Also, you should think about the ramifications of your method of calling Close and then still being able to do things with the form's instance after that. Why are you so resistant to learning the framework? This is more like someone telling everyone at a work site that they don't know the right way to do their job, when that person hasn't spent any time learning construction and the workers have been doing it for years.

You are wrong, the design makes eminent sense for a message/event driven environment like Windows. A modal form has its own internal message loop and that needs a way to figure out that it should exit the loop. Modalresult <> mrNone is that condition.

Evidently, there are issues with cycles. I do admit that our huge 3M LOC application has tons of cycles (where we have stuff in the implementation uses clause that would cause circular references if it was put in the interface). We are working on removing these because evidently they slow down the compiler as well. Over the last 20 years we were not aware there was any downside in having cycles and took no effort to refactor things to prevent them. Now we are far more careful. Evidently, LSP (even Delphi 12.3) does not like these and simply dies on our application. However, that does not explain that even in my relatively simple apps it is still unreliable.

And vice versa. But doing so works safely and reliably only if you stick to certain rules to ensure compatibility across programming languages/ABIs, environments, etc. Which limits what you can and can't use across the DLL boundary.

Indy's TIdHTTP component supports Digest, just make sure the IdAuthenticationDigest unit is in your uses clause (directly, or via the IdAllAuthentications unit) . And then you can set the TIdHTTP.Request.Username and TIdHTTP.Request.Password as needed.

I am designing a new media player UI and have been documenting my work, posting about programming and UI design in laymen terms on reddit. Recently, I posted about basic UI code optimization logic and thought it may be interesting for novice programmers. Since the post is simplified for non-programmers, I'll share here that I'm using WinAPI's layered windows and GDI+ to render the anti-aliased text and bar-shapes, preserving the alpha channel.

I dunno. I think it's pointless. I mean, properties? Pfft! What's the point? Delphi is dead anyway and if there's one thing the past 30 years has shown it is that the design is flawed beyond repair but we were just too ignorant to notice. If only we had been told about this before. The shame is unbearable.

OTL is very much tied to the windows api - will take a lot of work to produce a linux version. Feel free to help with the port.

I agree with you. The LSP simply is unusable on our project and we were forced to write our own IDE plugin and utilize DelphiAST to write our own code insight and code completion. Even in much simply projects I am writing (<10 units, a few hundred lines of code) the code completion, ctrl+click to jump to an identifier, does not work well.

Not that again! Just remove the f*ck*** call to Close and be done with it.

Must be exhausting attending Delphi's funeral every year just to realize it's still here.

I definitely don't "get" that. I think it's very unlikely. You're one of those people who assumes every gap in their knowledge is due to someone else's error. It's a waste of time to try to help people like that learn something.

It's not nonsensical at all and it is based on basic Windows event driven design that goes back eons. It's the whole point of using ShowModal to get a modal result, so that result is going to be set for you if you call Close. Just browse the VCL source code to see how it is meant to work, or read the documentation.

I'm speaking in general terms about people who are obsessed with compressing EXEs, as if it is a legitimate solution to create un-pageable files just to avoid proper deployment methods. As to that "unused stuff," Delphi's compiler does exclude a lot of unused code if you don't build your EXEs with shared libraries. Could it be better? Probably, but, when RTTI gets involved, things aren't so straightforward.

If you use ShowModal then you are using the modal loop built into the VCL which relies on exiting the loop when ModalResult<>mrNone. If you disagree with that design then don't use ShowModal; Use Show and build your own modal handling around it. And good luck doing that without a loop which monitors some kind of state flag. I don't think you have thought this through.

Yes, for the most part, a plain DLL can do that. Just be careful about accessing anything across the DLL boundary that is version-specific. Keep the interface between DLL and EXE simple - stick to functions and simple POD types or OS-managed types only. No classes, no Delphi-managed types, etc.

Sounds like it were a religion...

Unfortunately, we are not. The company has too many hoops to jump through to get anything out as open source. Plus we used a lot of our base classes and libraries to speed up the coding, so would have to disentangle that.