Leaderboard

v3.0.1 Increase default form quality of Skia4Delphi Canvas in Android and iOS; Improve documentation about Righ-To-Left text rendering with Skia4Delphi Canvas; Fixed demo in Android 11; Fixed exception in ExcludeClipRect; Fixed quality of DrawImage of Skia4Delphi Canvas; Fixed some wrong pixel format in Android and iOS (without metal) that caused wrong colors of TCameraComponet; Fixed opacity of TSkAnimatedImage, TSkLabel and TSkSVG when using Skia4Delphi Canvas; Fixed TSkSVG cache; Fixed compilation with FmxLinux; Fixed FontWeight in FmxLinux; Fixed PDF viewer of demo in FmxLinux; Fixed setup and improve the logs; Fixed build.sh script; Fixed chocolatey package; v3.0.2 Fixed pixelformat of TBitmap of Skia4Delphi Canvas; Github: github.com/skia4delphi/skia4delphi Website: skia4delphi.org

Maybe they are updating it for Delphi 11.1?? Says he with a hopeful thought...

We considered that URL to be the "documentation site" for the GraphQL library. It's analog, for example, to https://doc.tmssoftware.com/biz/aurelius (for TMS Aurelius) or https://doc.tmssoftware.com/flexcel/vcl (for TMS Flexcel), which are also separated "sites" from the main TMS site and the official product pages (downloads, orders, etc.). If you pay attention it's the same structure and output, we used the same tool to generate the content for the three of them. The fact the URL is https://graphql-delphi.com instead of something like doc.tmssoftware.com/graphql is simply a matter of trying to comply with the "pattern" of other GraphQL libraries out there, like graphql-java.com, https://graphql-dotnet.github.io or https://graphene-python.org.

Single person, two player, Thumb against thumb, Ball Basher for Robots. Juggle up to twelve sphere's of galactic matter in outer space. SpaceBallz Started out as a quick pong demo, but with Alexandria's grace, it turned into SpaceBallz!! A game in a class. I can do 12 balls for about 4 mins. It's a birthday present for Delphi. Sorry, I'm poor, have to take a hand made gift for now. Happy Birthday DELPHI!! ~q

You could do that but then you would have to use a ring buffer or something like it. It's much easier if you: Producer (probably main thread): Allocate a buffer and place it in a pool (just a list of buffers). Grab a buffer from the pool. Goto 1 if the pool is empty. Read data, process it and write to the buffer. Place the buffer into a FIFO queue. Goto 2. Consumer (a dedicated thread): Fetch a buffer from the FIFO queue. Write buffer to disk. Place buffer in buffer pool. Goto 1 You will need some synchronization primitives to control access to the FIFO queue and to signal the writer thread when there's data in the queue. It's common to use a semaphore for this. We can't make the disk faster but we can do something useful while we're waiting for the disk.

Must be one of your plugins never noticed that problem.

One observation: in unit Vcl.Forms there's an optimization in tCustomForm.WMDPICHanged which ensures that a form is only re-scaled when Message.YDPI is unequal to fCurrentPPI. Assuming that fCurrentPPI may not be perfectly reliable, I have removed that optimization just for testing. And bingo, my form now appears to re-scale properly every time. //unit vcl.forms.pas method tCustomForm.WMDPICHANGED if (* (Message.YDpi <> fCurrentppi) *) and Scaled then begin DoBeforeMonitorDpiChanged(fCurrentppi, Message.YDpi); OldPPI := fCurrentppi; ScaleForPPIRect(Message.YDpi, Message.ScaledRect); FCurrentPPI := Message.YDpi; fPixelsPerInch := FCurrentPPI; DoAfterMonitorDpiChanged(OldPPI, FCurrentPPI); end; Also I've found out that constraints may be problematic in Delphi. Normally, when a form is dragged to a new monitor having a different scaling factor and its center reaches the new monitor, Windows sends a wm_dpichanged message to the window's wndproc to inform it of the new resolution and also gives it a pointer to a rectangle containing a proposed new position and size. The form must then redraw itself using the proposed position and size to ensure that the scaled window is definitely on that new monitor. However, constraints in VCL components can enforce size limits to components and to the form itself. So it may very well be that after the positioning and resizing, the center of the form is suddenly back on the previous monitor ...

No need for that. Just run it in a profiler and you will know exactly which statements you should concentrate your efforts on.

@pyscripter, you pointed me in the right direction, but I think your syntax is off (I'm guessing just a typo.) Here's what worked: var SList := Shared.Make<TStringList>(TStringList.Create(dupIgnore, True, False)); Unlike some of my other tries this one just creates a single StringList with the correct parameters. I mention that just because some of my other syntax tests created a parameter-less StringList, immediately freed it, and then created the dupIgnore one. This syntax above seems to do the trick! Thanks! Also @Vincent Parrett I think you're right about Shared<>.Make! It turns out I was using the wrong "thing". Shared.Make<> vs Shared<>.Make.

I think var SList := Shared<TMyStringList>.Make(TMyStringList.Create(dupIgnore, True, False)); should work.

I don't believe this would be possible - Make isn't a method on TStringList - it's a class property on Shared<T> - so I guess it can only use parameterless constructors (happy to be corrected but that's how I read it, haven't used this feature).

Programmers quote?: http://quotes4all.net/quote?id=1487

I never liked McAfree.

My own casual survey leads me to offer this summary: BNF seems to be considered too limiting, and generally not for new work EBNF, though better, suffers from the extensions being numerous and undisciplined, so there seems to be no "standard" EBNF ABNF appears to be more useful than BNF, and better managed than EBNF -- see IETF RFC 5234 Don't shoot me, I didn't mention "right" and "wrong"!

The main trick is to avoid memory allocation, i.e. temporary string allocations. For instance, the less copy() calls, the better. Try to rewrite your code to allocate one single output string per input string. Just parse the input string from left to write, then applying the quotes or dates processing on the fly. Then you could also avoid any input line allocation, and parse the whole input buffer at once. Parsing 100.000 lines could be done much quicker, if properly written. I guess round 500MB/s is easy to reach. For instance, within mORMot, we parse and convert 900MB/s of JSON in pure pascal, including string unquoting.

Hi, I am using IBX on Windows (32 and 64bit) and Android (32 and 64bit). Database = Firebird (2.5 and 3.0). In Delphi 11, I have not found any problem.