Darian Miller

Nice. Is there a specific list of fixes you offer for 10.4 VCL Styles?

It looks nice. Do you include any specific fixes for VCL Styling in 10.4?

nSoftware has an E-Payment Integrator that supports Stripe: https://www.nsoftware.com/in/epayment/ https://www.nsoftware.com/kb/xml/02191401.rst If you are interested, then I would suggest that you buy their full Red Carpet Subscription instead of a single component. https://www.nsoftware.com/subscriptions/ They have a rather large component set and they offer support for multiple languages. Talk to Irida Haznedar, my account rep and see if you can get a discount. (sales@nsoftware.com) nSoftware is a highly recommended company.

I'm currently in the same situation of looking at the SynEdit-2 vs SynEdit. I originally picked SynEdit-2 by Pyscripter due to his changes, but am now using the github/SynEdit version due to Gutter.ShowModification support. Do you have your customizations on GitHub somewhere? The word wrap issue (assuming: https://stackoverflow.com/questions/54494905/how-to-make-tsynedits-wordwrap-same-as-tmemos) is a problem in all 3 of the projects. I haven't checked out the FPC version yet. Have you tried a pull request of your modifications to either SynEdit or SynEdit-2?

https://quality.embarcadero.com/browse/RSP-29639 var c1,c2,c3:Char; p:PChar; begin c1 := 'A'; p := PChar(c1); showmessage(p^); //10.3.3 Access Violation. 10.4 "A" c2 := Char(p); showmessage(c2); //10.3.3 "A" 10.4 Not "A" c3:= 'B'; p := Addr(c3); showmessage(p^); //10.3.3 + 10.4: "B" end;

I haven't seen any lock ups or AV's on 10.4. Maybe it's your environment / third party controls / add-ins.. do you have any IDE Experts installed? My problem with 10.4 is Code Insight. It's awesome when it works, but it falls apart over time.

For what it's worth, setting the VCL style in the DPR before the forms are created does seem to help with flicker (if you aren't already doing that.)

+1 now up to 58

This is fantastic! Thank you.

I agree! I had switched to QP to type up a new issue and thought the same thing. When I closed that window, this window beeped with your reply - must be good karma!

I've seen multiple cases of a timeout of 200ms returning in 160ms when running within VMWare. My first stress test included a fudge factor for returning too early just for that reason.

A new Quality Portal issue could be raised to ensure that the timeout values of the queue are >= 16ms. Anything less is apparently not achievable based on earlier comments in this thread.

1. Windows 10 build 18363. i7-7700K 4.2GHz, 4 cores, 8 logical processors, 64GB RAM. 2. pyscripter explained why a low pop timeout fails earlier in this thread and is why there's a minimum of 20ms in the stress tester now. The test originally failed less in a virtual environment (VMWare Workstation) so I switched to testing on physical machine. On Win32, you can try throwing more threads and run into problems, likely more with Windows than Delphi. I tested with 1,000 threads without any issue. Win64 could handle 50,000 threads without failing.

Two stress tests just completed without error after running for 24 hours straight: Win32 and Win64 running 1,000 threads each with a 20ms timeout with your latest MonitorWaitStackFix.pas.

I updated the GitHub repo with your changes and am running two more day-long tests (win32+win64) both with 1,000 threads and 20ms pop-timeout on Windows 10 physical machine. My last 24-hour Win32 stress test completed without failure. https://github.com/ideasawakened/DelphiKB/commits/master/Delphi Tests/Source/rtl/common/System.Generics.Collections/TThreadedQueue/StressTestPopItem