Rollo62

What about 'Routing ?

@Serge_Gthanks anyway, so I don't have to look into it too. Yes, that saves a lot of redundant work .... Sorry that you will be grabbed now by Emb-Police, farewell.

Yes, in Macos/iOS/Android I use both events, the OnDeviceLE to show an early response, and the EndDiscovery to proceed further. So an additional timer would mimick the Android/iOS behavior well. Still I don't use BLE on Windows, which is another construction site, but its on my roadmap.

How do you detect end-of-discovery, do you run a timer in parallel ?

You got my point.

Of course its not relevant, but nice to have, and good to see what a little "modernizing" can do. Also good to have a Delphi-based IDE, from where its maybe possible to start some support for special embedded hardware one day. Yes, we can use VisualStudioCode for all that too, but should we ?

@Roger Cigol I think Dev-C++ was originally intended as learning IDE platform, and probably only to make some small test projects. Maybe its better to compare Dev-C++ to RadStudio like VS Code is comparing to VisualStudio.

For issues like that I have a Clean_EXE.cmd batch file, removing all created files and folders externally. An internal clean is not good enough in most cases. I usually run clean and build all before any important change or release. In case of issues I step through the different shades of clean step-by-step, as not always a brutal full clean is needed. But I didn't need to re-install the target platform yet, anyhow maybe the days will come Good to know there is another shade of clean in the portfolio.

M1: Maybe you need at least 3 characters minimum

Adress data can be much chaotic data in general, including typo's, exchanged fields, etc. Thats why a hash value is maybe problematic too, if you want to work with the data. Have you considered to reverse GeoCode the data in a single batch run, and add lon/lat to your database ? Maybe that could make more sense for you, but could allow several "same" addresses of coarse.

Hi there, I have found this interesting post from Developpeur-pascal.fr, about howto check the M1 processor from an Macos app. (here the original link). Since I have no Apple M1 device in hand, I'm very curious about how it runs, or what needs to be prepared or avoided to do so. I assume that only normal, compiled apps may be working, by the Rosetta2 emulator, but not the PAServer debugger itself. ( or can PAServer be emulated and debugging too, and M1 could operate quite normally ? I would bet 10 bucks against that ). Would be great if you would share the pitfalls we can find there.

Ok, my fault, maybe a copy-paste-error here in DP: I had clearly seen the .a ending when I answered (thats why I copy-and-blue-red it, to make it more visible). So I thought this was maybe wrongly interpreted as fibrary file. I still think "lib\.... " should be the right place.

library\lib\arm64-v8a lib\arm64-v8a a So what you think the issue is, the missing library, or the added .a ? I think the library\lib should be right to be pointing to lib only, or do you expect the folder library ? The added .a should be not OK, maybe there is just a "\" or "/" missing or too many in the options setting, be aware that also the options settings exist for ALL, DEBUG, RELEASE, x32/x64, which could differ. I've added a kind of debug mode in my apps, where I can list and check all the available the local filles and folders, maybe that helps to get clear when comparing where are the differences after installation on the different phones. Does the libraries have same name for x32 and x64 ? Maybe that causes the bundle or the OS to ignore it ? But it should work with same name under different folder, I would assume too.

Do you have a simple test app, to be able to verify that it doesn't deploy ? Did you add the deployment manually in the deploymment manager (I remember there is also an automatic addition somewhere for default libraries, but SSL shouldn't be in there) ?

The RestDebugger should be in source code, under \Embarcadero\Studio\20.0\source\data\rest\restdebugger\ Maybe you can spot a difference between Rio and Sydney sources, but I doublt that there were any changes ? Have no Rio on hand, so I cant check. But also possible that the underlying REST components have changed.

Have you copied the missing files from Rio to Sydney, or did you add them manually ? What is the difference, did you made a diff of the files ? When using RestDebugger, you can also paste to pure TEXT editor, which should give all the components in textual format, would be interesting to see the difference in export from Rio and Sydney as Textfile.

Great, I will check that

I like the mustache notation {{}} a lot, is it possible to make this compatible (at least a bit), to Mustache ? (Naive approach: Maybe its just replacimg "<%" "%>" by "{{" "}}" ) ?

Hi there, the PlayStore take now more than 7 days in the status "wird überprüft (in review)". Google has changed recently their complete PlayStore to a newer version, and is also asking for additional permissions/explanations, in my case why to use location in background mode. Then you have to answer a few questions, and provide a link with a video that, which explains why to use that permission. The PlayConsole already notes that review might take longer these days, but from Google I never had too much hazzle in the reveiw process. Thats why I'm not sure if >7 days is usual now, or if I should carefully ask the support whats going on ? How is your experience, is this the "new normal" now ?

Yes, thats the usual time: 00:30 to 1:00, not much more. It was the first time I've got 8 days, never that much even in a manual review. I assume its a 2-level process 1. automated review: 30-60 min. and, if there is any issue 2. manual review (this can take longer these days, as noted on the Android page)

I would put one step of decoupling between the event and the processing, since the data maybe fired from external system, and I never trust that the thread or timing is correctly decoupled under all circumstances (maybe you call that paranoic ). I usually do like this: procedure TForm1.LocationSensor1LocationChanged(Sender: TObject; const AOldLocation, ANewLocation: TLocationCoord2D); var LDecSeparator: String; LNewLocation : TLocationCoord2D; begin LNewLocation := ANewLocation; TThread.ForceQueue( //<== Ensure that the UI is touched only from UI thread nil, procedure begin LDecSeparator := FormatSettings.DecimalSeparator; FormatSettings.DecimalSeparator := '.'; // Show current location ListBoxItemLatitude.ItemData.Detail := Format('%2.6f', [ LNewLocation.Latitude ]); ListBoxItemLongitude.ItemData.Detail := Format('%2.6f', [ LNewLocation.Longitude ]); end ); end;

30 what, days I've got 8 days now, never took so long before. And this time they want even changes

I like to speak a word for System.Messaging, which I extended to some kind of thread safety too. This seems a good base for me, and works very stable in main UI and threads also, if you took the right measures to secure it. To use System.Messaging as a base makes sense to me, because its a System unit and also the FMX messaging system is build on top of this, thats why I assume is has to be well tested and maintained. Nonetheless I like to see new libraries, which can do it much better too.

To add another solution, I have used this here., from Zacherl in the German DP, and separated this into separate 32- and 64-Bit units, and reworked a little. So far I have not yet worked with 64-Bit, so I cannot say its working there, or not. But I remember I put this into some unit tests, and was OK, I'm not sure ....

The links are already some years old, while background and permissions is a moving target on mobile. Maybe you should check out the latest Kastri repo, from Dave Nottage, which is IMHO most up-to-date.