Lars Fosdal

https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.SysUtils.CharInSet is the recommended method for checking if a character is in a set. It handles Unicode correctly.

Please make a minimal app that reproduce the problem, and create an issue on https://quality.embarcadero.com Remember to give a good step by step description of how/when it fails.

It seems someone lost their thread...

I'd be interested in reading a summary of your findings!

@Rollo62 I think we can say without doubt that none of us wants an AI like the one in the Terminators. I do want AI that is accurate and reliable for the areas that it is applied to.

Threads are not hard, as long as you play by the rules as described by @Dalija Prasnikar There is also good advice in OmniThreadLibrary by @Primož Gabrijelčič

Finding tools for Delphi is not easy. Look at GitHub - out of some 27+ million public repositories, less that 3k are Delphi. Not much material for the AIs to make patterns from. GitHub Advanced Security has no tools that can be directly leveraged for Delphi.

For sure! Who needs an AI to f... things up, when I am perfectly capable of f...ing stuff up myself? 😄

@hsvandrew There is no doubt "AI" (Machine Learning) will impact our work and business systems. What's wrong with me, is that I don't care for a deluge of "My AI generated code doesn't work. Why?" posts.

What can I say - I like open source where the source is included.

Consider type Use = record public class function When<T>(const aBool: Boolean; const WhenTrue: T; const WhenFalse: T): T; static; inline; end; { Use } class function Use.When<T>(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end; procedure Test(Cond: Boolean); type TObjectClass = class of TObject; var i: Integer; b: Byte; c: Cardinal; w: Word; s: String; d: Double; o: TObjectClass; begin s := Use.When(Cond,'True', 'False'); s := Use.When(Cond, 1, 2).ToString; i := Use.When<Integer>(Cond, 1, -2); b := Use.When<Byte>(Cond, 1, 2); c := Use.When(Cond, 1, 2); w := Use.When(Cond, 1, 2); d := Use.When(Cond, 3.14, 42.0); o := Use<TObjectClass>.When(Cond, TObject, TStringList); end; This is valid code. But i := Use.When<Integer>(Cond, 1, -2); requires the type to be specified. Also w := Use.When(Cond, 1, 128); stops working - actually for any signed or unsigned type - when the second parameter is changed to 128 or higher. It then complains: Why? I though the left hand type would assist in the type inference and hence the parameter validation? Edit: I just noticed that this only happens for Error Insight - not during compilation.

Thank you, @Stefan Glienke - that clears up the fog. It would have been nice, though - if the left side would be able to hint the type.

I guess I was trying to find out which of the constructs that was more readable.

FFS... I need to log off. Scrolling further up in the source code, I found... type Use<T> = record public class function When(const aBool: Boolean; const WhenTrue: T; const WhenFalse: T): T; static; end; { Use<T> } class function Use<T>.When(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end;

Changed the w line to w := Use<Word>.When(Cond, 1, 32000); That works too!

o := Use<TObjectClass>.When(Cond, TObject, TStringList); I did indeed mean o := Use.When<TObjectClass>(Cond, TObject, TStringList); but nevertheless, it compiles. Go figure.

The code compiles without a warning - also for that last line, @Stefan Glienke. In fact, even b := Use.When<Byte>(Cond, 1, 300); compiles. That is a bit weird, I think. Edit: Note to self - make sure you compile the project that contains the file you are fiddling with.

Hence open source effectively stopped being open source.

True, but still not thrilled about the use of the concept of taking something open and making a derivative work semi-closed. Can I make a derivative of sgcWebSockets and publish that as open source with source included?

Open source without the source... not sure what I think about that - particularly when it is based on another open source project.

It has become possible to create completely self-contained .NET apps as well.

That is a significant detail that should have been in your original post, which gives the impression that 64-bit is completely borked as a whole. There are some reports on similar issues when switching platforms in the QP - so it seems that it is not uncommon, but some of the reported issues have been closed with "unable to reproduce". My suggestion would be to try to narrow down the behaviour to a minimal example and submit it to QualityPortal. It can only be fixed if the problem can be reproduced.

Another Q: Do you have third party components/libs without sources and with .dcus compiled with a previous 11.x version?

- check that you don't have stray .dcu files - ensure that all projects build .dcus into different folders for 32-bit and 64-bit - If you have circular unit use, see if you can refactor and apply dependency injection

My advise would be to write a few test apps in .NET before you start your migration. Learn how to do databases, files, classes, interfaces, OS and UI. Understand the new paradigms before you try to csharpify Delphi code, so that you know how things work in C# and what you need to change from Delphi. Sadly, UI is still much more work in .NET compared to all the "freebies" in Delphi - and there are several flavours. WinForms, WPF, MAUI, ASP.NET, Blazor. You need to find the one that suits the needs for your app. You will most likely find yourself wanting to acquire some third party UI controls. For any complex Delphi app, you are not looking at a migration, but a rewrite.