Rollo62

TLDR; I think you mixed too many stuff in one method. I would separate this into different domains, each in a unit, e.g. like UMailSend.pas, USysInfo.pas, and the caller I usually encapsule separate functions into classes, with static functions/methods. This behaves same like functions or methods, but keep them under a "namespace" of the class, which could be extended if needed. type TMail = class class function Send( AReceiver, AMessage : String, ...); static; end;

Thats where you should set it, under "All" Android should be the best place, when Debug/Release is not yet set. Be aware that there could be several wrong, old settings under Debug 32/64 and Release 32/64. Maybe you could check with a fresh, new project, just to ensure the that the keysore works well.

There were two passwords, for the keystore and the Alias. Are you sure both of them were correct ?

How about this Project?

There are other, simpler methods to copy a bitmap, but maybe this example is worth noting it, (or here) line-by-line using ScanLine. var srce, dest: TBitmapSurface; path: string; scan: integer; w, h1, h2: integer; begin path := 'C:\tmp\Imgs\res.bmp'; srce := TBitmapSurface.Create; try TBitmapCodecManager.LoadFromFile(path, srce); dest := TBitmapSurface.Create; try // first half w := srce.Width; h1 := srce.Height div 2; dest.SetSize(w, h1, TPixelFormat.RGBA); for scan := 0 to h1-1 do Move(srce.Scanline[scan]^, TBitmapSurface(dest).Scanline[scan]^, srce.Width * 4); Image1.Bitmap.Assign(dest); // second half h2 := srce.Height - h1; dest.SetSize(w, h2, TPixelFormat.RGBA); for scan := h1 to srce.Height-1 do Move(srce.Scanline[scan]^, TBitmapSurface(dest).Scanline[scan-h1]^, srce.Width * 4); Image2.Bitmap.Assign(dest); finally dest.Free; end; finally srce.Free; end; (the example explains how to handle very large images). Here also a simpler solution (just don't use the "with" ...)

TMS Maps claims that they support TomTom, not tested that.

https://en.delphipraxis.net/topic/5406-image32-2d-graphics-library-open-source-freeware/

What does that mean ? The page is here, its not requiring any ther packages, as far as I know. http://www.angusj.com/delphi/image32/Docs/_Body.htm

Samples like that ? https://github.com/FMXExpress/Cross-Platform-Samples

Just a few posts ago, with Image32.

Thanks, thas very interesting news, to solve the ugly SSL issues once and for all. I wonder what prevents them to make it FMX compatible right away, on all platforms, I expect not much VCL code inside ?

Pexels

Have a look at this WP-Client from Embarcadero, maybe its helpful. Not tested it, would be great if you could give us some feedback about it, if you can use it. Looks not that current any more, but maybe a good start.

I like clear pricing strategies 👍

Thats why I always feel cheatet, as a loyal, many year subscription customer. For the normal, official renewal they offered about 27% higher rate than in this offer, while they claim subscription renewal will get lower every year. I from my perspective think that they choose renewal price by a kind of monte-carlo method, every year new. Shall I contact my sales office ?

Yes, WordPress has a REST API. There was a security warning some time ago, better not to use it, but I'm not sure about the current state. I think it should be safe and stable.

Hi there, maybe that link helps to check the status of some services.

No

@PeterPanettone Why do you insist of some special stuff, that Uwe and others already explained in detail several times. Why not simply say "thank you very much for the insights and the valuable time you offered to me" ? Why getting more and more agressive about people that only try to help you ? Why do you expect other people doing something especially for you, while shouting at them ? Questions, questions, questions 🤔

Maybe thats more current, from Vinicius Sanchez

