Leaderboard

Thanks, for the explanation, I see that buffer is a dynamic TBytes, unusual for 20 years ago when Delphi didn't really support TBytes. I only started making wide use of TBytes a few years ago with a lot of new library functions. I'll fix the code, and check other receive loops for similar problems. I'm hoping to release ICS V9.4 this month, with various minor fixes. Angus

type TForm1 = class(TForm) ListView1: TListView; procedure FormCreate(Sender: TObject); procedure ListView1UpdateObjects(const Sender: TObject; const AItem: TListViewItem); procedure FormDestroy(Sender: TObject); private FCustomItem : TListViewItem; FBitmap : TBitmap; public { Public declarations } end; var Form1: TForm1; implementation {$R *.fmx} procedure TForm1.FormCreate(Sender: TObject); begin for var i := 1 to 25 do ListView1.Items.Add.Text := Format('item #%u', [i]); FCustomItem := ListView1.Items[4]; FCustomItem.Text := 'Custom Background Item'; var c := TAlphaColorRec.Orangered; TAlphaColorRec(c).A := 64; FBitmap := TBitmap.Create(8, 8); FBitmap.Clear(c); end; procedure TForm1.FormDestroy(Sender: TObject); begin FBitmap.Free; end; procedure TForm1.ListView1UpdateObjects(const Sender: TObject; const AItem: TListViewItem); begin if AItem = FCustomItem then begin var Bkgnd := TListItemImage.Create(nil); Bkgnd.ScalingMode := TImageScalingMode.Stretch; Bkgnd.OwnsBitmap := False; Bkgnd.Bitmap := FBitmap; AItem.View.Insert(0, Bkgnd); end; end; custom_bkgnd_item.zip

If you use the OpenSSL 1.1.1 or 3.1.x, I suggest to use this: //CipherList are used in TLSv1_2 CipherList := '!EXPORT:!LOW:!aNULL:!eNULL:!RC4:!ADK:!3DES:!DES:!MD5:!PSK:!SRP:!CAMELLIA'+ ':ECDHE-RSA-AES256-GCM-SHA384'+ ':ECDHE-RSA-AES128-GCM-SHA256'+ ':ECDHE-RSA-CHACHA20-POLY1305'+ ':ECDHE-ARIA256-GCM-SHA384'+ ':ECDHE-ARIA128-GCM-SHA256'+ //Weak !! but necessary for old products ':ECDHE-RSA-AES256-SHA384'+ ''; //CipherSuites are used in TLSv1_3 CipherSuites := ''+ 'TLS_AES_256_GCM_SHA384'+ ':TLS_CHACHA20_POLY1305_SHA256'+ ':TLS_AES_128_GCM_SHA256'+ ':TLS_AES_128_CCM_8_SHA256'+ ':TLS_AES_128_CCM_SHA256'+ ''; If you use only old OpenSSL 1.0.2u (limited to TLS 1.2): CipherList := '!EXPORT:!LOW:!aNULL:!eNULL:!RC4:!ADK:!3DES:!DES:!MD5:!PSK:!SRP:!CAMELLIA'+ ':ECDHE-RSA-AES128-GCM-SHA256'+ ':ECDHE-RSA-AES256-GCM-SHA384'+ ':ECDHE-RSA-CHACHA20-POLY1305'+ ':ECDHE-ARIA256-GCM-SHA384'+ ':ECDHE-ARIA128-GCM-SHA256'+ //Weak ':ECDHE-RSA-AES256-SHA384'+ //To use this two you must generate the DHPARAMS file with OpenSSL utility //':DHE-RSA-AES128-GCM-SHA256'+ //':DHE-RSA-AES256-GCM-SHA384'+ '';

There seems to be an adapter to apply VCLStyles to DevExpress components: https://www.almdev.com/prods/stylecontrols/stylecontrols.html - I have no experience with this but at some point we will have to look into this as customers keep asking for Dark mode in our application 😎 🙈

This attitude is inappropriate. Access to these forums is a privilege, not a right. Do not abuse it.

I've downloaded (cloned) Indy repository from github (https://github.com/IndySockets/Indy.git). Manually copied needed file in a source folder of my project. Added that folder in the project search path. Created the class only with code (no IDE objects placement) so I use only custom sources for Indy. This permitted me to add changes and work with latest git repository code, without remove native Indy tools from IDE.

I wrote some tips about TListview you can find here (in French) , or in this tutorial

