Rollo62

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.

@Dave Nottage Thanks, I will check that. Never know when to use what and why excactly when it comes to iOS objects

When it comes to IDE experts, I'm a little careful, as I prefer the manual way to not rely on some experts or IDE "magic" too much. After separating the number of components is reduced into a few frames to handle, and they easily can be handled manually. Of coarse I prepare my views manually at runtime too, putting them into the right container, not in the IDE designer, which might cause all sorts of issues. That way the RAD in RadStudio becomes very handy for the frame/form design, but for the rest I try to rely on coding over drag-n-drop. For me this is the best of both worlds.

Probably that doesn't help you much right now, but I usually decompose more complex views into smaller modules, already before putting all components on one form. To have a few separate views, which show specific aspects of a whole view, like media.play.controller; media.play.playlist, media.play.viewer, all were placed into separate, selfcontaining frames or forms. In my final views I can simple compose them, and connect them via interface bindings and/or messages. Thats way makes it easier to test, compose, re-use and re-place separate parts of a projects view. All it needs is a little more discipline before clicking such complex views or datamodules together, and a little more efford, but I'm not ready either to do this always right, especially when I needed a "fast" solution again

@Dalija Prasnikar Yes, I think compiler/linker could get a little smarter though, maybe in the direction like FixInsight or PascalAnalyser can do. To find common anti-patterns, and give warnings, that should be not so far out of reach. But you're right, maybe this is a task for some separate tool probably.

Maybe something is possible with FireUI, never checked that out more deeply. I usually make screenshots of each situation I need, e.g. on iOS phone, and then have a lot of files I can show.

Yes, Rx10.4 will move in the opposite direction then. Maybe someone else has some practical thoughts too, how to get most of it. I personally can live with the interface as is well, but of coarse the pitfalls are deep. How about a better error-detection by the compiler/linker, would that be thinkable ? Couldn't be all the do's and dont's in the compiler logic (as switchable error option of coarse, for those who need it as is) ? Probably that not possible either, but maybe the most common, drastic mistakes/misuses could be turned into some clear compile time errors (warnings).