Rollo62

Looks very nice and relaxing. Have you heard about the Skia contest ? It should be still ongoing, not sure if they take games as "UI" too.

All that can happen, but its also true that the whole pip, npm, composer, chocolatey universes and also the applications and websites build on that rely on such same repositories. These should be billions I would guess. This would break as well for many other applications, no matter if bundled or not, or if hosted on AWS. I was never aware of any bigger problems with that repos, of course security issues always appear here and there on a daily bases, but in general well maintained packages, reviewed by many people, should have relative low risk. That said also Workpress, Joomla, whatever face the same risks, even every Website, not only a very specific desktop application. I would assume if someone compromizes for example ImageMagick, then the whole web will be down, not caring much about such small desktop app. The last case I can think of was OpenSSL or log4j, which had that ability to put the web down, it can basically catch anyone anytime always. We're all using some external stuff here and there, even Delphi itself was compromized before, so I would not think that risk with repos would not be manageable. But thanks to remind me on that risk question, so it might be a good idea to integrate some additional "security" features inside, for example to be able to cut off the apps fastly from a central server by a blacklist server maybe, if some problems with packages are known.

Maybe the difference I'm looking for is the ability also to integrate non-python packages, like this example, this is why I'm looking after Anaconda vs. Chocolatey for example. Yes, its a test balloon and new consideration for me too, to find out that whole thing makes sense. I'm not thinking of a huge application, but about a small app that can do a few little things very good, like a swiss knife. There are so many very good, well maintained open libraries out there, why not make use of them and even push their publication a little ? I know quite a few free or not-free "utility" products that rely on other open-source packages, only for making them more user-friendly. To download from 3rd Party I see not as problen at all, best example is Delphi itself: - Installer downloads Ms Dot-Net installer - Delphi uses Android SDK packages ( I have to confirm license sepatately ) and so on. I think this is nothing new or "smelly" with that approach, at least from my point of view. We only have to take care about the license questions, maybe switch from open to licensed packages in some cases. For that reasons I'm looking after platforms that supports most packages in a most convenient way.

I'm not sure how Win10 Notification behaves, but what happens if you try to decouple this from the incomin ComPort thread ? procedure TForm62.comportclient1Receive(Sender: TObject; InQue: Integer); begin SendMessage(handle, pm_ProcessBarcodeScan, WPARAM(0), LPARAM(0)); //<= Better avoid any ProcessMessages application.processmessages; end; procedure TForm62.ProcessBarcodeScan(var Message: TMessage); begin inherited; SendWin10Notification('Hello World', 'Sent by Message'); end; procedure TForm62.SendWin10Notification(aTitle, aAlertBody: string); begin TThread.ForceQueue( //<= This ensure the call inside main thread, and should avoid to use a Timer IMHO nil, procedure var lNotification : TNotification; begin lNotification := NotificationCenter.CreateNotification; // Processed in Main UI thread here lNotification.Name := format('Windows10Notification%d', [GetTickcount]); lNotification.Title := aTitle; lNotification.AlertBody := aAlertBody; lotificationCenter1.PresentNotification( lNotification ) //insendmessage <== This doesn't help, if you call this several times. // Where is FNotification be created, probably only once at start ? // I think you could have to create a local FNotification here, if you don't have the need to touch this variable again. end ); end; //<= This is probably not necessary at all procedure TForm62.Timer1Timer(Sender: TObject);

Yes, but it seems not all Packages are available in the standard distribution or the connected PyPi repository. Thats why I looked into Anaconda repository, which seems to be well maintained. If I distribute Python together in an compiled setup, then I would like to have a minimal installation and all required packages were loaded after install from the main exe. A GUI protects the user from any interfearance with the Python backend. If you meant that the "normal" Python distribution is free to add in commercials too, and is able to bootstrap itself from PyPi or Anaconda, then this might be a good alternative too. As far as I have seen, the Python license would allow that, I think you're right. Some Python-nauts recommend to use Miniconda for that bootstrap purpose, which would also be by favorite so far. Thats why I ask what the best setup for this task would be, I'm a 5% Python newbie so far 🙂 Only have used a few scripts for testing. Not quite, I want to prepare pre-build apps with e.g. InnoSetup, similar as usual, convenient Windows Apps, where the simple user shall be totally shielded against any underlying command-line operations or other "difficult" tasks, like re-loading extra packages, etc. Everything should be packed in a nice GUI, with a few buttons to operate, while that hard work is done by some special Python packages underneath. The GUI should only prepare all packages accordingly and run the prepared scripts.

