Rollo62

I'm not very sure about ligatures, but I'm afraid they don't have fixed proportions. I wouldn't think that non-fixed fonts are a good choice for code editors.

Hi there, since I notices that I rarely need to touch iOS32 when preparing new iOS apps, while they are still compiles and bundled in the IPA, I wonder what phones will be affected. There is a detailled technical list, I hope that one is correct. It tells that > iPhone 5C, I can consider 64-Bit. I found a german article about such considerations, and another article that is a little contradictary. It tells that iPhone 5C should have modern CPU ( I assume 64-Bit), was produced still until 2017. While the other article tells us that iPhone 5S is from 2013 and iPhone 6/6 Plus is from 2014. Since I would consider >= iPhone 6/6 Plus as still quite modern and with a large user-base, can I be sure that they all run on iOS64 ? How much market impact has the iPhone 5S nowadays, which also means the slightly older OS iOS32 ? Another question is if "modern" CPU also means that they will guarantee to have OS iOS64 alone, or could they still run on iOS32 or both, depending on when they were updated or produced ? Is there the possibility, similar like in Windows, that both OS (32 and 64) might be running under one hardware ? Would be good to clarify from what model the OS iOS64 is definitively installed, for iPhone and iPad. Maybe there are some more official numbers out there, about how many iOS32 / iOS64 systems are in use.

Great, thats what I hoped But where did you find that number 98%, is that anything official ?

Thats what I meant, this plugin is used in NextCloud, while NextCloud prepares all the hard parts of the configuration for you. Since the setup is really easy, it will prepare the SavreDAV automatically. With that you can simple test if that is OK for you, and then later strip down NextCloud to the SabreDAV configuration you need.

Maybe that helps: You can use the structure panel to access the hidden compenents you need. If you really need to see and touch the hidden piece, then you better move from VCL to FMX, there you can set them invisible 🙂

Who said that Delphi couldn't look like C++

TListBox ist not ideal for large datasets, consider TListView instead

What kind of server ? A simple and easy one is inlcuded in NextCloud.

No problems here, but I'm living in a VmWare guest, not real hardware. Of coarse I have 10.3.3 all latest hotfixes installed, never checked X3 or Seatle any longer.

No source code = no go only VCL (I guess) = no go (for me) There is an alternative here

Hi there, I'm using Bluetooth-LE, and I can see that apps might crash in RELEASE under TestFlight, while they work well in DEBUG. This happened never on older iOS versions, so I still try to find the real reason for crashing. What I think is that the bluetooth-le flag not only controls the download from AppStore, but maybe also might cause internal crash's, if not defined. I use bluetooth, with UIBackgroundModes "location", "bluetooth-cetral" and "audio" background modes, which worked well before (and still does in DEBUG), but now shows the typical permission crashes, all on modern phones and iPads with iOS13.4.1. My configuration: Rx10.3.3, XCode 11.4.1, iOS13.4.1. Maybe I need to define bluetooth-le in the UIRequiredDeviceCapabilities, or does that doesn't make any difference in apps behaviour ?

I've managed to remove this strange crash by re-creating the project from another, existing working project. Since I'm very sure that all settings in the project before were OK (I checked all of them them 100 times), I suspect that these project settings maybe be changed or get corrupt in a way that cannot be seen. Unfortunately the .dproj file cannot nicely be checked or compared, to find that out. I lost already a few days by finding that nasty "ghost", by searching the issue in codebase, and I will try to check and find the real reason later, I hope. To reset the settings with some tools I've never really tried productive, I feel more save to recreate them new from a checklist instead, this seems more reliable to me. Since these messy options issue allready happened several times in different ways in the past years, which is always a headache, I hope that options setting, comparing, resetting them could be a little improved in the future versions.

I see, thats what I though too. What I considered in some apps is to the the FMX geocoder, to half the load of requests to the GoogleMaps service. Since this is a free tier, but also has a limit, I'm always afraid to touch this limits and get horrendous bills suddenly I think there is no way to find out how much your free tier is already occupied.

