Leaderboard

It works with Delphi 🙂 Just received the Mac Mini with the new Apple M1 CPU. After a quick attempt to deploy our FMX app, I can confirm that PAServer runs and I can deploy and run our FMX app without problems. "Rosetta 2" seems to do the job very well!

I know right now code completion is, let's say, not ideal. We hope this will be much better in 10.4.2 - lots of work going into it in this release. You can see this noted on our recent roadmap: https://blogs.embarcadero.com/rad-studio-november-2020-roadmap-pm-commentary/

@Mahdi Safsafi you are the winner! 🙂 I benchmarked 3 methods and results are like this: (time in ms) fncMyHexToBin (Emailx45) = 15722 = 100% Hex2Bin (Mike) = 6170 = 39% HexToBin2 (Mahdi) = 925 = 5% I assume using Pos, For loop and string concatenation kills our performance, @emailx45, while Mahdi's doesn't use any of it. Of course, credit goes also to @David Heffernan because Mahdi's function is evolution of David's example. Thanks! 🙂

No, the zip only contains the source. I have attached another one with a compiled exe and a cfg file. UsesCleaner.zip

UniDAC has a nice feature called Unified SQL (https://www.devart.com/unidac/docs/unisql.htm) which can be used to automatically preprocess SQL statements based on macros and conditionals. Maybe this can help you.

Perhaps you are missing a proper config file (default is UsesCleaner.cfg next to the exe). If there is none, the program will use the default settings which are - well, somewhat special: procedure TSourceFileUsesClauseFormatter.InitSettings; begin UsesHelper.UnitAliases := 'WinTypes=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE;'; UsesHelper.UnitScopeNames := 'Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell'; UsesHelper.SearchPath := 'c:\Program Files (x86)\Embarcadero\Studio\19.0\lib\win32\release'; UsesHelper.GroupNames := '<UnitScopeNames>'; end; In your case, the SearchPath may be the culprit, which may cause the standard units not to be found. A decent config file can look like this (with an adjusted SearchPath entry of course): [Settings] Indentation=2 Compressed=0 MaxLineLength=130 SearchPath=c:\program files (x86)\embarcadero\studio\21.0\lib\Win32\release; UnitAliases=WinTypes=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE; UnitScopeNames=Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;System;Xml;Data;Datasnap;Bde;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell GroupNames=@DelphiOTA;Winapi;System.Win;System;Data;FireDAC;Vcl [Groups] DelphiOTA=ToolsAPI;DesignIntf;DesignEditors

Not that I know of. But you could have a look into the BPLs using the GExperts PE Information Expert. It shows a list of units and classes which the package exports. That would give you a starting point.

The issue with "Delphi support for the latest iOS Simulator" is that the iOS simulator technology is undergoing a complete change. In the past, on Intel Macs you had to build an Intel App the simulator could run. The new ARM Mac would require a different binary target -- so in effect a different compiler. Well, it might not require a new compiler, given the binary is the same that iOS runs... but I think you get the point. If we ere to build an Intel simulator (64 bit) in a little time that would be totally useless... So we rather skip it and jump on the ARM future sooner. I know

The easiest way to kill the compiler is to have huge cyclic unit dependencies. Try to reduce that. Also if the project was created before unit scope names were introduced you should add the scope names to the units in the uses lists and remove from project options in Unit Scope Names.

Hm, when will Microsoft start to rewrite Office to use WinUI? Until that happens, I am skeptical whether this will be worth the effort. But I am only a disgruntled old white man^d^d^d^d^d^d^d^d^dVCL developer.

Even though we are a Delphi forum, we have a considerable number of users of the C++Builder among us. Without shifting the basic focus of this forum, we are aware of the long and close connection between Delphi and C++Builder and therefore want to give its users space for their questions. https://en.delphipraxis.net/forum/41-general-help/

This is the correct solution and the Delphi ide/compiler 64 bits is far. I faced this problem on a daily basis, the project became too big, and a solution adopted by us was to divide the project into packages, so as not to overload with a single compilation. You can for example divide main project, FMX package and RTL package.

I have attached the FMX.InAppPurchase.Mac.pas that we use so it is easy to use for others. All you need is to add it to your project and also add a modified version of FMX.InAppPurchase.pas where you include the file (just search for FMX.InAppPurchase.IOS, and see how that file is added, and do the same with the FMX edition) FMX.InAppPurchase.zip

Did you also set the location permissions (fine should be enough, but fine+coarse do no harm) ?

Only once in a year: any delphihtmlcomponents.com product with 44% discount (5 licenses available). Please use coupon code HB2020.

Perhaps this may help a bit: UsesCleanerSource.zip

There are quite a few different avenues you could take to support API development. The first step in any is to get it "to work" which you seemed to have accomplished! Your next question is valid - will it scale? The question remains, how much do you need it to scale? How many concurrent connections are planned, what sort of total throughput is required and what are acceptable latencies? Once you define those, you can test those things yourself by using tools like JMeter and BlazeMeter and see if your performance is acceptable. If it's not, then you can look at scaling methods, either locally with Windows Clusters or migrating to cloud services on AWS or Azure. If the performance isn't satisfactory, you could also look into different implementations. One of the most commonly used frameworks is mORMot which has been highly optimized. If you join their community you'll likely get some help getting started. There's a LOT of code available, and much you can ignore to get started. Another option is to get a commercial finely-tuned multi-tier approach from Components4Developers. This option has been around a very long time and is quite mature, and quite performant. Another commercial option to look into is the Remoting SDK from remobjects. This also has been around quite a long time and is widely used. For a real simple and performant commercial toolkit, also look at RealThinClient components. There are plenty of other choices out there. The next step that I would recommend is to analyze your projected usage and start establishing some real testing metrics that you can validate current and future decisions on. Get the tools in place to back up your API infrastructure with measurements and validation. In addition to API testing, get line-by-line performance measurements with ProDelphi or Nexus Quality Suite to track down different implementations.

Available at https://blogs.embarcadero.com/rad-studio-roadmap-november-2020/ Also, PM commentary at https://blogs.embarcadero.com/rad-studio-november-2020-roadmap-pm-commentary/

That's news to me 🙂 I see now from an email that you said I should share what I did for you.. which I will do soon.

@David Heffernan Few remarks about your code if you don't mind : 1- Its pointless to use string when characters are fixed in size ... Simply use static array of X char. 2- Its also pointless to calculate index when you already used a case ... Simply declare your array using char-range. In your case, compiler generated additional instructions to compute the index. function HexToBin2(const HexValue: string): string; type TChar4 = array [0 .. 3] of Char; PChar4 = ^TChar4; const Table1: array ['0' .. '9'] of TChar4 = ('0000', '0001', '0010', '0011', '0100', '0101', '0110', '0111', '1000', '1001'); Table2: array ['a' .. 'f'] of TChar4 = ('1010', '1011', '1100', '1101', '1110', '1111'); var HexDigit: Char; P: PChar4; begin SetLength(Result, Length(HexValue) * 4); P := PChar4(Result); for HexDigit in HexValue do begin case HexDigit of '0' .. '9': P^ := Table1[HexDigit]; 'a' .. 'f': P^ := Table2[HexDigit]; 'A' .. 'F': P^ := Table2[Chr(Ord(HexDigit) xor $20)]; else raise EConvertError.CreateFmt('Invalid hex digit ''%s'' found in ''%s''', [HexDigit, HexValue]); end; Inc(P); end; end;

Hi All For those who are interested, I have made some progress on this project, and have uploaded an installer with the command line tool and IDE plugins for XE2-10.4 - it's still very much an alpha version (not feature complete or stable) but at least shows the direction I'm heading in. I have added some quick notes on how to get started with dpm https://github.com/DelphiPackageManager/DPM/blob/master/GettingStarted.md The installer can be found here https://github.com/DelphiPackageManager/DPM The IDE plugin is still a bit rough around the edges but reasonably stable. Note that installing design time packages is still being worked on. Most of my open source projects have package binaries under the releases tab (the getting started notes show what to do with them). It's still some way from being ready for production use, we are still working on a website/package repository. If you are a library author, please do take a look. Creating packages is not at all difficult.

Hi Wagner I'm working towards the design time support, it will take a while but I'll get there eventually. Once I have it working I'll email you again and we can see how it will work with your products.

Hi Jaun, Thank you so much for coming back to me so quickly, I tested the above and that done the trick! I also spotted a problem with my release version, long story short, I forgot to tick the “Generate Android App Bundle file (arm + arm64) in the “Compiling” option with the target set to "Android Release 64bit", I ticked this and re-published my app and that sorted the release version. Thank you again. Neil

64bit IDE is not question of easiness. It is also question of 3rd party libraries and design packages support. You cannot mix 32bit and 64bit DLLs so having 64bit IDE would mean everyone would need to provide their components and plugins as 64bit versions, too. Also, because you cannot mix 32bit and 64bit DLLs in a process, there is question of other parts of the Delphi IDE - this is not just Editor, but also compiler, linker, debugger... not everything is written in Delphi and porting any of the necessary parts to 64bit may not be straight forward. Easy part of 64bit transition is about Delphi applications, even though depending on your code you may have smooth or bumpy ride, too. I didn't have to do any adjustments for my code, because I never used any hacks around integer - pointers casting and I always had bitness explicitly specified for any data types I have used. So, generally most of transition to 64bit should be easy, but it also depends on specific projects and other libraries, plugins and interactions they might have and use. Scaling is bit different story... VCL Styles originally didn't have High DPI support, and when they were added to IDE theming in Rio they were still without High DPI support... now they have High DPI support, but tweaking the IDE to fully work under High DPI does require some work. This part would be the same with or without VCL Styles. I would first make IDE high DPI aware and then add styles... but that is me... why are some things done the way they are, I have no idea.

Hi Lars Not possible. As a workaround, I created computed (calculated) fields and used them in the group by clause.