Rollo62

Nice products 👍 You forgot to mention iOS, and VCL and LCL ... New Telegram API Component for Windows, Android, ..., OSX and Linux.

I still have no clue what happens here, so I started another CrossPost in the German DP.

Yes, absolutely. I would add: Write once, use anywhere. A clever design concept is a good pay-off.

Yes, its honey-like, also when switching to debugging. Several times I have crashed in debug, when it shows "out-of-ressource" (never see that in 10.3.3 before). My assumption is, that this is caused by the LSP separation, with all its side-effects, but I cannot really reproduce that. Anyway, I hope that Update 1 will fix all this, and make it as stable as 10.3.3 again.

Hi there, I found by accident the Dev-Cpp project on the Embarcadero-Github. Whats the idea behind, is this intended as replacement for the old, free BCC5 compiler, or what ?

Ok thanks, thats what I used at that time. Well I think I installed it one time from binaries, but I never really looked into it. Was always sure this was completely GNU c++ based, with MINGW, and all that stuff. But now its clear, the IDE and tools are separate. Maybe its worth to have a second look at it now.

Never recognized that this was a Delphi project, like you said, it was a populat free GNU IDE. From my point of view this had never anything to do with Delphi/Borland, beside maybe that C++Builder was able to compile it. Anyway, good to have it here.

I may introduce a different option, what I use successfully for years now. Instead of any dialog, I use specialzed messages, for TMessage/TMessageManager, which are pushed to the system. There is only one central place in my apps which handle the dialog requests. Can be a normal MessageBox, can be TFrame-based, can be a special component or 3rd party solution, etc. What and how I do there, is up to my mood or customers requirements. The main advantages: 1. all the dialogs in my apps are looking same 2. changing the UI is just changing an entry in the uses 3. last but not least: unit testing messages works nicely, nothing to get headaches Hope you like this idea as much as I do.

Don't mess with youself too much, if Microsoft shows not any attempt to make these controls practically more usable since the last 20+ years, why should we do ? I must really say that meanwhile I hate to fix all the quirks in OS, IDE, tools, libraries, etc. Enough to do with my own, selfmade errors

I just tried to add ALLOW_BACKGROUND_PERMISSION, which shows ALWAYS as option, as it should. But still I need externally to change the Android options ONCE, only then access is granted. I think I should forget that for a while, I hope my customers will understand that this is an Android issue. Would be great if this is somewhere documented, so that I can proove this behaviour to angry customers. I think 'm getting too old for this shit, the last months I was only catching several issues in various systems. Not that I could really work on my own projects, as I should, but wasting my time finding workarounds for things that should be running. T356_AndBleTest_4Step.zip

Since I suspected that Android needs some more time, I also checked a 3-step process. Where I need 3x press the button 1. location, 2. bluetooth, 3. discover, to avoid too fast calling the API. What I can tell is that it makes no difference. T356_AndBleTest_3Step.zip

@Dave Nottage Curious me has tested the 2-step process too, first ask for LOCATION, and then ask for BLUETOOTH permission. But no luck, still need to change in Android system to ALWAYS, see enclosed project. Seems I have to blame Android for this, or is there any workaround ? I hope that DelphiMT has a good explanation. T356_AndBleTest_2Step.zip

@Dave Nottage Here is a stripped down sample, with its foto story ... Hope you can spot an issue here. When pressing first time, it enables BLE Pressing 2nd time asks for permission, as it should ... Of course I give permission "WHEN IN USE", Then its discovering, but NOTHING found (I can retry as often as I want) Its NOT a permission problem, Android shows while app is running that "WHEN IN USE" is fine If I change this to "ALWAYS" Then the app is still running (no restart), and I can discover now perfectly Can you spot an issue, I'm afraid this could be an Android issue ? I re-order the requests, as @DelphiMT propose, already in this sample. What I didn't checked is to ask for permission in two steps, probably that helps: 1. Ask for Location 2. Ask for Bluetooth Is that they way how it should work (but it was workong fine before) ? T356_AndBleTest.zip

Yes, its saying like that in the specs, but I only get foreground access when additionally the background permission was given. That would explain the need to permit twice, since "WHEN IN USE" seems to be completely ignored, at least in my Samsung S9 Plus. @DelphiMT Thanks, looking forward to your explanatons regarding to this. Probably these Android quirks has something to do with adding the Covid-19 API in a hurry, which requires always background ?