@vfbb Thanks for the nice library. I use the TGeoCoder which is available in FMX, and that works fine for me under iOS (Apple maps) and Android (Google maps). Where would you say is the advantage of your geocoder, to have GMaps on all platforms ?

Yes, I did that, and the link above was a quite good solution helping to set up my own licensing server fastly and cost effective. But since EU GDPR I switched off that licensing server, and decided to open to register freely via other ways. I didn't want to step in that legal trap, but of coarse enhancing the PHP system regarding the GDPR is feasable, but will take a lot more efford around the pure PHP coding. I think this should be also considered when to move to a licensing system, if they support such legal aspects too.

Interesting, and how do you use this hardware ? Is it a kind of data encryption, which is absolutely needed to decode the data from the machine ? In the example of Cadsoft, they finally put some hidden watermarks in the created files, when they detected to be hacked. This is a very effective and nasty solution, as it appears to be functional, but your created files will uncover that you done it illegal. From that time I liked such idea very much.

I doubt even that, see CadSoft trying to protect their Eagle CAD layout software in the early days. They had a dongle, but were hacked all the time. But you're right, if the dongle does some necessary calculation, which is absolutely needed in the app, then this might work.

https://avlock.av-soft.com/products.php I used the older version in a project, where I could control the license by my own PHP server. Not checked the newer versions, and also not checked the safety level. But for my old app that was well working and good enought, to protect from too easy stealing software. If you need very high trusted licensing systems, I'm not sure if there is any, you always should be aware that things can be hacked.

Thanks for that list. Would be great if also the platform tags could be maintained in that list. (VCL, FMX, FPC, Win, Macos, Android, IOS, Linux).

If this is the concern, then why not create your own custom "Lo-Fi" style ? https://www.youtube.com/watch?v=V7g9EDPDPcQ https://www.youtube.com/watch?v=j9XxM7W94p4 Thats what styles are made for, you can be scribbling them as "Lo-Fi" as you want. You can load the whole PNG picture of ta style in Photoshop, and change it to whatever design needed. I think that would be the perfect way. 1. Create the 50% functional demo, use the Lo-Fi style 2. Show your customer 3. Do some refinements of the rest 50% for the next 3-4 months 4. Switch to normal, desired UI style 5. Show to your customer 6. All are happy Is that the way you need ? By the way: You could ask at DelphiStyles for such design, I'm sure they're happy to do that for you.

Ask the inventor .

I've tried some back and forth, but it still keeps same. Crash happens at sampe place in RELEASE, when touching the GetConnectionState. In DEBUG it shows BLE authorization alert, in settings BLE switch is visible, and also it didn't crash at GetConnectionState. In RELEASE it didn't show BLE authorization alert, also not visible switch in the settings, of coarse logically the BLE might crash. The problem seems to be that only in RELEASE the Bluetooth alert didn't appear when touching the CBManager, also no Bluetooth switch in the settings. I have here iOS13.4.1, use Rx10.3.3 w/ all relevant hotfixes, and XCode 11.4.1, and SDK-Manager was updated to the current debug images. It should work with that configuration, all other stuff wors as well. Seems that there have been changes to the authorization system in iOS, since iOS13. I know that there have been changes and deprecated functions in the CBManager and CBManagerAuthorization, but that shouldbe be the reason. The problem seems to be that the BLE alert is not popping up, so what would be the right way to enforce that ? Apple says somewhere that any touch of CBManager would cause that, but I double it. Maybe there is a special operation which should be used to popup BLE alert, I used ConnectionState in the past (working well). The CoreBluetooth is somewhat hacked into the units, there is no separate CoreBluetooth I have found. I haven't used the header conversions from Eli's FmxExpress yet, not sure if they reflect the latest iOS13 changes, but I hope that I don't have to rewrite the whole thing to make it workable under iOS13, its already massivly troubled now. Any ideas ? P.S.: All version info settings are same in debug, release, also info.plist is OK as far as I can tell (checked 100 times).