pyscripter/python4delphi · Discussions · GitHub pyscripter/SynEdit · Discussions · GitHub

Such a version has NOT been released yet. Still a work in progress. The next Indy version that is pending release (10.7) will be splitting off all OpenSSL support into a new package, IndyTLSOpenSSL, as an add-on to the main Indy packages. It has its own repo: https://github.com/IndySockets/IndyTLS-OpenSSL v1.0 will focus on backwards compatibility as users update their existing projects to include this new package without changing the rest of their code. Then v2.0 will be for adding OpenSSL 3.x. In the meantime, there are a few 3rd party projects already available now that bring OpenSSL 3.x to the current Indy. You cannot have multiple versions installed together. The GitHub version is not compatible as-is with the default bundled version. You will have to use one or the other. I can't answer that. Each 3rd party project that has been released so far has its own way of doing things. Use what is appropriate for whatever project you decide to use. What will end up in the new IndyTLSOpenSSL package is not finalized yet.

Delphi developers.... one half still uses Delphi 7 and the other one does not even do 32-bit anymore

I would go with option 1; Get rid of the technical debt once and for all. Even if you managed to get ProfGrid working now (which is probably possible, given enough effort) you would then have to maintain it yourself going forward and since you don't have Pascal expertise this doesn't sound sustainable.

Yes it is a good idea! But I cannot make any promises. Time is limited

Would you consider adding some video tutorials on how to use Bold? It would be very helpful if the demo databases were PostgreSQL, SQLite, or even Paradox, as this would make it easier to understand the entire concept at once.

Hi everyone, more than twenty-one years ago, I started the German-language part of this forum and could not even begin to imagine what it would become. Thanks to the tireless support of many moderators as well as your thirst for knowledge and willingness to answer other people's questions, it has become a pillar of the virtual Delphi community - even far beyond the German-speaking world. Since 2018, this English-language part of the forum has also been available, with considerable support from Lars. With an online presence of this size comes the obligation to take proper care of it. I have always been very happy to do this, but over twenty-one years is a very long time and life and its priorities change. I can't help but realize that my daily/weekly time has become less available and the time has come for me to hand over the management of the forum to someone else. Thankfully, Thomas B. ("TBx") has agreed to take over the Delphi-PRAXiS and continue it in good hands - together with Lars, of course. You know Thomas as a longtime moderator of this forum and now he will take over my previous role. I myself will of course remain part of the Delphi community - not least because I continue to work a lot with Delphi in my job. I will also remain a part of this forum. Thank you all for over 21 great years!

Inheritance Tree: IEnumerable<T> IReadOnlyCollection<T> ICollection<T> ISet<T> IEnumerable<T> has many functions including Contains: function Contains(const value: T): Boolean; overload; function Contains(const value: T; const comparer: IEqualityComparer<T>): Boolean; overload; function Contains(const value: T; const comparer: TEqualityComparison<T>): Boolean; overload;

Are you sure that poor speed is acceptable on desktop applications? What about applications that need to load complex forms where opening such form can take half a minute or more? Or when you need to create plenty of business objects, or when you need to do some textual processing. Good compiler means a lot in such cases. In last few Delphi releases @Stefan Glienke has continuously submitted hand crafted code to improve speed of some widely used RTL routines that have impact on overall performance. With better compiler that would not be necessary. Not only that, but with better compiler all other code we write would be faster and when speed matters we wouldn't have to bend over backwards, writing horribly unreadable code just to get the speed we need. We could just write the clean and readable and maintainable code and leave the dirty work to the compiler. Speed always matters. Now, Delphi still might be fast enough for many purposes, but for many that is simply not enough. Once it was state of the art compiler, now it is seriously falling behind.

If it weren't for other statements already this one really disqualified you from even participating in any performance-related discussion. I just recently updated from an Ivy Bridge CPU to a Raptor Lake at home and the single-thread performance of some Delphi benchmarks approximately doubled. If you don't believe my sample then simply take a look at https://www.cpubenchmark.net/year-on-year.html You see that in about 10 years the single thread performance approximately doubled (and even less on server hardware). And when we think about how the real gains in performance are achieved these days (parallel computing) Delphi is even in a worse situation given the poor support for anything parallel computing (yes, it can be achieved but you need to handcraft a lot of code and much existing code does not scale well at all).

Well, if you work with databases, everything else feels fast 😛