Rollo62

Unfortunately, they wont use Delphi, do they?

Thanks for the info. From what I understood, these components came as binary package only, which would be a no-go for me. Can you confirm this, or am I interpreting their specs falsely?

I usually look into market surveys, which phones or brands were selling best https://www.heise.de/news/Smartphone-Markt-hat-sich-2024-erholt-chinesische-Marken-legen-zu-10241291.html#nav_marktanteile__1 Then you have a chance that you are testing on whats your clients are using most. Google Pixel is perhaps the best, most modern and best supported Android phone, which helps to be state-of-the-art, but its market share is quite low still.

Thanks, I know the OrangePi company, I will check that board. Thats a reasonable price, if so much variation in prices exists, its good to have a recommendation like yours.

@tomye Thanks, thats a very interesting project. That makes Rockchip an interesting option, when it comes to neural networks. I assume that you run this project under Android. There are at least some boards in the market that come with Android naturally, are these boards supported by Delphi out-of-the-box, like a Samsung or Pixel phone, or do we need special drivers or other measures, drivers or modules to make it compatible? Maybe you can tell us also something about the hardware you used too, which would be needed to run that smoothly? I assume a Firefly board would be a good choice, but it seems also to be quite costly, about 200 -300 USD. https://en.t-firefly.com/doc/download/207.html While a Radxa Rock 5A is available from 22 USD, I would expect from the data that it has NPU too, perhaps there are some drawbacks for that price. https://radxa.com/products/rock5/5a/ I have not checked where the differences in detail are, I assume both support the NPU in the same way, but I'm not an Rockchip expert. Maybe there are subtle differences in the Rockchip model code, which lead to biggers differences, which CPU model will be the most promising? Do you have recommendations for some capable Rockchip boards for testing, maybe there are many other boards than the two above, which are newer and more powerful, I'm not aware of.

PasLibVLC? https://stackoverflow.com/questions/36567287/delphi-paslibvlc-use-without-installing-vlc-player

What features are most wanted: Under all platforms (Win32, Win64, Macos, iOS, Android, Linux, ...) I would wish to have - A debug experience, that is reliable and shows and behaves consistently under all platforms - A rock solid debugging function, with at least breakpoint, step-over, step-into ... likely the full feature set - A rock solid and consistent debug inspection view, with ability to show on mouseover or inspect, for all structures in the same way - A debug inspection view, that is able to decode all sub-structures of classes or records correctly and is fast and easy to access its underlaying members - A debug inspection view, that defaults to human readable data representation first, while there were options to watch single variables in many views. - A debug inspection view or watch, that can reliably switched between decimal or hex view at least (and even more integer/hex/string/byte array,pointer,... ) - A debug inspection view or watch, maybe on the breakpoint level, that can define the preferred view representation of the current session permanently, for all different views (hoover, inspect, watch,...) The Win32 behaviour is more or less the best reference so far, while other platforms are still not there.

Nice, now I have something very interesting to read in the next cold winter days The whole payment and download experience with PayHip was also extraordinary pleasing, I can recommend that.

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

This is interesting blog https://blogs.embarcadero.com/execute-scripts-and-view-source-with-tedgebrowser/ Perhaps this might work for showing videos, but there is also the possibility that certain Codecs or Plugins were missing, like HLS (.m3u8) : var HTMLContent: string; begin HTMLContent := '<!DOCTYPE html>' + '<html>' + '<body>' + '<video width="640" height="480" controls>' + //either local file '<source src="file:///C:/Pfad/zum/Video.mp4" type="video/mp4">' + //or stream '<source src="https://example.com/stream.m3u8" type="application/x-mpegURL">' + 'Dein Browser unterstützt das Video-Tag nicht.' + '</video>' + '</body>' + '</html>'; EdgeBrowser1.NavigateToString(HTMLContent); end; For accessing local files, there could be the need to add AdditionalBrowserArgument flags https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/working-with-local-content?tabs=dotnetcsharp#loading-local-content-by-navigating-to-a-file-url https://docwiki.embarcadero.com/Libraries/Athens//de/Vcl.Edge.TCustomEdgeBrowser.AdditionalBrowserArguments

Exactly, but if that doesn't set the value reliably, then you can use a second opinion by another internal sensor, or not? While you take that image in the phone, you could try to fix this, in your Android App. If you only read/export images from the Gallery and if you have no own Andoid App inbeteeen, then you have little chance. Still there could be the options to fix images, depending on device dependend information, e.g. Samsung S20 always needs 90° rotation, iPhone 14 doesn't need that. But such list will be huge and fragile and maybe also depends on specific mobile device settings.