Ok, I will try, but the real reason where any why it crashes I cannot tell. I found by heavy logging in the sources that it crashes when calling the GetConnectionState method: (I added a lot of Logs around the problem zone). (System.Mac.Bluetooth) In DEBUG, After first start, Location "when using" appears, and the selection is visible in the settings: All OK the app doesn't crash, and when touching GetConnectionState first time, the Bluetooth alert appears. : All OK After first start, the Bluetooth switch is visible in the apps settings: All OK In RELEASE (only via TestFlight, not in debug w/ run), After first start, Location "when using" appears, and the selection is visible in the settings: All OK the app crashes, when touching GetConnectionState first time, no Bluetooth alert appears. : not OK After start and crash, the Bluetooth switch is NOT visible in the apps settings: not OK I use the audio, location, bluetooth-central background modes, (but the problem occurs in Foreground, ) I have set all necessary strings NSLocationAlwaysUsageDescription, NSLocationWhenInUseUsageDescription, NSLocationAlwaysAndWhenInUseUsageDescription NSBluetoothPeripheralUsageDescription , NSBluetoothAlwaysUsageDescription Here are some parts function TMacBluetoothLEManager.GetConnectionState: TBluetoothConnectionState; var LTotal: Single; begin if FAdapter = nil then FAdapter := TMacBluetoothLEAdapter.Create(Self); LMacBluetoothLEAdapter := TMacBluetoothLEAdapter(FAdapter); if LMacBluetoothLEAdapter.FLEManager.FCentralManager.state = CBCentralManagerStatePoweredOn then Result := TBluetoothConnectionState.Connected; else begin LTotal := 0; repeat InternalWaitMessage(0.05); LTotal := LTotal + 0.05; until (LTotal >= 1) or //<====== FATAL CRASH happens here, see Logs below for DEBUG/RELEASE, the request of state seems to crash in RELEASE (LMacBluetoothLEAdapter.FLEManager.FCentralManager.state = CBCentralManagerStatePoweredOn); if LMacBluetoothLEAdapter.FLEManager.FCentralManager.state = CBCentralManagerStatePoweredOn then Result := TBluetoothConnectionState.Connected else Result := TBluetoothConnectionState.Disconnected; end; end; The LOG enhanced code is function TMacBluetoothLEManager.GetConnectionState: TBluetoothConnectionState; var LTotal: Single; LMacBluetoothLEAdapter: TMacBluetoothLEAdapter; LCurrAdp : TMacBluetoothLEAdapter; //S4: 22.04.20 begin if FAdapter = nil then FAdapter := TMacBluetoothLEAdapter.Create(Self); LMacBluetoothLEAdapter := TMacBluetoothLEAdapter(FAdapter); //####### //## //S4: 22.04.20 wait until central manager fully created // PREVENT FATAL CRASH // LTotal := 0; repeat InternalWaitMessage(0.05); // Give a little delay to finish EnableBluetooth LTotal := LTotal + 0.05; // CurrentManager just reads the FManager variable LCurrAdp := LMacBluetoothLEAdapter; if Assigned( LCurrAdp ) then begin // if available, maybe still not ready yet if Assigned( LCurrAdp.FLEManager ) then begin if Assigned( LCurrAdp.FLEManager.FCentralManager ) then begin InternalWaitMessage(0.05); // Give a little more safety delay break; end; end; end; until (LTotal > 1.5 ); //This loop doesn't really cause the crash, as considered first, always leaving directly if LTotal <= 1.5 then begin S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (1a) BLE State OK: ' + Format( '%2.2f', [LTotal]) ); end else begin S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (1b) BLE State FAIL: ' + Format( '%2.2f', [LTotal]) ); end; // //S4: 22.04.20 try wait until central manager fully created //## //####### S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (2a) Check state' ); if LMacBluetoothLEAdapter.FLEManager.FCentralManager.state = CBCentralManagerStatePoweredOn then begin S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (3a) state is connected' ); Result := TBluetoothConnectionState.Connected; end else begin S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (3b) state is NOT connected' ); LTotal := 0; repeat S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (4a) repeat before wait' ); InternalWaitMessage(0.05); S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (4b) repeat after wait' ); LTotal := LTotal + 0.05; //LMacBluetoothLEAdapter.FLEManager. until (LTotal >= 1) or //<====== FATAL CRASH happens here, see Logs below for DEBUG/RELEASE, the request of state seems to crash in RELEASE (LMacBluetoothLEAdapter.FLEManager.FCentralManager.state = CBCentralManagerStatePoweredOn); S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (3c) before result' ); if LMacBluetoothLEAdapter.FLEManager.FCentralManager.state = CBCentralManagerStatePoweredOn then begin Result := TBluetoothConnectionState.Connected; S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (3c) result CONN' ); end else begin Result := TBluetoothConnectionState.Disconnected; S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (3d) result DISCONN' ); end; end; end; Here are the logs for DEBUG: and for RELEASE The strange thing is that is eeems to crash in the timer delay, not really the state request, but I won't rely on the logs in this fatal crah situation. The logs may be cutted in the crash. S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (4a) repeat before wait' ); <===== LOG IS STILL HERE InternalWaitMessage(0.05); S4Log.d( 'TMacBluetoothLEManager.GetConnectionState' + ' (4b) repeat after wait' ); <===== LOG IS NOT HERE (CRASHED) Its very strange, because it was working well for years before, and now crashes, but only in RELEASE, DEBUG works fine. What wonders me is that even in DEBUG the state doesn't return as CONNECTED, but as disconnected. I'm pretty sure I'm missing a minor piece in the puzzle, but I cannot spot it.

