Rollo62

Yes, that seems a good choice, but maybe you can clarify a few questions, which would be important. In some place they declare something, in other places they stay a little more vage, so it would be great to know if everything is supported as expected. # Is this product based on or related to Indy, or just cooperates with Indy, or is completely different, standalone and not-compatible? # Are all platforms natively and fully supported (in other places they descibe this not so clear)? As stated here: https://www.devart.com/sbridge/compatibility.html Supported Target Platforms Windows 32-bit and 64-bit macOS 64-bit and ARM (macOS Apple M1) Linux 32-bit (only in Lazarus and Free Pascal) and 64-bit iOS 64-bit iOS Simulator ARM 64-bit Android 32-bit and 64-bit # Are any pre-compiled static or dynamic binary libraries or SDKs needed, are they included or are sources included to compile them externally? Or is everything pure pascal source? # How is SSL ( OpenSSL ) supported, as binary library, or pascal unit?

Hi there, sorry for the little joke in the title, but what currently makes me headaches is the fact that after May will be broken. I used iOS as stable debugging platform for many years now, which seems to breakdown hard in a few days. The alternative Android was never that stable for debugging over the same many years, getting better now, but no replacement. The big problem now is, that Apple seems to enfore the use of their latest tools after 01.05.2024, which would make the use of XCode 14.3.1 for releases impossible. For the possible XCode changes and reasons I figured out the following possible facts for my record. Perhaps they were not all correct, maybe only a few, so please feel free to correct me, if you have more insights into the XCode ecosystem. In general, there seems to be a huge change in the new XCode debugging system. Overview of the changes seen in XCode 15: Topic Old (Xcode 14.3.1) New (Xcode 15) Comments Debugging platform partly still 32-bit using 64-bit only The new debugging platform seems to remove older 32-bit code internally completely. Debugging Framework GDB-based LLDB-based New debugging framework based on LLDB, incompatible with older GDB-based framework. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Debugging Libraries libgcc.dylib, libc++.dylib, New debugging libraries, incompatible with the older libraries used by D12.1. libstdc++.dylib libc++abi.dylib Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Symbolication Manual Automatic Xcode 15 introduces automatic symbolication, incompatible with manual symbolication used by D12.1. Debugging Protocol GDB protocol LLDB protocol New debugging protocol, incompatible with the older GDB protocol used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Breakpoint Handling Software breakpoints Hardware breakpoints Uses hardware breakpoints, incompatible with the software breakpoints used by D12.1. Debug Information STABS debug format DWARF debug format New debug information format, incompatible with the older STABS format used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers I would like to know if this huge XCode change is really upcoming soon, and what can we do about it in the near future? Is there any workaround in sight? I'm afraid, that we have to wait for the next Delphi Update or Patch, which maybe changes a lot of the internals ( libraries, PAServer, workflows, ... ). Are there any news from Embarcadero, about this topic, so that we could see any light in the tunnel? Would be great if there is a way, to make XCode 15 compatible with Delphi, or vice versa. My considerations so far: - Use Android for Debugging, even if it not that stable. Perhaps there are ways to improve Android debugging too. - Forget Mobile debugging, rely only on Logging ( the worst case for me ). - Still use XCode 14.3.1 for debugging, while releasing under XCode 15. This is problematic, because I think XCode 14.3.1 dosen't allow to use iOS 17.4, and perhaps two versions cannot switch easily on the macOS host. Are there any tested workflows, like xcode-select --switch /Applications/Xcode14.app/Contents/Developer and xcode-select --switch /Applications/Xcode15.app/Contents/Developer ? That also means, we would possibly need two sorts of devices with iOS 16.x ( DEBUG + Log ) and iOS 17.4 ( RELEASE + Log ) for proper tests ( Permanent upgrade / downgrade is not an option ). - Embarcadero already had worked out a stable Update 2, to simply make iOS 17.4 debuggable and testable. ( The best case for me ). - Any smart hack, to make XCode 14.3.1 producing releases still? Perhaps, setting a build-ID could do the job, but I'm completely unsure about that. When Apple finds such hacks, this may also be considered as infringement and lead in blocking the app in the store, which could be even harder. - Other ideas / news / thoughs, are there any ? Edit: See above table, it seems that Delphi >= Alexandria can already make use of LLDB debugging system: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers

Like said, maybe you even need more decoupling, by a timer. Perhaps Android needs a while interally to build and save a PDF in the background, if PdfView kicks in too soon, that could maybe lead to odd behaviours.

Maybe this has also to be considered https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#FireDAC_SQLite_Version_Update https://blogs.embarcadero.com/new-firedac-driver-for-sqlite-see/ https://www.youtube.com/watch?v=hhzkxjYKv-g When using encryption, you seemed to be locked in into an older version from 2020, if I understand this right. Either you use the paid EE, or the outdated FDE.