As said, its not FMX related, but gives you a lot of info about memory usage, performance, power consumprtion, hardware, network status etc. It has several tools that can be configured in a custom way. Instruments is a kind of separate tool in XCode, so not much problems to use it, it can connect to running or start new processes.

Profiling is a bit tricky, I think there is no real integrated version for FMX yet. But you could try to use the Macos XCode Instrument tools, they show a lot of details for any running apps, but I havent used them any more in the last few years. I think it should be more powerful and useful even. https://gist.github.com/loderunner/36724cc9ee8db66db305

I'm not sure what exactly you are looking for, especially for FMX. A Macos "performance monitor", like a rudimentary "Windows Task-Manager", is called ACtivity Monitor under Macos. This has nothing special for FMX of course.

Ok, here is something to play around with natural spline interpolation vs. other kinds. https://tools.timodenk.com/cubic-spline-interpolation Maybe that has enough gamification factor to fulfil the high expectations here.

So you need to fit all datapoints, but want to avoid large overshootings, then this paper is maybe also interesting for you. https://towardsdatascience.com/numerical-interpolation-natural-cubic-spline-52c1157b98ac

Android: There are quite old infos from Brian Long, maybe too much has changed meanwhile. http://www.blong.com/articles/delphixe7nfc/nfc.htm Android iOS: Maybe WinSoft ? https://winsoft.sk/infclib.htm https://blogs.embarcadero.com/powerful-core-nfc-api-library-for-delphi-firemonkey-on-ios-by-winsoft/ And maybe you find something in Dave's great Kastri Library too https://github.com/DelphiWorlds/Kastri/blob/master/Demos/NFC/MainFrm.pas

Sorry, its probably too late. I had read it as: ... I dont have any issues IOS - Developer/Deployment certificate with Provisioning profile.

Done. But the personal questions had gone way beyond of good taste, IMHO.

For iOS distribution you MUST have a developer account, a provision certificate, etc. etc. etc., the whole Apple "Security by bureaucracy" flash ... https://docwiki.embarcadero.com/RADStudio/Sydney/en/IOS_Mobile_Application_Development I'm afraid there is no way around it.

Haven't checked the sources: I would assume that the SubscribeToMessage() is called twice, with using the same event handler. That should not be allowed, from the EListError error above. So you could try to move this line to a position where it is only called once per lifetime of the app, during initialization ( in TScreenOrientationMonitor.Create for example, if that exists in the source ).

Maybe adding 'android.permission.BLUETOOTH_ADMIN'; makes any difference for you. Not sure how Pairing and Bonding differ in detail, and can be used under Delphi. Do you have any simple example code of what you want to achieve in Java (Android) / Objective-C (iOS) ? Maybe its possible to add and implement that in Delphi too In the code above you don't do anything "bonding special", I would say. https://medium.com/@martijn.van.welie/making-android-ble-work-part-4-72a0b85cb442 https://www.kynetics.com/docs/2018/BLE_Pairing_and_bonding/

Hi there, I'm playing around with the platform behaviours, and I found some strange behaviour when adding them to both 32-Bit and 64.Bit. (1) 32-Bit node: While it is possible to add the library to 32-Bit, ... <== dw-kastri-base-2.0.0.jar was added (2) 64-Bit node: it seems impossible to add the same library to the 64-Bit node: ... <== dw-kastri-base-2.0.0.jar cannot be added Although it seems pretty much possible to add different libraries under the same name ( see work-runtime-2.1.0.dex.jar or others of the default libraries ). In case (2) under 64-Bit I don't get any error or message or something, it simply didn't appear in the list above. It seems to work when I add under 32-Bit only, also under 64-Bit (at least I don't see any errors here), but it doesn't work when I add it under 64-Bit node only. Then it seems not be available in the 32-Bit node. It seems to compile, run and work anyhow, see enclosed demo, but I'm unsure if this by lucky accident ony. Maybe you have some idea what could be going wrong here ?. T457_TestAndLib_001.zip Running under Delphi D11.1 Patch 1