Hi there, I wanted to call the Bluetooth initWithDictionary and its option CBCentralManagerOptionShowPowerAlertKey; There is little information out there howto create the options for this call in the right way. CBCentralManager = interface(NSObject) ['{587D1855-5B53-43DA-91AF-AF9D93FFDB9F}'] ... function initWithDelegate(delegate: id; queue: dispatch_queue_t; options: NSDictionary): id; cdecl; overload; In XCode that looks quite straightforward, but what about Fmx ? let opts = [CBCentralManagerOptionShowPowerAlertKey: false] let manager = CBCentralManager(delegate: self, queue: nil, options: opts) Info's like this doesn't help much http://codeverge.com/embarcadero.delphi.firemonkey/help-rewrite-objective-c-proced/1046099 Using NSUserDefaults to access the info list properties seems not to work, returning nil. But is NSUserDefaults the right place to look for those keys ? var LDefaults: NSUserDefaults; LDict: NSDictionary; begin LDefaults := TNSUserDefaults.Wrap(TNSUserDefaults.OCClass.standardUserDefaults); LDict := LDefaults.dictionaryForKey( CBCentralManagerOptionShowPowerAlertKey ); // ! This (LDict) is nil if Assigned(lDict) then FCentralManager := TCBCentralManager.Wrap( TCBCentralManager.Alloc.initWithDelegate( GetObjectID, 0, LDict )) I used this function to get the key constant function CBCentralManagerOptionShowPowerAlertKey : NSString; begin Result := CocoaNSStringConst(libCoreBluetooth, 'CBCentralManagerOptionShowPowerAlertKey'); end; Other ways to construct this NSDictionary look to ugly to be true: LDict := TNSDictionary.Wrap( TNSDictionary.OCClass.dictionaryWithObjectsAndKeys( <<This is Pointer to object a nil-terminated list>>)); Maybe somebody can help with some useful hints, to find the right way to access such system options ?

Yes it works with that configuration, the LDict is assigned, and even better, the Bluetooth alert appears. Thanks again Dave.