Yes, I checked that, its a very heavy and mighty DB that needs a lot of maintainance attention, IMHO. It can do much more, what I ever will need probably. I do like the more light weight DB, which are more easy to handle and with a less steep learning curve.

I would not use any of those for a local app, that doesn't really hardly requires any of the big ones. The locical steps for me would be 1. Sqlite, 2. Firebird Embedded or Server, 3. only if that is not good enough something bigger. Mysql (or better MariaDB) would be the next logical step (3.) for me, PostgreSQL is quite heavy weight, but I have not much experience with it, perhaps its capable for doing huge stuff. SQL Server binds you more to the Microsoft environment, if that is no issue for you. I was forces to use SQL Anywhere once and I was no big fan of that either. In the end, all SQL DB should work fine, at the SQL level, then maybe the small differences appear more important. Like drivers, like OS and general support, like portability, like certain SQL specialities (e.g. full text searc h), and so on. Generally I tend to stay with the most basic SQL sets anyway, which would allow me to switch easily between DBs anyway. What I can say is that Sqlite is perfect for local DB under all OS, thats the usual choice. Firebird server works also rock solid, even when not eagerly maintained, this really astound me how this runs untouched over many years. Interbase IBToGo is maybe a good choice for cross-platform too.

Sqlite can be used in large, production-ready sites, you could have a look what Pieter Levels does with Sqlite, PHP, JQuery only, like back to the roots. https://news.ycombinator.com/item?id=23359023 https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.youtube.com/watch%3Fv%3DB-_P0d1el2k&ved=2ahUKEwjJxILl-PuIAxXFSPEDHTKKOr8QtwJ6BAgKEAI&usg=AOvVaw0ESb4TJ_wTRTzhSmsFX7ot

Maybe that can give some ideas, although for Win and VCL. https://stackoverflow.com/questions/38273974/delphi-components-and-screen-readers Perhaps this can be implemented in similar ways on Android too? But I doubt it will be already well prepared under FMX, habe not checked recently. Edit: Maybe you can check, if this might work for you ( untested ) : But I doubt that the Delphi handle works as expected. uses System.SysUtils, FMX.Types, FMX.Controls, FMX.Platform, FMX.Platform.Android, Androidapi.JNI.GraphicsContentViewText, Androidapi.Helpers, Androidapi.JNI.Widget; ... procedure SetControlAccessibilityDescription(AControl: TControl; const ADescription: string); var NativeView: JView; begin NativeView := WindowHandleToPlatform(AControl.Handle).View; if NativeView <> nil then begin NativeView.setContentDescription(StringToJString(ADescription)); end else begin raise Exception.Create('Das View-Objekt konnte nicht abgerufen werden.'); end; end; ... // Application for Label SetControlAccessibilityDescription(Label1, 'Das ist eine Beschriftung für den Namen'); ... // Application for Edit SetControlAccessibilityDescription(Edit1, 'Bitte geben Sie Ihren Namen ein'); ... // Application for Checkbox SetControlAccessibilityDescription(CheckBox1, 'Ich akzeptiere die Nutzungsbedingungen'); ... // Application for Switch SetControlAccessibilityDescription(Switch1, 'Benachrichtigungen ein- oder ausschalten');

But this would run fine too. procedure Test; begin Abort; end; It should be good enough to use fully qualified names only in cases of ambiguity, IMHO. The compiler shows such cases. But in the uses clause I always use fully qualified names.

Maybe these lists are intersting too, although not 1:1 what you're asking for: https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List https://en.wikipedia.org/wiki/History_of_Delphi_(software)

Usually I try to use fully qualified namespaces only, in the unit and uses definitions. Still I can see that many code may use "partly" or "mixed" qualified namespaces, like this: unit MyCompany.Libs.MyUnit1； uses System.Classes, // Fully qualified name. SysUtils, // Generic name. MyCompany.Libs.Unit2, // Fully qualified name. UnitX; // Generic name. Are there any insights how this behaves, will the resolver of namespaces work on each single name separately and make a separate decision, or will the whole "uses" switched into a different, generic mode? The fully qualified name should be the most performant, and the total generic name should be the least performant, IMHO. What about a mixture of that, is it exactly according to the number of generic name count in those uses, or does it behave worse than that, more like if all where generic names?

Some more details on CmonLib TInitialize here too https://en.delphipraxis.net/topic/11986-best-way-to-set-early-global-variables-in-a-project-before-build-time/

In some rare cases I add a "Module_Init();" function in such units, which can be called from the caller unit or initialization process, to have a little bit better manual control over the initialization order.

Here are some libraries, some were not free unfortunately https://github.com/landgraf-dev/aws-sdk-delphi https://www.tmssoftware.com/site/tmsfnccloudpack.asp# https://www.appercept.com/ https://www.esegece.com/openapi/apis/amazon-aws-sdk