Yes, sorry for that. I am currently chasing some strange behaviours I see on some older Android systems maybe connected with Android-32 CPU. Thats why I just try to look into all possible corners to find a reason, but I have no clear reproducable error right now.

For what platform ? From my setup here: Under Android64, debugging is broken in more complex projects, already since >= 10.4 or so, simply starts veeery slow, shows blackscreen and stops. Under Android32, debugging is still fine and fluid. But I haven't seen such D33566 yet. My recommendationm for any Internal error is, to completely clean all compiled, temporary stuff, and build the project new. That resolved the internal errors in 99.9% in my cases, which leads to my opinion that internal errors are causes mostly by mainy failing processes, leaving DCU or other files in a ghost state.

@Dave Nottage Thanks, that's interesting. Unfortunately it doesn't give me a clue howto workaround these issues really in a reliable way ( currently I'm not dealing with service, but wanted to know howto handle the .jar in the right way ). I considered a "brute-force" copy and paste the same library into the 32/64 Bit structures, but I had to realize that this is only one structure under a general entry "<ItemGroup>", which has no platform specific versions. <ItemGroup> <DelphiCompile Include="$(MainSource)"> <MainSource>MainSource</MainSource> </DelphiCompile> <DCCReference Include="Unit1.pas"> <Form>Form1</Form> <FormType>fmx</FormType> </DCCReference> <JavaReference Include="..\..\..\Kastri\Src\Lib\dw-kastri-base-2.0.0.jar"> <Disabled/> </JavaReference> <BuildConfiguration Include="Base"> <Key>Base</Key> </BuildConfiguration> <BuildConfiguration Include="Debug"> <Key>Cfg_1</Key> <CfgParent>Base</CfgParent> </BuildConfiguration> <BuildConfiguration Include="Release"> <Key>Cfg_2</Key> <CfgParent>Base</CfgParent> </BuildConfiguration> </ItemGroup> That would explain why there is a "There can only be one" behaviour for the .jars. I slightly assume it doen't really matter if the library is in the 32- or 64-Bit tree, as long as it is there it will be taken for both. Howto ensure that it is taken for both, is there a secret Delphi switch ? Strange is that there were are separate library trees for the standard libraries, for 32- and 64-Bits, just as it should be: <PropertyGroup Condition="'$(Base_Android)'!=''"> //<== 32-Bit <DCC_UsePackage>fmx;DbxCommonDriver;bindengine;IndyIPCommon;emsclient;FireDACCommonDriver;IndyProtocols;Skia.Package.RTL;IndyIPClient;dbxcds;FmxTeeUI;bindcompfmx;ibmonitor;FireDACSqliteDriver;DbxClientDriver;soapmidas;fmxFireDAC;dbexpress;inet;DataSnapCommon;dbrtl;FireDACDBXDriver;Skia.Package.FMX;CustomIPTransport;DBXInterBaseDriver;IndySystem;ibxbindings;bindcomp;FireDACCommon;IndyCore;RESTBackendComponents;bindcompdbx;rtl;RESTComponents;DBXSqliteDriver;IndyIPServer;dsnapxml;DataSnapClient;DataSnapProviderClient;DataSnapFireDAC;emsclientfiredac;FireDAC;FireDACDSDriver;xmlrtl;tethering;ibxpress;dsnap;CloudService;FMXTee;DataSnapNativeClient;soaprtl;soapserver;FireDACIBDriver;$(DCC_UsePackage)</DCC_UsePackage> <VerInfo_Keys>package=com.embarcadero.$(MSBuildProjectName);label=$(MSBuildProjectName);versionCode=1;versionName=1.0.0;persistent=False;restoreAnyVersion=False;installLocation=auto;largeHeap=False;theme=TitleBar;hardwareAccelerated=true;apiKey=</VerInfo_Keys> <BT_BuildType>Debug</BT_BuildType> <VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo> <Android_LauncherIcon36>$(BDS)\bin\Artwork\Android\FM_LauncherIcon_36x36.png</Android_LauncherIcon36> ... <Android_NotificationIcon96>$(BDS)\bin\Artwork\Android\FM_NotificationIcon_96x96.png</Android_NotificationIcon96> //<== 32-Bit Jars <EnabledSysJars>annotation-1.2.0.dex.jar;asynclayoutinflater-1.0.0.dex.jar;billing-4.0.0.dex.jar;browser-1.0.0.dex.jar;cloud-messaging.dex.jar;collection-1.0.0.dex.jar;coordinatorlayout-1.0.0.dex.jar;core-1.5.0-rc02.dex.jar;core-common-2.0.1.dex.jar;core-runtime-2.0.1.dex.jar;cursoradapter-1.0.0.dex.jar;customview-1.0.0.dex.jar;documentfile-1.0.0.dex.jar;drawerlayout-1.0.0.dex.jar;firebase-annotations-16.0.0.dex.jar;firebase-common-20.0.0.dex.jar;firebase-components-17.0.0.dex.jar;firebase-datatransport-18.0.0.dex.jar;firebase-encoders-17.0.0.dex.jar;firebase-encoders-json-18.0.0.dex.jar;firebase-iid-interop-17.1.0.dex.jar;firebase-installations-17.0.0.dex.jar;firebase-installations-interop-17.0.0.dex.jar;firebase-measurement-connector-19.0.0.dex.jar;firebase-messaging-22.0.0.dex.jar;fmx.dex.jar;fragment-1.0.0.dex.jar;google-play-licensing.dex.jar;interpolator-1.0.0.dex.jar;javax.inject-1.dex.jar;legacy-support-core-ui-1.0.0.dex.jar;legacy-support-core-utils-1.0.0.dex.jar;lifecycle-common-2.0.0.dex.jar;lifecycle-livedata-2.0.0.dex.jar;lifecycle-livedata-core-2.0.0.dex.jar;lifecycle-runtime-2.0.0.dex.jar;lifecycle-service-2.0.0.dex.jar;lifecycle-viewmodel-2.0.0.dex.jar;listenablefuture-1.0.dex.jar;loader-1.0.0.dex.jar;localbroadcastmanager-1.0.0.dex.jar;play-services-ads-20.1.0.dex.jar;play-services-ads-base-20.1.0.dex.jar;play-services-ads-identifier-17.0.0.dex.jar;play-services-ads-lite-20.1.0.dex.jar;play-services-base-17.5.0.dex.jar;play-services-basement-17.6.0.dex.jar;play-services-cloud-messaging-16.0.0.dex.jar;play-services-drive-17.0.0.dex.jar;play-services-games-21.0.0.dex.jar;play-services-location-18.0.0.dex.jar;play-services-maps-17.0.1.dex.jar;play-services-measurement-base-18.0.0.dex.jar;play-services-measurement-sdk-api-18.0.0.dex.jar;play-services-places-placereport-17.0.0.dex.jar;play-services-stats-17.0.0.dex.jar;play-services-tasks-17.2.0.dex.jar;print-1.0.0.dex.jar;room-common-2.1.0.dex.jar;room-runtime-2.1.0.dex.jar;slidingpanelayout-1.0.0.dex.jar;sqlite-2.0.1.dex.jar;sqlite-framework-2.0.1.dex.jar;swiperefreshlayout-1.0.0.dex.jar;transport-api-3.0.0.dex.jar;transport-backend-cct-3.0.0.dex.jar;transport-runtime-3.0.0.dex.jar;user-messaging-platform-1.0.0.dex.jar;versionedparcelable-1.1.1.dex.jar;viewpager-1.0.0.dex.jar;work-runtime-2.1.0.dex.jar</EnabledSysJars> </PropertyGroup> <PropertyGroup Condition="'$(Base_Android64)'!=''"> //<== 64-Bit <DCC_UsePackage>fmx;DbxCommonDriver;bindengine;IndyIPCommon;emsclient;FireDACCommonDriver;IndyProtocols;Skia.Package.RTL;IndyIPClient;dbxcds;PkS4_Core_Rx1111;FmxTeeUI;bindcompfmx;hclcore_xe11;ibmonitor;FireDACSqliteDriver;DbxClientDriver;soapmidas;fmxFireDAC;dbexpress;inet;DataSnapCommon;htmleditcore_xe11;htmledit_xe11;dbrtl;FireDACDBXDriver;htmlcomp_xe11;Skia.Package.FMX;CustomIPTransport;DBXInterBaseDriver;IndySystem;ibxbindings;bindcomp;FireDACCommon;IndyCore;RESTBackendComponents;bindcompdbx;rtl;RESTComponents;DBXSqliteDriver;IndyIPServer;dsnapxml;DataSnapClient;DataSnapProviderClient;DataSnapFireDAC;emsclientfiredac;FireDAC;FireDACDSDriver;xmlrtl;tethering;ibxpress;dsnap;CloudService;FMXTee;DataSnapNativeClient;soaprtl;soapserver;FireDACIBDriver;$(DCC_UsePackage)</DCC_UsePackage> <VerInfo_Keys>package=com.embarcadero.$(MSBuildProjectName);label=$(MSBuildProjectName);versionCode=1;versionName=1.0.0;persistent=False;restoreAnyVersion=False;installLocation=auto;largeHeap=False;theme=TitleBar;hardwareAccelerated=true;apiKey=</VerInfo_Keys> <BT_BuildType>Debug</BT_BuildType> <VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo> <Android_LauncherIcon36>$(BDS)\bin\Artwork\Android\FM_LauncherIcon_36x36.png</Android_LauncherIcon36> ... <Android_NotificationIcon96>$(BDS)\bin\Artwork\Android\FM_NotificationIcon_96x96.png</Android_NotificationIcon96> //<== 64-Bit Jars <EnabledSysJars>annotation-1.2.0.dex.jar;asynclayoutinflater-1.0.0.dex.jar;billing-4.0.0.dex.jar;browser-1.0.0.dex.jar;cloud-messaging.dex.jar;collection-1.0.0.dex.jar;coordinatorlayout-1.0.0.dex.jar;core-1.5.0-rc02.dex.jar;core-common-2.0.1.dex.jar;core-runtime-2.0.1.dex.jar;cursoradapter-1.0.0.dex.jar;customview-1.0.0.dex.jar;documentfile-1.0.0.dex.jar;drawerlayout-1.0.0.dex.jar;firebase-annotations-16.0.0.dex.jar;firebase-common-20.0.0.dex.jar;firebase-components-17.0.0.dex.jar;firebase-datatransport-18.0.0.dex.jar;firebase-encoders-17.0.0.dex.jar;firebase-encoders-json-18.0.0.dex.jar;firebase-iid-interop-17.1.0.dex.jar;firebase-installations-17.0.0.dex.jar;firebase-installations-interop-17.0.0.dex.jar;firebase-measurement-connector-19.0.0.dex.jar;firebase-messaging-22.0.0.dex.jar;fmx.dex.jar;fragment-1.0.0.dex.jar;google-play-licensing.dex.jar;interpolator-1.0.0.dex.jar;javax.inject-1.dex.jar;legacy-support-core-ui-1.0.0.dex.jar;legacy-support-core-utils-1.0.0.dex.jar;lifecycle-common-2.0.0.dex.jar;lifecycle-livedata-2.0.0.dex.jar;lifecycle-livedata-core-2.0.0.dex.jar;lifecycle-runtime-2.0.0.dex.jar;lifecycle-service-2.0.0.dex.jar;lifecycle-viewmodel-2.0.0.dex.jar;listenablefuture-1.0.dex.jar;loader-1.0.0.dex.jar;localbroadcastmanager-1.0.0.dex.jar;play-services-ads-20.1.0.dex.jar;play-services-ads-base-20.1.0.dex.jar;play-services-ads-identifier-17.0.0.dex.jar;play-services-ads-lite-20.1.0.dex.jar;play-services-base-17.5.0.dex.jar;play-services-basement-17.6.0.dex.jar;play-services-cloud-messaging-16.0.0.dex.jar;play-services-drive-17.0.0.dex.jar;play-services-games-21.0.0.dex.jar;play-services-location-18.0.0.dex.jar;play-services-maps-17.0.1.dex.jar;play-services-measurement-base-18.0.0.dex.jar;play-services-measurement-sdk-api-18.0.0.dex.jar;play-services-places-placereport-17.0.0.dex.jar;play-services-stats-17.0.0.dex.jar;play-services-tasks-17.2.0.dex.jar;print-1.0.0.dex.jar;room-common-2.1.0.dex.jar;room-runtime-2.1.0.dex.jar;slidingpanelayout-1.0.0.dex.jar;sqlite-2.0.1.dex.jar;sqlite-framework-2.0.1.dex.jar;swiperefreshlayout-1.0.0.dex.jar;transport-api-3.0.0.dex.jar;transport-backend-cct-3.0.0.dex.jar;transport-runtime-3.0.0.dex.jar;user-messaging-platform-1.0.0.dex.jar;versionedparcelable-1.1.1.dex.jar;viewpager-1.0.0.dex.jar;work-runtime-2.1.0.dex.jar</EnabledSysJars> </PropertyGroup> Just looking at the "annotation-1.2.0.dex.jar" entry, there were two places where it is included. While for the external libraries, see above, Delphi allows only one place for all architectures, strange. Still I'm unsure if this one will be enough for compilation of Android-32 and -64, how could I check if a library is binded into the package ? I can find the reference, I assume, inside the classes.dex, but not sure if it always gets there . Will there be any useful error message, if the reference would be missing, either in 32- or 64-Bit or both ? This error hopefully pops by linker failures. When I would ever need to handle separate 32- and 64-Bit Jars, I'm afraid there is no option in Delphi to do that right now, maybe by adding a wrapper JAR only, handling that externally.

@Minh Hoang The error 96/05/2022 10:20:30 is clearly not a valid date. But this format also might lead to the consideration if you are using the appropriate TFormatSettings for the conversion itself. Since "/ :" separators are used in US mainly, other countries might use different formats, for example in Germany the usual format is "dd.mm.yyyy hh:nn:ss". I think in asian countries you also might have the ". :" separators , which may lead to similar errors when not taking care about them. Suddenly a program running well in your country might crash in another country.

Why not upload via PAServer ? Have you tried to delete all apps with same name, or BundleId before ? It seems that you have an existing app, maybe due to Apple Configurator, thats why it cannot be re-loaded by PAServer ( a rough guess ).

Good point, but IMHO Skia is just in the early phase of rocketing launch into many projects. I would assume this may stay quite some time very active, the more people get aware of this nice library. Edit: References References References

Yes, thats true, but also my biggest concern. Google is lightyears ahead, and Embarcadero needs to follow Google, Apple, Microsoft, and whatsnot. This is clearly an unfair game 🙂 Thanks, I was not aware of that fact. That make is much more easy to just move to Skia, without too much rewrite of existing code. This makes is more easy to join and to use and improve it, you should make this fact more clear since this could ease the decisions. If it only would concern sourcecode, I would be relaxed, but since Skia also involved external libraries as a binary base, there is a lot more risk of using it. Easily it might break iOS, Macos, Android and even Windows, when running out of sync in new IDE, XCode, SDK versions or OS versions. Again, very good to know about the simple Skia on/off switch behaviour, so that I still can check FMX and Skia behaviour in parallel. You could not advertise this fact big enough

Thanks for the insights, this is what I expected too. There was a TScene "demo" from Eugene which pointed maybe in the same direction, this library I checked out some years ago, but never implemented into my current apps yet because the advantage was not so big for me. Maybe that could be more relevant with Skia now, or is this already obsolete technology ? If Skia is able to perform so well and stable, I will give it a try soon, probably beyond just testing. My biggest concern is if such system is resilient and production stable now, or rather might break in the next OS or IDE updates. I see you'r updating very eager, and it seems well supported, so thats a very good sign. FMX is not really stable for me, and tend to behave different in every version. If Skia is an approach to make FMX more stable, I'm jumping on that train very likely, but if Skia is adding another dimension of new failure modes, I will probably will make more tests.