I have made some more tests, with a pure Bluetooth DiscoverDevices search. It seems that Android requires always the ALLOW_BACKGROUND_LOCATION at Android 10 now, although I understand the documentation differently. https://developer.android.com/about/versions/10/privacy/changes The table should say that normal foreground only operation should be possible Now it isn't discovering any longer, I need to have ALLOW_BACKGROUND_LOCATION defined. While it didn't accept the forground immediately, even if background is set. In a minimal sample the manifest looks like this <?xml version="1.0" encoding="utf-8"?> <!-- BEGIN_INCLUDE(manifest) --> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.embarcadero.T355_bleAdvData" android:versionCode="1" android:versionName="1.0.0" android:installLocation="auto"> <uses-sdk android:minSdkVersion="23" android:targetSdkVersion="29" /> <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.BLUETOOTH" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.INTERNET" /> <uses-feature android:glEsVersion="0x00020000" android:required="True"/> <application android:persistent="False" android:restoreAnyVersion="False" android:label="T355_bleAdvData" android:debuggable="True" android:largeHeap="False" android:icon="@drawable/ic_launcher" android:theme="@style/AppTheme" android:hardwareAccelerated="true" android:resizeableActivity="false" android:requestLegacyExternalStorage="true"> <!-- Our activity is a subclass of the built-in NativeActivity framework class. This will take care of integrating with our NDK code. --> <activity android:name="com.embarcadero.firemonkey.FMXNativeActivity" android:label="T355_bleAdvData" android:configChanges="orientation|keyboard|keyboardHidden|screenSize" android:launchMode="singleTask"> <!-- Tell NativeActivity the name of our .so --> <meta-data android:name="android.app.lib_name" android:value="T355_bleAdvData" /> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <receiver android:name="com.embarcadero.rtl.notifications.NotificationAlarm" /> </application> </manifest> <!-- END_INCLUDE(manifest) --> How to set up correctly foreground and background Bluetooth operation now, is this an Android bug, or am I missing something ?

Are looking after FMX ? You can use the Edit custom style, to prepare a customized version Or you can use OnApplyStyleLookup, where you can grab the single elements from above, e.g. by usng FindStyleResource('text') ... When you looking for VCL, probably you have to create you own custom component, or you simply use ' ' space, to get more distance tho the checkbox.

That shows the core differences in the different languages: C++ = pointer love Delphi = pointer hate But why: pointers are always, and will be always out there, till the end of days (at least when it comes to the bare metal).

Yes I was also missing that too, and even would like to customize the keyboard. Seems that this ends up in a lot of fumble jumble. https://medium.com/@ssaurel/learn-to-create-a-system-keyboard-on-android-95aca21b1e5f https://medium.com/@ssaurel/creating-an-in-app-keyboard-for-your-android-apps-a0a6c6e1e289 Not even checked for the iOS side. I hope that Embarcadero will work their fingers to the bone one day

Would choose FreeNullminator, ... hasta la vista .... Object

Depends maybe in what industry you are, as a Kiosk system this is probably OK (but far too expensive from my point of view). In real industrial control systems you are right, its not accepted at all, neither is the RasPi. But at least there were some RasPi more "ruggadized" in the market, which could be used for that. In regards of safety I think none of the above will be really acceptable nowadays, I had done industrial controls in the past also by PC technology, but this won't get through a normal risk-analysis anymore. Especially the larger the machines get you want to control.

@aehimself Right, and regarding consideration for an app like NAS, Smarthome, IoT broker/server or many others. There are so many perfect ARM based, Linux based solutions out there, that Delphi never could catch up IMHO. Take a simple, basic Synology NAS, which comes with all apps from NAS, PHP to Node.js even on the smallest footprint. I'm so sorry to say, but this Tiny PC's are not Delphi's strengths at all, so I would not consider them for anything which is not veeery special. Maybe this can change with the Linux option one day, but surely we will never see such many perfect, rich apps like in the PHP and Node.js world.

I like tiny computers too, but I would check for a NUC-sized to Mini-PC sized PC, with reasonable performance. If I ever need a tiny computer like that, its probably something like a RasPi. All these TinyPC I have seen so far were too expensive and not well supported.

I have seen the "exclude users" warning only from Android, are you sure this is in iOS too ? Would be interesting to see this warning on iOS exactly. With Android you simple confirm: yes, I have to exclude some ancient users (those from ancient Android 4,5,6,..).

@Sherlock Thanks for pointing to this. I noticed first time that the ZeroMQ should be in, but in my GetIt I cannot find this. If ZeroMQ is hidden somewhere, can this be used for C++ only (what I assume) ? Maybe someone has experience with ZeroMQ under Delphi already, and where can I find ZeroMQ in GetIt ? I know the Grijjy implementation, but seems not to be supported for Rx10.4 yet.

I think that Apple is just phasing out 32-Bit, there is no more need to support 32-Bit any longer. All old phone owners should order a new one (Apples view). If you want to update 32-Bit versions for older OS, maybe you can keep one Rx10.3.3 in a virtual machine, as long as this might work, to be able to upload such apps. Never tried, but maybe a pure 32-Bit IPA for older OS can be still uploaded via transporter somehow, but I doubt it. Here could be some insights, howto try this via command line tool. If still possible, you could have two VM, one for 32-Bit Apps, one for 64-Bit Apps. Maybe to support 32-Bit is pointless, as you could find here.