David Heffernan

This is fair, I use shift right click to get the full context menu, but it would be better if they allowed you to choose which you wanted

I bet you'd regret it if you did.

Small things, minor improvements, better integration, built in vpn that works, but it all adds up. I find it a cleaner experience.

Definitely Windows 11 is better than Windows 10. Just nice incremental improvements. Every single time there's a new release of Windows people complain that it's worse. But who honestly wants to go back to 98 or XP?

No salary, and talk of XE12 a version that does not exist.

I'm sure he'll get here at some point, but I've been chatting with him about this.... So yeah, his development stands on a threadpool. There's a lot of really interesting aspects to it too. Looking forward to the Amsterdam Delphi event where he can say more.

Hasn't Stefan been working on using multiple threads, whereas SIMD will be on a single thread so actually really powerful in its own domain

I've recently come across a defect in my code that looks like this: msg := Format('%s' + foo, [bar]); If foo contains any format placeholders, e.g. %s, %20, etc. then this will result in an exception being raised. It's a stupid mistake, but now I want to check my entire codebase to see we've done it elsewhere. Ideally I'd like a static tool that detects any call to Format or common equivalent like Exception.CreateFmt for which the format string is not a literal. I don't think FixInsight has such a warning. Does anybody know of such a tool?

Doesn't look like it handles code laid out over multiple lines.

I know how to code a solution. And I'd use a proper parser to do it. But I'm looking for a tool.

No, I am just looking for a tool that detects non literal args by static analysis, which is what I wrote

It feels like most releases in the past 5-10 years have been "quality focused" releases. In other words, they are already doing this. How is it going?

Yes, silly me! Sorry.

Sure. I can choose not to be impressed. The Win64 bit compiler was available for pro from initial release, XE2

I mean, I did, and I read the what's new. As I said, I think it's pretty poor that they can release software that is so far from being functional.

Saying X does not, a priori, make X OK

I went from XE7 to 11.something and only upgraded to get high DPI support which was worth it. Not sure what would get me excited from here. Probably would be copilot like goodness in the IDE.

Well sure. But isn't this pretty lame? Who does version 1 releases that don't work? They might be upfront about all of its deficiencies, but good developers produce software that works. We've all used VS and VSCode and PyCharm and so on, and they work and shine. And then 12 months passes, it's 2025, and Emba come out with 5000 bug fixes and a 64 bit IDE that doesn't work.

Prepare for three years of them fixing the new 64 bit IDE

AI is just a tool. It has its uses. It's not going to do everything. Yes it's over hyped. But that does not mean it has no value. As usual the value lies somewhere in between what the hypers and the doubters say.

Sure, that basic concept. But I think I'd take it further and move the data into a text file embedded as a resource. Given the scope of this unit.

It's funny to see various people posting their own solutions when the original post contains a comprehensive implementation....

This code would be much better if each check of file header was done with same same code, against a signature declared either in a constant, or maybe in a file that was linked as a resource. This would make the code much cleaner, without so much repetition, and would allow you to extend it very easily.

As a broad rule, you should never call ShellExecute. It's long since been replaced by ShellExecuteEx. The only reason you need to know why, is that ShellExecute doesn't report errors correctly. ShellExecuteEx does. And in this case, as in so many cases, as Remy already pointed out, CreateProcess is correct. Whenever you are creating a new process, you use CreateProcess and not ShellExecuteEx. The latter is for executing shell verbs.

This one is easy to debunk. Exceptions raised in a constructor then lead to exceptions in the destructor. This is the entire reason why Free exists.