This seems to be a general problem, that different phones may behave differently. https://stackoverflow.com/questions/13245556/exif-orientation-tag-value-always-0-for-image-taken-with-portrait-camera-app-and?utm_source=chatgpt.com I have seen this issue in Samsung too. Maybe a solution would be, to manually verify and correct the EXIF data based on the real orientation data of the phone ( measured by the tilt-sensor ), and not alone rely on what samsung tells you.

I tested that some years ago, not sure if that still works. https://github.com/Embarcadero/wordpress-rest-api-client

I'm not sure, if that is still true on modern phones with modern OS, the examples were quite old, from the era before permission discussions perhaps. I would generally recommend to request permission before touching any camera part, that cost not much, and will be considered as good behaviour to ask the user before touching dangerous parts.

Perhaps, but I assume if there is already one custom control, then its very likely that there are several custom components units too, like MyCustomCalendar.pas MyCustomThis.pas MyCustomThat.pas wouldn't it be cleaner to combine the registration for the designer in a common registration unit? MyCustomReg.pas procedure Register; begin RegisterComponents('My Delphi Tools', [TMyCustomCalendar, TMyCustomThis, TMyCustomThat]); end; Just saying, I haven't looked too deep into this, its also fine as-is.

TL;DR; You should consider to separate the combined unit into separate designtime and runtime units. procedure Register; begin RegisterComponents('My Delphi Tools', [TMyCustomCalendar]); end;

Yes, that is strange. I never tried to get a runtime permission for a "normal" permission, but I had expected that the IsPermissionGrant would also work in same way. Since it is not explicitely forbidden anywhere in the docs, at least I find no rule for that, maybe the best place to logically derive this from is here: https://source.android.com/docs/core/permissions/runtime_perms?hl=en It states more or less, that the runtime expressios are intended for >= dangerous permissions, from this we could logically deduct that "normal" permissions doesn't need (or better doesn't allow) such requests. Negative logic is sometimes confusing ...

Aaaah, I see. Its a new business model, using AI for writing poor code, that students will have to correct in their exams. Thats how AI can be perfectly used, you will be incredible rich soon

You could ask me too, thats cheaper

I do ( 3rd from left )

Isn't that a little discriminatory towards other pets? Write a haiku about cats and dogs Whiskers meet wet nose, Silent grace and joyful bark, Peace beneath the sun.

I'm afraid a "move" from older to newer is not possible, but I also would always recommend a new, fresh VM anyway, even if it would be possible, to ensure the always best performance on a new platform. Since the setup of such new machines always may take up to one week, until a setup is fully configured on all platforms, I usually proceed a strict checklist for that. There is a 2 year old post from Germany, about running Delphi on Apple Silicon, maybe that's helpful too ( should be able to be auto-translated ). https://www.youtube.com/watch?v=vc2mLROXWcQ

Yes, that is true, but a reasonable timeframe and roadmap should be there. I would like to see full support for such mission critical topics, either from Embarcadero or other from companies. Now the whole risk is laying on the single developers shoulders, to find a reasonable solution, which will maybe result in many different problematic solutions out there. Our clients have some expectations and we cannot provide solutions to all mobile features right now. I was sure that TMS also had an integrated a solution in their TMS FNC too, but perhaps I was wrong with that, at least they have support for all major external Cloud Payment providers.

Scripts are perhaps not powerful enough or too clumsy to use them easily. Maybe DosCommand is a bridge between both worlds, that works for you and can bring the best of both worlds close together. https://github.com/TurboPack/DOSCommand/blob/master/Demo/Unit4.pas

I wonder why Embarcadero is not offering an easy and stably native payment solution, or at least a valid tutorial howto get there. This unclear technical base and very high risks prevents me from even looking much deeper into this topic. Thats a pity, because the Payment is an essential feature in mobile, same as location, sensor access and web access, IMHO. Perhaps the TMS FNC solutions are a more stable alternative, but I have not looked into this either. https://blogs.embarcadero.com/create-native-and-secure-ios-wallet-enabled-apps-with-delphi-and-c-builder/ I'm afraid the preferred way will be to use external providers, such as Stripe or PayPal, to make things easier. https://blogs.embarcadero.com/rapidly-deploy-blazing-fast-payment-solutions-on-windows/ I hope one day there will be a rock-solid, tested and approved solution for GooglePay and ApplePay anywhere, not just "proof-of-concepts".