For me it was quite the opposite. Ok, Claude gives a more short answer generally, while CGPT might give longer explanations in more detail. But Claude for example seems to hallucinate specific abbreviations, like this '"Holistic Supply Chain Compliance Report (HSCCR)", which I think nobody is using in the real world. Such hallucinations I had never seen with CGPT in the whole last year, it was always quite precise and spot-on. Perhaps it depends a lot for what you are going to use it mainly, in my case, it not 100% for coding.

Simulation doesnt help much with IoT Devices, unfortunalely.

OpenAI is the most capable, now also as Version ChatGPT o1

You can follow my Odysee here https://en.delphipraxis.net/topic/11463-ios-xcode-15-madda-make-delphi-debugging-again-after-01may-2024/?tab=comments#comment-90929 Not happy debugging here either, so my silent hope was 12.2. But it turns out, that Delphi 12.2 doesn'T change andything, as they told us yesterday. I'm still preparing my move to Delphi 12.2 for testing, so I still have min imal hope 🙂

https://www.youtube.com/watch?v=E73cMk856xM&list=PLwUPJvR9mZHisbPqXfMYk6JOzx_5IF_k6&index=1 https://youtu.be/E73cMk856xM?list=PLwUPJvR9mZHisbPqXfMYk6JOzx_5IF_k6

....

Perhaps it would even better to decouple this a little more, to be on the safe(r) side against timing problems on different OS and hardware. This is what I would usually do, if not really give a delay inbetween, like 50ms or so: TabControl1.SetActiveTabWithTransition(TabItem17, TTabTransition.Slide, TTabTransitionDirection.Normal); TThread.ForceQueu( nil, procedure begin FPDFControl.LoadPDF(sFile); end );

Sorry, that was the least biased answer, to such an wildly general and fully open question

Ask ChatGPT, to get a good overview and strike-out what you don't need. 1. Sales Management Core Product Catalog Management: Ability to add, edit, and delete products. Support for categories, subcategories, and variants. Price management, including discounts and promotions. Inventory Management: Real-time inventory tracking. Stock level alerts and reordering management. Support for multiple warehouses or storage locations. Order Processing: Support for creating and managing sales orders. Integration with inventory to update stock levels automatically. Invoice generation and tracking. Customer Management: Basic CRM functionalities (customer profiles, purchase history). Ability to manage customer-specific pricing and discounts. Loyalty programs and reward points. 2. Point of Sale (POS) Core Sales Interface: User-friendly interface for processing sales quickly. Support for multiple payment methods (cash, credit card, mobile payments). Ability to handle returns, exchanges, and refunds. Receipt Management: Printing or emailing receipts. Customizable receipt templates. User Management: Role-based access control (cashiers, managers). Sales tracking by user for performance monitoring. Offline Mode: Ability to process sales offline with synchronization once reconnected. 3. Analytics and Reporting Sales Reports: Daily, weekly, and monthly sales reports. Product performance analytics. Inventory Reports: Stock movement reports. Alerts for low stock or overstocked items. Customer Reports: Sales by customer. Loyalty program reports. 4. Security and Compliance Data Encryption: Encrypt sensitive customer and payment data. Compliance: Ensure the software complies with local regulations (e.g., GDPR for data privacy, PCI DSS for payment security). Backup and Recovery: Regular backups and easy recovery options. 5. Integration and Extensibility Payment Gateway Integration: Support for major payment gateways. Third-Party Software Integration: Basic API support for integration with other systems (e.g., accounting software). Extension Modules: Allow for easy addition of new features or modules as the product evolves. 6. User Experience and Support Multi-language Support (if applicable for the target market). Onboarding and Training: Basic user tutorials or help sections. Customer Support: Mechanism for users to contact support (e.g., chat or email integration). 7. Deployment and Maintenance Cloud or On-premise Options: Depending on the target market, offer a cloud-based solution or an on-premise installation. Automatic Updates: Seamless update mechanism for new features and security patches. Optional but Valuable Modules: Mobile POS: Mobile application or web interface for sales on-the-go. E-commerce Integration: Sync inventory and sales with an online store. Advanced CRM: More detailed customer insights and marketing tools.

Not shure if this is what you need, but are you aware that you can use several interfaces, to define and separate several sub-structures in the same class? Maybe that is interesting for you too: IapShape = interface procedure SetThing(AThing: Boolean); property Thing: Boolean read FThing write SetThing; // Error here: Field or method identifier expected end; IapRectangle = interface ... end; TapRectangle = class(TRectangle, IapShape, IapRectangle) private FThing: Boolean; procedure SetThing(AThing: Boolean); public property Thing: Boolean read FThing write SetThing; end; IapTriangle = interface ... end; TapRectangle = class(TRectangle, IapShape, IapTriangle ) private FThing: Boolean; procedure SetThing(AThing: Boolean); public property Thing: Boolean read FThing write SetThing; end;

Not sure, but have you tried this: ListItemText.Text := 'This is a non-breaking space:' + #$00A0 + 'here.';