Rollo62

I highly disagree. For me RadStudio comes already quite close to the high goal "one source - all platforms" idea, at least when talking about simple solutions. This makes a lot sense to me, instead of fumbling around with 3-4 completely different tools, frameworks and concepts. Why did JavaSript can deliver what Delphi is promising ? Because JS uses the standarized force of modern browser engines, sitting on top of the OS. From my point of view, Delphi supports already a lot what those browser engines can do, plus a lot of extra stuff. While the FMX framework with Styles should act as JS, to provide "one source - all platforms". The problem with Delphi is that it doesn't offer the standardized force of Delphi for all platforms yet, its still a long way to go. I would love to see much more of this platform unification and abstraction work, to make Delphi the common core for all OS. By the way This comes sooner than you might think

Maybe there are different kinds of spaces used (like NBSC, or other from strange Unicode char , which might be seen as different characters.

<OT> That means probably a short form of "Guten Morgen" <> "Good morning", but the usually form howto speak this, is "MOIN MOIN" (especially in Hamburg town, where Daniel lives) Maybe the term is doubled, to make very sure that the recipient got the message right </OT>

Have not checked CMR yet, neither Delphi nor FPC. Are the implementatons compatible at least, or is this FLP CMR a completely different animal ?

Maybe all these nice improvements could still be added in CMR V2.0 🙂 Only the choice of ".Create" was not so good indeed, and this could be changed similar to custom constructors in classes. Where then there is the default Create constructor still dangling around. Would be maybe a good idea to add an additional accessibility control, like "hidden, private, protected, public", to hide away Create at compile time, instead of e.g. dirty-hack away the access to Create constructor in classes (although I dislike such basic changes in a language, but such addition would not harm any existing code). Maybe that would make records and classes even more compatible (not sure if that is for good or bad, maybe depends on the viewer).

@Arnaud Bouchez Wait until the next great articles from Erik will arrive, more closer towards the C++ SmartPointer ecosystem. The advantage: its a linear, simple, local record, no ref-counting issues, no TInterfacedObject hazzle. Yes, long waiting for such thing, and it seems Delphi can do it now. ProbablyI need to make some first tests soon.

Hi there, again I just wanted to check out Patch 3 fastly, and end up in a big mess finally. 1. I tried via GetIt, but get this error message Of course I try this on my current workstation, where all serials are registered and OK. 2. I've tried manually via https://my.embarcadero.com , which was proposed as second way to download it, beside the GetIt way. Also there I always got "invalid credentials", either the server is down or I lost my credentials. 3. I'v tried via the old https://members.embarcadero.com and then I see this. 4. I'v tried QC, fortunately this still works for me Is there anybody at Embarcadero who can write a reliable web-service and web-site, please step forward and do something. Already this costs me 30 minutes again, without any success, that is really deadly lost time while we have nicest weather here in summer. Please let me know what I can do now, just sit and wait ?. Shall I post a feature request, that you better should publish your files on GitHub ?

Hi there, I see some strange behaviour here when using Bluetooth with Android in the background. I'm using the permissions BLUETOOTH , BLUETOOTH_ADMIN, ACCESS_COARSE_LOCATION , ACCESS_FINE_LOCATION and there is the new permission ACCESS_BACKGROUND_LOCATION Currently I do not really use lcation at all, only in combination with Bluetooth LE, which requires that. Since I want to use Bluetooth in the background, it seems that I have to set the ACCESS_BACKGROUND_LOCATIONas well. Usually all works well, but I can see a strange effect after first install: Only when the app is first time installled, - I see the first permission alert popping up, and - usually I set location permission to ALWAYS - If I check the system permission dialog, I can see that location ALWAYS is perfectly set in the Android system - ! But Bluetooth LE its NOT working. Only after that I do, - close the app (closing not really needed, also good enough to change the system permission dialog to "WHEN IN USE") - change the location permission to "WHEN IN USE" - open or start the app again - ! opening, after changing the permission, will re-start the app, which is same as close/open So that really close/open is not needed, the system permission change causes the same effect. ! Changing from "WHEN IN USE" to "ALWAYS" doesn't re-start the app. - the app is asking again for location "ALWAYS", as it should - when I set "ALWAYS" (the second time), only then Bluetooth LE is working Conclusions: - So seems to work only from the 2nd time setting "ALWAYS", permission needs to be switched to "WHEN IN USE" once before. - I can also install the app, set permission alert to "WHEN IN USE", and then in system dialog change from "WHEN IN USE" to always, the app doesn't re-start, but seems to work with Bluetooth now. - It needs a sequence with "WHEN IN USE" firstly be required, before switching to "ALWAYS", is that the case ? Any clues what the real reason for this odd behaviour might be ?

Just to finalize this: I could solve the issue, with the help from Phillip in the German DP. After I cleaned-up the permissions, I always used to set COARSE and FINE location both, I've set to COARSE location only, which I was sure that this is good enough to start Bluetooth. But that was a wrong assumption, as the Android documentation tells me here: The strange thing was that BLE started anyhow ignoring that it was not allowed to, after an external permission change back and forth, while I expected a sudden, startup crash (as usual with permisson issues), when touching any of these dangerous APIs. Never saw such half-allowed states before, and I still think this is a kind of Android bug. Maybe I've got used to sudden, startup crashes so much meanwhile, that I don't think twice when they not appear .

Are there any experience with Patch 3 ? I just will move back to Patch 2, since all my Android apps suddenly will crash before start now, and I have no time to deeper look into this. Patch 2 worked more or less more stable for me.

Thats what I meant too: - if device is currently in landscape, - the user switches a button to show a new page which requires Portrait mode - give the user an advice that turning the device is necessary before, or - possible too that the new mode appears automatically, when the user has turned the device into portrait

I still have a "manual" solution implemented, which gives advice to the user howto set-up the right orientation. Not perfect, but no time to search for a better one right now. Since its happening only in a remore place in one app, its acceptable for me.

No, its not worse. Its just stabilizing on a floating level

Its hard to say, usually I would propose to update to 10.4. Because you work on Android, and this fixes the required API-Level 29 stuff, if you only want to work on older API Level 26 (which cannot get into PlayStore probably), then Rx10.3.3 should be fine. But in general the latest version is always best, when it comes to mobile. If its only the \bin\KeyTool.exe. issue, maybe first you try to fix that, sounds doable, or re-install the Rx10.3.2 incl. all Android SDK.

Ok, all the files seems to be younger (around 22.07.20) than the last patch (around 15.07.20), only this one ir older bin/Windows/lldb/embt_formatters.py Thats the log: bin64/vcl270.bpl bin/bccaarm.exe bin/bcciosarm.exe bin/bcciosarm64.exe bin/compclang33.dll bin/gdbdebugcore270.bpl bin/vcl270.bpl bin/vcl270.jdbg bin/win64debugide270.bpl bin/Windows/lldb/embt_formatters.py bin/Windows/lldb/liblldb.dll bin/Windows/lldb/lldb-mi.exe lib/android/debug/librtlhelper.a lib/android/release/librtlhelper.a lib/win32/debug/de/vcl.lib lib/win32/debug/fr/vcl.lib lib/win32/debug/ja/vcl.lib lib/win32/debug/Vcl.Grids.dcu lib/win32/debug/vcl.lib lib/win32/release/de/vcl.lib lib/win32/release/fr/vcl.lib lib/win32/release/ja/vcl.lib lib/win32/release/Vcl.Grids.dcu lib/win32/release/vcl.lib lib/win64/debug/de/vcl.a lib/win64/debug/fr/vcl.a lib/win64/debug/ja/vcl.a lib/win64/debug/vcl.a lib/win64/debug/Vcl.Grids.dcu lib/win64/release/de/vcl.a lib/win64/release/fr/vcl.a lib/win64/release/ja/vcl.a lib/win64/release/vcl.a lib/win64/release/Vcl.Grids.dcu source/vcl/Vcl.Grids.pas

What shall I say, the 5th attempt via GetIt works finally. Again I've lost nearly 1h with all that sh.... Please don't do that all the time to me, Embarcadero. Its so much annoying, you won't believe it.

You probably have installed a wrong JDK version, or updated that, in Rx10.3.3 it should be jdk1.8.0_60 . Maybe you can switch Rx10.3.3 already to the new AdoptOpenJDK, but I'm not sure if that only works from Rx10.4 on. But usually it should be possible, if you adjust all the JDK paths in the SDK Manager of the IDE.

The backup files are there, in a separate folder, and also the file dates were changed as described in Marco Cantu's Blog. Only verifying the file dates has to be so ne manual, which is a little unprofessional .

The programmers ethics ... you can find here

Right, I also use NaN a lot, to make sure that float numbers are not valid.

Then you better catch exceptions and log them in a "invalid data" file or DB. To allow to find them manual rework them later, that would prevent that you are loosing any important information.

I would think that especially with external data, you can never be 100% sure that all works fine. You made a contract to the data known at that certain time, but you cannot predict the future. Maybe your customer changes the contract without noticing you. I think also that the programmer should handle that as careful as possible, but in reality you will always see unexpected data and behaviour. UnitTests might help a lot, also to identify known "wrong data", but who can predict the unkown ? In some cases the system can handle the unexpected gracefully, in some systems you will find hard crashs. To throw an exception in these cases at least may help to prevent further damage. To cover everything in try - finally, and to ignore exceptions is maybe not the best choice to ensure a good data quality. That way nobody gets aware of such (hopefully rare) cases.

Right, GIT works serverless as well. It can be used in very many ways. Moreover to all whats said before: GIT can be integrated with the Delphi IDE (but I don't use that at the moment, but wanted to try out).

But better use GIT then, this also runs standalone just copying 1:1 on a network folder. Same Features, same EXE, makes it easy to scale up .

Yes, they have a PatchTool included, which could verify its own work. Why are so obvious features always missing, to find the failure in the picture by ourself ?