Leaderboard

False. I'm not disagreeing that the IDE should be 64-bit by now, but there are still major applications that need to build 32-bit targets. But all that means is that we still need 32-bit compilers, it has nothing to do with the bitness of the IDE.

Yeah, looks like a performance issue. Some things you could try (but before that please run more tests with other input controls, animations, tabs, timers, etc. so you know if the issue is visual or general performance): - Change your Form's Quality to HighPerformance - Switch to native controls - Test with Skia4Delphi - Try with third-party controls like Alcinoe or FGX (never tested these personally) However if the performance culprit is not merely visual (i.e. impacts the RTL) then the best option could be, if possible, to work with the device manufacturer / docs and check if something can be done at their OS level. Good luck.

Just like he "publicly stated" that 640k would always be enough memory, right? Actually, there is no evidence of either statement. The 640k thing is directly disputed by Gates and nobody has any direct source for the statement. Internal memos at MS disagree with the latter "quote" ( https://www.cnbc.com/2020/05/26/how-bill-gates-described-the-internet-tidal-wave-in-1995.html ) I have no love for Gates, but people should stop perpetrating those myths, as it is unjust to attribute statements to people with no actual evidence they ever said something. As to the other stuff, MS-DOS and Windows did not need to focus on high-powered shell programmability. It seems obvious to me that their target audience was not Unix gurus. Be that as it may, that is all ancient history and you can use full *nix shells on Windows now if you want to. What I don't really understand is why anyone who dislikes Windows so much would willingly become a Delphi developer. Delphi started as a Windows development tool and that is still its strength.

See also: http://rvelthuis.de/articles/articles-convert.html#varargs

This has been done using compiler magic. You can not create such a function.

Yes I knew about the hardware token but I honestly tough that they apply only to the EV (my first certificate was an EV). Maybe because of the wording? Even the article that rvk pointed to, uses some strange wording "for standard code signing certificates" instead of the "OV". Basically, those 300 words of that article can be summarized as: "the rules for storing EV now also apply to OV". Dang it! _____________ PS: for completeness of information, the missing parameter from the command line to sing an exe file WITH a time server is: /tr http://timestamp.digicert.com /td SHA256 😞

So your certificate has been issued in 2022 and thus doesn't fall under the new hardware rules. You can use it as long as it is valid, but then you need one of the new ones bound to a hardware token.

Nope. That is old fact: If an unsigned executable has been downloaded and executed by many users over a long period without triggering significant antivirus or security alerts, systems like Microsoft's SmartScreen may assign it a positive reputation. I was in that situation. I also have a few small "blue" programs now. ________ Anyway, I added a time stamp to my signature/exe now. What is strange is that I had it before. I remember seeing the date in the "digital signature". This is why I highlight in a precious post that the timestamp is "Not available". So, I wake up my old backup HDD and dig some old programs and found that up to a certain date some, of them had proper signature. Probably somewhere along the road I f****d up the command line..... ________ Anyway, the discussion started from the fact that you cannot sign today an exe file without an electronic device. If you certificate is old enough, you can 🙂 But yes, it will be sad when I will have to upgrade my current certificate.

Just start to be realistic and first of all fix bugs Knock out all platforms expect Windows family (for rest that's what lazarus/fpc is for) and focus only on Windows and VCL + native support for ARM. Performance is poor, look how much optimization they do in C# in many aspects c#(net 9.0) code is already much faster than Delphi. Don't delude yourself that the shrinking business and extinct delphi programmers(sad but true) will make this a wishful thinking gig.... Sadly, no, either you have a product for everything (that is, for nothing, with 1000 bugs more or less serious), or you focus on a narrow field and polish it like a diamond. Dear coders, stop mas****ating to this extinct product with disastrous management by old dinosaur boomers. Come down to Earth. Maintaining all those features with all new is definetely too much for them. It only looks good in theory and marketing slogans.

Because they charge your $130 for that USB stick (so called "packing and handling fees"). They make more money from that USB than they make from the token itself.

Hi @robfr If the Mac mini and the PC are on the same network you should have no problem between PAServer on the Mac and RAD Server on the PC except if a firewall block the communication. I wrote a post about that a few years ago at https://developpeur-pascal.fr/se-preparer-a-developper-pour-mac-os-x-depuis-windows-avec-delphi--rad-studio.html On the PC : - copy PAServer.pkg from the RAD Studio installation folder and install it on your Mac On the Mac : - you need Xcode - you need PAServer - start PAServer, don't put a password when it ask for one and use "i" to show current IP address and "v" to show the log On the PC : - start RAD Studio - go to Tools / Options / Depoyment / Platform profiles (or something like that, I don't remember the English text) - add a new profile and give it the IP address shown by PAServer - test the connection It should not be more complex than that. A "ping" from the Mac to the PC IP and from the PC IP to the Mac are supposed to work. If PAServer can't show an IP, the problem is somewhere on the Mac and it's network connectivity. If RAD Studio can't connect to PAServer, it can be blocked by a firewall on Windows (or sometimes an antivirus like McAfee).

Compiled the app on Delphi 10.4.2, tested on a Samsung J2 Core device (Android 8.1) and didn't notice any considerable lag/delay. Screen record below: rec3.mp4 Could be. Maybe some OS customization is causing FMX to perform poorly. Try to run an app with simple animations or content scroll.

You write way to long posts! If you like so much Unix shell, use Cygwin under Windows: it has it all.

I tried it on a Samsung A13 and all the keys respond the same way, without any apparent delay (D12)

The question is whether they can do something about it at all. For start, Skia in Delphi operates on several layers of indirection (including some poor design choices) which also involve memory intensive operations on each paint (including reference counting). When you add FireMonkey on top that is additional layer. Now, all that does make Skia slower than it could be. But that problem exists on all platforms. ARM and especially Apple Silicon have better performance when it comes to reference counting, but that is probably still not enough to explain the difference. Some of the difference can also be explained with juggling memory between CPU and GPU on Windows as those other platforms use unified memory for CPU/GPU. However, my son Rene (who spends his days fiddling with GPU rendering stuff) said that from the way CPU and GPU behaves when running Skia benchmark test, that all this still might not be enough to explain observed difference, and that tiled based rendering on those other platforms could play a significant role. Another question is how Skia painting actually works underneath all those layers and whether there is some additional batching of operations or not. @Hans♫ Do the Macs you tested it on have Apple Silicon? If they do then they also support tile based rendering. As far a solutions are concerned, it is always possible to achieve some speedups by reusing an caching some objects that are unnecessarily allocated on the fly, those could be both in FMX code itself, or in how FMX controls are used and how many are them on the screen. I used to create custom controls that would cache and reuse some FMX graphic objects when painting instead of creating complex layouts with many individual FMX controls.

I find it interesting that you clearly knew how to access the element values in the 1st range-for loop, but didn't know how to do the exact same thing in the 2nd range-for loop.