Leaderboard

SVN and the overnight zip have been updated with a lot of changes so ICS supports International Domain Names for Applications (IDNA), i.e. using accents and Unicode characters in domain names. Domain names can only contain lowercase ASCII letters and numbers and a couple of symbols, so Unicode U-Labels (nodes in a domain) must be converted to A-Labels (Punycode ASCII) with an ACE (ASCII Compatible Encoding) prefix. So www.mâgsÿstést.eu becomes www.xn--mgsstst-pwa1e4l.eu and мособлеирц.рф becomes xn--90aijkdmaud0d.xn--p1ai. ICS mostly does the Unicode to A-Label conversion just before looking up an IP address for a domain name (in DnsLookup) and converts back from A-Label to Unicode when doing a reverse lookup (in ReverseDnsLookup). HTTP headers also contain A-Labels for the Host: header and the host part of URLs for proxy or relocation, but Unicode paths should be UrlEncoded by the application as now. Not looked at SMTP yet. The HTTP client and server, Ping, ICMP and DNS Query components all now support Unicode domain names, generally without application changes unless you want to display the A-Label name looked-up (PunycodeHost property). DNS Query does require application changes due to all methods and properties previously being AnsiString, now String. SSL/TLS now fully supports Unicode domain names, including displaying the Unicode version of the domain name (except for Subject and Issuer lines), and X509 automatic certificate ordering from Let's Encrypt fully supports Unicode domain names. Certificate files are saved with Unicode names, not A-Labels. For server testing I registered an eu domain which is live on one of my web sites at https://www.mâgsÿstést.eu/ and https://scrúdú.mâgsÿstést.eu/ which have ICS ordered SSL certificates. I do have DNS for Cyrillic and Far East domains, but this web server is built with Delphi 2007 so no full Unicode. Angus

Having arguments to the constructor is something I try to avoid. TINIComparer = class private fINIFileName1: string; fINIFileName2: string; protected procedure LoadINIFiles; procedure CompareINIFiles; virtual; public constructor Create; virtual; procedure Compare(const aINIFileName1, aINIFileName2: string); end; TIniComparer2Way = Class(TIniComparer) protected procedure CompareINIFiles; override; // if necessary public constructor Create; override; end; constructor TINIComparer.Create; begin Inherited; end; constructor TINIComparer.Compare(const aINIFileName1, aINIFileName2: string); begin fINIFileName1 := aINIFileName1; fINIFileName2 := aINIFileName2; LoadINIFiles; CompareINIFiles; end; constructor TINIComparer2Way.Create; begin Inherited; fCompareType := cmt2WayCompare; end; // from main form: fINIComparer := TINIComparer2Way.Create; fIniComparer.Compare(edtINIFilename1.Text, edtINIFilename2.Text)

In Delphi 10.3.3 it's possible to write: TStaticCheck = class class procedure OverStatic; static; static; static; static; end; I don’t know, is it worth reporting to the issue tracker? The idea is taken from here: System.Generics.Collections.pas, TArray.BinarySearch<T>

I like my constructors to construct No loading, no process, no fancy stuff inside the constructor other than parameter assignment, variable initialization or other class creation.

OMG, take a poor idea, and make it much worse

Hello, [OverbyteIcsWSocketS.pas] procedure TSslWSocketServer.OrderClose; OLD>> if FIcsHosts.Count = 0 then Exit; NEW>> if (not Assigned( FIcsHosts )) or (FIcsHosts.Count = 0) then Exit;

It works. But better to have one constructor that accepts an argument. Think of the time you need to decide at runtime which path to take. Then your way is hopeless.

as long as nobody else have to use this class and you have memories like an elephant, it should be fine..

https://quality.embarcadero.com/browse/RSP-20169

Well, I am sure you will understand that it's not really nice to advertise another product in a thread specifically presenting HxD. I have invested many years into it (since 2002), and it has been Freeware all the time. A little respect for that effort would be appreciated.

After a very, very long beta phase I finally released MMX Code Explorer V15. Thanks to all beta testers for their help and patience. A really big thank you goes to all who donated for the new MMX icons.

How about you write the code in a proper way: using System; public class TTest1 { public void Test() { Console.WriteLine("TTest1.Test"); } } public class TTest2: TTest1 { public void Test() { Console.WriteLine("TTest2.Test"); } } public class TTest<T> where T: TTest1, new() { public static void TestIt() { var FTest = new T(); FTest.Test(); } } public class Program { public static void Main() { TTest<TTest2>.TestIt(); } } The reason FPC does it different is because its generics are behaving more like C++ templates. However for generics there is no kinda "duck typing" or prototyping. You tell the generic class "look there is the type parameter T, which is guaranteed to be a TTest1 and it has a constructor". So when the compiler generates the AST for the generic type it just takes from these informations and so it decides to emit a static call to TTest1.Test because that is not a virtual method. This is the behavior in all languages with generics that I know of (such as C# or Java) - languages that use a templating approach such as C++ and possibly FPC does it similar decide what to call when the type parameter is being specified. Generics in this case behave the same way as if you would write code like this: procedure TestIt(const t: TTest1); begin t.Test; end; here it will always call TTest1.Test and not TTest2.Test even it t is a TTest2 - simply because there is no polymorphism happening due to the lack of a virtual method call. Personally I would rather call this a bug in FPC - but again it depends on the actual language specification/implementation. Both have their pros and cons. I cannot find the official specification for generics in FPC about this specific point to verify.

In case you give MMX Code Explorer a try: it has an Extract Interface refactoring. Given this class declaration type TMyClass = class private FNewProp: Integer; function GetNewProp: Integer; procedure SetNewProp(const Value: Integer); public procedure NewMethod; property NewProp: Integer read GetNewProp write SetNewProp; end; select the property and method in the members view of the MMX Code Explorer window and in the context menu select Refactorings - Extract Interface. In the following dialog enter the interface name, GUID etc. and you end up with this: IMyInterface = interface(IInterface) ['{8431B2B9-8D15-4308-BF08-26AB2BA4960F}'] function GetNewProp: Integer; procedure NewMethod; procedure SetNewProp(const Value: Integer); property NewProp: Integer read GetNewProp write SetNewProp; end;

Sure. Professional relationships, personal preferences and even mood, are just some of the many factors that affect priority. We're humans. As long as you know why you are making a choice I don't see anything wrong with making it based on "feelings" or intuition. Just don't make all your choices that way 🙂 I regularly make technical decisions based on intuition. I may not be able to rationally explain why I choose one solution over another, except that one "feels" right or the other doesn't "feel" right.

I've just created a QV issue. Please vote for it: https://quality.embarcadero.com/browse/RSP-27256

I found the culprit! It was a simple setting in Tools/Options (see attached image). That's totally crazy.

I just tested the Read Only option of with Delphi 10.3 professional. It works fine with GExperts installed, so it probably isn't the culprit. Also, disabling GExperts from the experts manager while it is acive in the IDE works fine for me (after restarting the IDE, GExperts is gone). Enabling it via the stand alone Experts manager brought it back. So everything seems to work as expected. I do use GExperts every day. I don't use Delphi 10.3. I only have it installed to compile and test GExperts. And every time I have to use it I curse it. I don't use the dark theme and I have got lots of more interesting things to do than implementing theming in GExperts. I already had enough trouble to keep GExperts functional when Embarcadero changed the light mode to also be a theme. So, unless somebody submits a patch for this and fixes all the bugs it will most likely cause, theming in GExperts won't happen.

If you think GExperts may be the culprit, disable it with the Expert Manager, restart the IDE and see whether it solves the problem.