Rollo62

Then you should care, that "visual form editing capabilities" is what I meant by RAD.

I can think of a world with RAD designers, as the best and fastes way to create views, prototypes, and maybe even events and bindigs. Plus a code-centric, MVVM enabled, way to produce the business logic behind in a modern way. Why should that be so hard to bring both concepts (RAD & MVxx ) together in a nice marriage, I never understood that. ? Just open all the options in the framework, and let people create the way they want (and let them also grow with their skills in the same tool). Even if thats a complete rewrite of most the components, that should be worth it. From all other visual designers I have checked so far, the RadStudio I like the most. Thats why I'm on RadStudio. Maybe thats only because of old habits and laziness, but I think the current concept is still best. Maybe the question is not RAD or MVVM, but RAD plus MVVM.

VSC is a great tool, seems to be well thought from ground up, with a zillion users out there. Also consisting of a large ecosystem, with plugins and many supporters. Most important maybe, as said before, the young guys are there: If you want catch attraction to Delphi code in the young generation, then this is a good place to go. VsCode is Open-Platform, mostly used on Macos, because of its coolness factor. By the way: Worth to mention, its free and open source IMHO this is the new way to go, all other IDE look old fashioned against this ( Ok, I know Atom, etc. too, but the winner takes it all).

Maybe Delphi should be designed as a plugin for VsCode, and FMX could be an extension for PlatformIO ( Oh my, TMS is halfway on the direction to that )

Maybe that helps too. I basically moved to TListView, since I find the more reliable supported than TListBox. Although TListBox would be handy in most places.

Yes, they are in VsCode anyway. Installing another Plugin is no big deal. Not sure if in VsCode marketplace is some kind of "Ad" publishing for new plugins. If so, would be maybe great to try to reach all those JS, Node.js developers out there.

@Dave Nottage Yes, no direct solution. But maybe the intent filter could lead to some insights, howto achieve that goal in Java and Delphi.

Good guess IMHO. I only hope that the 75% Delphi-only developer have enough vision to predict the future of desktop-only apps. Many of them might be forced by THEIR customers, to offer a mobile or web-centric solution. See some posts before, the TMS WebCore, what is possible with a little vision, braveness and motivation even for a small company. You don't need the crystal clear glass bowl, to predict the upcoming future, the frozen glass bowl will be sufficient

Have you checked out the Kastri project ?

OnItemClick Your second post shows that too, is that the solution or does it have an issue ?

Not sure what the question really is. procedure TForm1.FormCreate(Sender: TObject); var AppEventService: IFMXApplicationEventService; begin if TPlatformServices.Current.SupportsPlatformService(IFMXApplicationEventService, AppEventService) then AppEventService.SetApplicationEventHandler(HandleAppEvent); // Register the type of intent action that we want to be able to receive. // Note: A corresponding <action> tag must also exist in the <intent-filter> section of AndroidManifest.template.xml. MainActivity.registerIntentAction(TJIntent.JavaClass.ACTION_VIEW); TMessageManager.DefaultManager.SubscribeToMessage(TMessageReceivedNotification, HandleActivityMessage); end; procedure TForm1.HandleActivityMessage(const Sender: TObject; const M: TMessage); begin if M is TMessageReceivedNotification then HandleIntentAction(TMessageReceivedNotification(M).Value); end; function TForm1.HandleAppEvent(AAppEvent: TApplicationEvent; AContext: TObject): Boolean; var StartupIntent: JIntent; begin Result := False; if AAppEvent = TApplicationEvent.BecameActive then begin StartupIntent := MainActivity.getIntent; if StartupIntent <> nil then HandleIntentAction(StartupIntent); end; end; function TForm1.HandleIntentAction(const Data: JIntent): Boolean; var Extras: JBundle; begin Result := False; if Data <> nil then begin Memo1.ClearContent; Extras := Data.getExtras; if Extras <> nil then Memo1.Text := JStringToString(Extras.getString(TJIntent.JavaClass.EXTRA_TEXT)); Invalidate; end; end; HandleIntentAction(const Data: JIntent): Boolean; Is the Action function that is doing the work when the intent is proceeded. While TMessageManager.DefaultManager.SubscribeToMessage(TMessageReceivedNotification, HandleActivityMessage); registers the Handler. and this can be called from two sides, 1. from the handler: HandleIntentAction(TMessageReceivedNotification(M).Value); By the registered callback . 2. StartupIntent := MainActivity.getIntent; if StartupIntent <> nil then HandleIntentAction(StartupIntent); During startup of the app: when the OS puts the app into foreground by selecting the intent. Just looked fastly over this, what exactly is missing ?

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.