Yes, I considered that approach too. But I am not a big fan of hundrets of sub-folders, especially because Delphi doesn't support relative paths well (except in the .DPR). If Delphi would allow uses including relative paths, I would go for this approach too, meanwhile I try to abstract by "namespaces". The advantage of "mainspaces" like above is, that the files are not cluttered all over different sub-folders, but they are nicely sorted side by side. That way, I can even add further sub-modules, that are related to the domain: My.SpecialUnit.pas //<= Common functionality My.SpecialUnit.SubModule.pas //<=SubModules My.SpecialUnit.SubModule.iOS.pas //<=SubModule with specific workaround for iOS My.SpecialUnit.SubModule.Other.pas //<=SubModule with implementation for all other platforms My.SpecialUnit.Win.pas //<= Specializations, workarounds, fixes My.SpecialUnit.iOS.pas My.SpecialUnit.And.pas My.SpecialUnit.Macos.pas My.SpecialUnit.Linux.pas Of course the folder approach would be nice, because thats even removed IFDEFS, but also make the "path" handling in Delphi more fragile. Thats why I don't use it via the different platform designer in Delphi, this is only differentiating the Form, but hardly to manage different behaviour too. I separate different "Views" in TFrames, and on them I can use whatever I like. My.SpecialView.Frame.Win.pas // Maybe this uses StringGrid My.SpecialView.Frame.Win.dfm My.SpecialView.Frame.Tablet.Mobile.pas // Maybe this uses Popup, (for iOS, Android Tablets) My.SpecialView.Frame.Tablet.Mobile.dfm My.SpecialView.Frame.Phone.Mobile.pas // Maybe this uses ListView, (for iOS, Android Phones) My.SpecialView.Frame.Phone.Mobile.dfm My.SpecialView.Frame.Macos.pas // Maybe this uses HtmlGrid, (for Macos) My.SpecialView.Frame.Macos.dfm My.SpecialView.Frame.pas // Here I can manage to include the right code in the uses, and forward that as interface // All the frames above include the same Interface, so they encapsule the same behaviour, only in different views. // This interface, according to the platform, can be simply forwarded or wrapped if needed My.SpecialView.pas // Here I can handle the interface, for usage of the certail "view" // Like forwarding the right interface and Factory // The whole unit block keeps nicely together, avoiding cluttering into many, unrelated units and folders. The single views can be nicely edited, by the TFrame designer in a RAD manner, and I can add and visually design as many components as needed for each platform. I can handle the different "views" by a single interface, so from the users perspective the different platforms doesn't really matter. The caller doesn't need to care if he is on desktop or mobile (in the best case), he simply can use the same code in many projects. The views can easily be extended. Of course the abstractions of different platforms are somewhat difficult, but it turned out that many "standard views" can be identified, and easily unified. As example: Dialogs, Login, Logger, InternalDebug, View of Lists, and whatsnot This is what are 1:1 same in all my apps, and work on all platforms in the same way. This way I can replace many "components" by such "view interfaces", and the caller deals only with the interfaces with their expected, well defined behaviour. All workarounds, fixes and platform differences, version differences are well hidden in the structures behind.

Right, and this is why I separate those differences into different views and classes, so that in the end you might have still "one source", which might be dynamically switched from platform to platform. I use mainly frames to define different kinds of views and sub-views, and plug them together as needed. Very important is to have a strict nomenclature and naming scheme of files, to handle the separations, I use the Postfix if separations by platforms are needed, like My.SpecialUnit.pas //<= Common functionality My.SpecialUnit..Win.pas //<= Specializations, workarounds, fixes My.SpecialUnit..iOS.pas My.SpecialUnit..And.pas My.SpecialUnit..Macos.pas My.SpecialUnit..Linux.pas Sometimes I start a new unit, but when it turns out it needs separation, then I rework it to above scheme. I try to avoid IFDEF's in the code, but only in the uses section. What I meant regarding different platforms is more a visual and behavioral decision, like on mobile phones use TListView, on tablets use a kind of popup view, and on desktop maybe a TStringGrid. All approaches show maybe same or similar info, but in a platform dependend way, using the same interface in the caller wherever possible.

This nice and detailled walkthrough from Kim Hyun-Soo (Humphrey Kim) is maybe also somewhat related.

That could be a problem in the near future, since Apple doesn't care much about backwards compatibility. So if you really want to use iOS seriously, my recommendation would be to use a more late Mac for that, even if that is more expensive. http://www.deltics.co.nz/blog/posts/3066 The big question is howto find a reasonable cost/benefit relation these days, maybe refurbished items ?

Interesting coincidence, that Jeroen came up with the same solution I was working on a few days ago. I used that same approach in a similar situation, but extended that by the use of local double fields, as shadow variables, that were set only once during creation. That way I should get some higher performance when using (calculate) it many times, not needing Rtti conversion all the time, on cost of a little more memory space. Maybe thats useful to add in certain situations.