Darian Miller

Can you provide a small sample project that reproduces the error? My limited testing shows that it's working much better in 10.4.1. If you could reproduce the problem in a simple example project, it has a much higher chance at getting fixed.

On a diversionary whim, I tried installing 10.4 on XP and the installer presented a fatal error "This program does not support the version of Windows your computer is running." I imagine you have to unpack, tweak the installer package, and then rebuild it to get it to work on XP, correct?

Ok, I'll get the electronic version. Thanks!

Congrats! Are you working on publishing a print version?

You could check out this library: https://www.zylsoft.com/gsm.htm They appear to have recent updates, but their forums are down right now

My main point was making a case that this particular bug does not really warrant the noise. There are many other examples that you could use, and would probably garner more support. I like inline variables, and they work rather well. However, Boian stumbled across a particular set of circumstances which consistently leads to memory leaks which assumedly would have been obvious is he ran a memory leak checker before releasing his code. The simple reproducible case was posted in September. As in my hypothetical example, if it was a new language feature in VS2021 just released and you moved all your code to use it...you would not, could not, would ever expect to get an immediate fix from Microsoft so you should provide the same courtesy to Embarcadero and not demand "fair and civilized" compensation for this issue. Instead, argue for bugs that are more than 3 months old and it would be much more beneficial. And/or argue for more unit tests on the RTL, and demand they be made public. Embarcadero has acknowledged a quality issue. They have attempted to attack it in the last few releases and planned to do even more in the next release. Expecting them to immediately fix a new bug when there are plenty of bugs which are years old and affect much, much more code is just the wrong approach in my opinion. I fully support the general argument being made, but just not this specific issue.

LOL. I knew some response was bound to come in from someone. Sorry, but that is pretty weak as every piece of software has bugs. If you mentioned, say, RSP-9678 Delphi IDE is not DPI aware (from 2014 with 93 votes) then it may have been stronger. Or maybe RSP-17724 Linux x64 compiler produce very bloated code. Or perhaps this thread: Again, that's not an overly strong argument. How many one liner changes have you had to chase for hours on end, that may have not have revealed themselves as a problem for months? The key point here is tests. So you can put bugs in your code, or hair on your burgers which you serve, but they aren't allowed? I believe the major issue here is lack of tests. The main way to gain more confidence in the Delphi platform is by trumpeting, marketing, glorifying their major gains in testing over the last few years (which assumedly has been the case.) Likely one of their most dominant product features is backwards compatibility - that very valuable feature can only be assured with a huge amount of manual effort, or a very large amount of tests. Likely one of their most harshest points of criticism lately is new code is not up to the quality of old code. That also can and should be braced with an adequate amount of tests. Finally, let's state the obvious here: Boian Mitov should not have changed his core library to inline variables until he was completely satisfied that it wouldn't cause problems for his customers. Changing your legacy source code in thousands of places to utilize a new feature of Delphi seems pretty reckless without adequate testing. Yes, we should be able to trust the compiler, but how about using Microsoft as an example... They have one of the largest R&D budgets in the world and they still ship very questionable software. If they came out with Visual Studio 2021 today, would you immediately migrate all your source code to it, after changing it in thousands of places to use one of the VS 2021's newest language features, and then quickly ship your product to all of your customers with a large amount of memory leaks? Would you be out there stating that Microsoft shouldn't be able to sleep at night, or would you be rolling back your changes and provide a stable product again to your customers? I certainly don't like providing an excuse for buggy code, or lack of tests. But this particular example is certainly not the hill to die on.

30215 was reported in July. A minimal stand-alone test case to reproduce the issue was posted by Embarcadero in September. To complain that you don't have a fix by December is too much. This particular edge case issue is no where near the prime example to be complaining about long-standing bugs... to me, it considerably reduces the strength of your argument.

There are some Hunspell related items here: https://github.com/darianmiller/Delphi-Hunspell

Sorry to hear that... the classic is supposed to be backwards compatible with the prior version. I would recommend opening an issue on the quality portal.

CodeInsight was radically changed with the implemention of a Language Server Protocol host as the default Code Insight provider. You can change this in: Tools->Options->User Interface->Editor->Source->Code Insight You are able to switch back to "Delphi (Classic Code Insight)" I assume you are on an early version of 10.4 Sydney. The latest version 10.4 Sydney Update 1 and Patch #1 provide major improvements to Code Insight. You can see a list of recent updates here: https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List I suggest you update to 10.4.1 and then apply latest patches as Code Insight is much better.

Does that mean that more debugger issues will be found and fixed, or that your IDE Plugin will simply ignore more as time goes on? 😉

This was from the Q&A on the 10.4 Release Webinar back on May 27, 2020:

I believe it was stated that CE will remain one full version behind the current. So, when 10.5 gets released then CE will be upgraded to 10.4.

https://stackoverflow.com/questions/156767/whats-the-difference-between-an-argument-and-a-parameter

https://www.ideasawakened.com/post/delphi-programming-how-it-started-how-it-s-going

I'll need some more mushrooms to fully decipher that.

I've tried a few times to write a decent reply... I'll just leave it at: Whatever dude.

Type definitions are different... I definitely prefix with uppercase T Except for Error class types that start with uppercase E Interfaces with uppercase I

I have switched over the years but current prefixes include f for Fields p for Parameters v for Local Variables You could also use v for Var parameters I no longer prefix constants - I add them to classes and scope all uses with the class name. If I don't use class scoped constants, I slip back into old school mode and use all uppercase for unit constants. TMyClass = class public const DefaultMessage = 'Hello World'; ... ShowMessage(TMyClass.DefaultMessage) Globals are treated similar to constants...if used, add them to a globals class or record. Since I have a strong preference for lower case prefixes, I prefer v over l for local variables as the l prefix can lead to readability issues. I just don't reading: FThreadCount, AThreadCount, LThreadCount. I'd rather see fThreadCount, pThreadCount, vThreadCount. I believe the prefix used for parameters and local variables is stricly for collision prevention purposes only and shouldn't be highlighted with a capital letter. There are a few coding standards on the web for reference if you'd like to review: http://www.sourceformat.com/coding-standard-delphi-econos.htm http://mc-computing.com/languages/delphi/Style_Guides.html https://edn.embarcadero.com/article/10280#3.5 https://wiki.freepascal.org/Coding_style https://www.gnu-pascal.de/h-gpcs-en.html https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide I think we had about 8 Delphi developers on staff at my previous job when we all got together and voted on style rules. The daily Code Reviews started enforcing those style rules. It wasn't enforced 100% of the time but it did help standardize the code better than before. (4+ million lines of Delphi code written by a few dozen different developers.) These prefixes came from that vote about 12 ago now.

It was a simple example and the Encoding is selectable, but it really depends on what you are going to do with those TBytes... If you are getting it from Edit1.text as in the example, fidding with the bytes somehow, and then shoving it into Edit2.text, why convert to UTF8?

Example. Start a new VCL app, drop an Edit and a Button on a form. In the click event of the button: procedure TForm7.Button1Click(Sender: TObject); var x:TArray<Byte>; begin x := TEncoding.Unicode.GetBytes(Edit1.Text); ShowMessage(IntToStr(Length(x))); end;

Sorry for the double post...double clicked the Submit button I guess

Curious if you ever received a response?

I don't recall if this is on by default: TStyleManager.SystemHooks := TStyleManager.SystemHooks + [shDialogs]; But also look at: http://delphiprogrammingdiary.blogspot.com/2019/05/how-to-apply-vcl-style-to-delphi-common.html