Rollo62

@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.

I am in the lucky situation that I don't need to migrate any VCL, but can start new, light apps with FMX from scratch. Based on a self-made framework, I'm used to work on all platforms at the same time, meaning one code for all. Different views, e.g. phone, tablet, desktop, I would separate into different frames or forms wherever you need much difference. Of course this doesn't end up in a thick, rich Windows client, but in light and easy to handle mobile-like apps on all plaforms. I must confess that I do nor squeeze as much functionality in, as I did under Windows in the past. So the approach is FMX - mobile first, and so far I think that is OK for most of my apps since it helps to keep apps light and easy. If you need really heavy database related stuff, probably I would do that on VCL, and separate code to mix in some light FMX version too.

If you don't want to switch to D11 yet, I would highly recommend already to "porting and testing" from D11 to the older version, as much as you can. This will help to keep updated and makes the final upgrade in the future more reliable and easy. Otherwise, what @FPiette mentioned, would bite you much harder one day.

Thanks for that list, it added one more item to mby list too, regarding the LicenseManager See below, hope that helps too: Backup - IDE (old) Backup projects : Last project states, under IDE (old) - IDE (old) Backup libraries : Last library states, under IDE (old) - IDE Keystores, SlipFiles, Setups, ... UnInstall - Delphi AddOns … - Delphi : Interbase - Delphi : IDE … - AdoptOpenJDK : Java Cleanup IDE ( is no full cleanup needed ) - : Just uninstall IDE, Interbase, AdoptOpenJDK - : keep the registry untouched - : remove all file links - : Cleanup CatRepo, SDK, etc. Whole folder can be removed => C:\Users\Public\Documents\Embarcadero\Studio\ - : Keep AppData Roaming: => C:\Users\NAME\AppData\Roaming\Embarcadero\BDS\21.0\ (containing keystores, etc.) Cleanup Paranoic Checklist => Launch License Manager from bin folder and delete any trial or beta (Test Field) license that you can find. Check it under “License Details” in the center column. 0. Backup: Save all Projects, save VM !! Save all Rx-Sources and Rx-Samples for later comparison 1. Launch the License Manager from the bin folder (by default "C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\LicenseManager.exe") and delete any trial or beta (Test Field) license that you can find. Check it under “License Details” in the center column. Beta: Field testers should also do the following (and others may want to as well): Delete the Godzilla license from License manager before uninstalling it or during the installation of RAD Studio 10.x --> Removed BetaLicense, keep the normal license 2. Uninstall from ControlPanel Under your Control Panel's Program and Features Add/Remove Program uninstall the following entries: RAD Studio 10.2 version 19.0 --> Remove the IB2017 Server (Automatic) --> Remove RadStudio (all GetIt Packs are removed, until finished) If you had problems in the second step (uninstalling from Windows Control Panel), try this Microsoft tool to solve uninstallation problems: http://go.microsoft.com/?linkid=9779673 --> EasyFix Lösungen werden nciht mehr zum Download angeboten 3. 32Bit: remove the C:\Program Files\Embarcadero\Studio\19.0 directory (or the custom folder you had used). 64Bit: remove the C:\Program Files (x86)\Embarcadero\Studio\19.0 directory (or the custom folder you had used). --> Admin 4. Remove the cd C:\Users\Public\Documents\Embarcadero\Studio\19.0 directory --> 20.0 CatalogRepository, BLP, DCP Remove the cd C:\Users\Public\Documents\Embarcadero\Studio\dbExpress Remove the cd C:\Users\Public\Documents\Embarcadero\Studio\FireDAC --> All under Embarcadero removed Remove the cd C:\ProgramData\Embarcadero\Studio\19.0 directory. --> All under Embarcadero removed (Licenses RadStudio, IB2017) Remove the cd %APPDATA%\Embarcadero\BDS\19.0 directory. --> !! Keep all new .keystores for Android --> Removed all under Embarcadero (AppData\Roaming) Remove cd C:\Users\reg_w\OneDrive\Dokumente\Embarcadero\Studio\ --> CodeTemplates, Projects --> !! Keep only old iOS/Macous SDKs Remove the HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\19.0 registry key --> Remove complete unter Embarcadero 32Bit: remove the HKEY_LOCAL_MACHINE\SOFTWARE\Embarcadero\BDS\19.0 registry key 64Bit: remove the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Embarcadero\BDS\19.0 --> Remove complete unter Embarcadero Remove the .lldb folder for Android SDK 5. Search registry "Embarcadero", remove any leftovers BDS.bdsdeploy, Embarcadero Modeling, MUICache, GetIt, ToolsAPI, Midas, CommonTasks, Interop, BorDb, GetItHelper, BorDbHelper, Midas, TogetherInterOp, TogertherOptionInterop, Current Software Explorer TypedPaths - cannot be removed WinNT CompatibilityAssistant, IB Unwise !! Indexer Path, SourceInderxer Path - kept because of conted items !! Install Properties kept !! MS Win SDK installer kept !! UserSettings kept !! FireWallRules kept !! Path kept - cleanup via Windows ControlPanel "Umgebungsvariablen bearbeiten" --> Remove all Embarcadero references Path: OLD: C:\Program Files (x86)\Embarcadero\Studio\20.0\bin;C:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl;C:\Program Files (x86)\Embarcadero\Studio\20.0\bin64;C:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl\Win64; C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath; D:\Prg\Embarcadero\Studio\19.0\bin;C:\Users\Public\Documents\Embarcadero\Studio\19.0\Bpl;D:\Prg\Embarcadero\Studio\19.0\bin64;C:\Users\Public\Documents\Embarcadero\Studio\19.0\Bpl\Win64; %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\GitExtensions\;%SYSTEMROOT%\System32\OpenSSH\ 5. 32-bit: remove the following files from C:\Windows\System32\: BDEAdmin.* CC32*.DLL Midas.* Xerces*.DLL 64Bit: remove the following files from C:\Windows\SysWOW64\: BDEAdmin.* CC32*.DLL Midas.* Xerces*.DLL --> Was already removed by uninstaller

I am just considering what could be the use cases. How would it behave if you put B into a const parameter, passing it into a procedure. Is the SetLength( AParamOfB, SizeOf( AParamOfB ); behaviour then still be maintained ? This could maybe make sense, to have several different functions, while some need a unique copy, some don't.

Try var LTask : ITask; begin LTask := TTask.Run( procedure begin ... end ); end; If you don't need LTask to control the running task later, which I assume in your case, you better completely leave that out begin TTask.Run( procedure begin ... end ); end;

From my understanding of Miletus, it uses the standard OS browser anyway, so its just an option to make the web-app "installable". The additional advantage of Miletus I see is, that it could open and add certain features to a web-app, that wouldn't be possible for a pure browser. (Like IO/ access or controlling specific hardware, also time-critical tasks, or the like). To make that option real, TMS would have to open Miletus, best of all as open source, so that it could be easily extended when needed. That would be a real advantage over Electron.

Well, don't worry, that happens from time to time to all of us

You could assign an Event, and process more property than one inside. BTW: FMX.Types.TFmxObject.AnimateFloat is deprecated.

Exactly, if the IDE would safe my valuable time, then the high cost for the IDE is getting less and less problematic. Unfortunately at the moment the IDE eats up my time, instead of releasing.

You can watch similar thread in german DP, maybe thats helpful.

If you consider most modern AI, I would consider that Python is currently the right choice, although you could do everything in Delphi too. The main advantage of Python is IMHO that a huge bunch of libraries amnd code is available, especially in the AI direction. Since Python has limited UI options, what about a combination of Delphi and Python via Python4Delphi ?

I always try to use most basic components, to reduce possible problems. Like TToolbar => TLayout, and nested TLayout's for all other grouping when necessary, all together with TAlignLayout and Margins to achieve a responsive behaviour. Buttons I use TAlignLayout.Left, with Margins Left, Top, Bottom, so I can nicely arrange them one after the other.

You could also use https://myip.dnsomatic.com/ to get the IP, but if this is used for your own purposes it might be better to host it on your own PHP server. Like this #php 7.x <?php $ip = isset($_SERVER['HTTP_CLIENT_IP']) ? $_SERVER['HTTP_CLIENT_IP'] : isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : $_SERVER['REMOTE_ADDR']; echo "The user IP Address is - ". $ip; ?>

Right, I know this doesn't solve your issue directly. I thought of virtualizing your own Delphi app on the remote system, that maybe remotes Word locally somehow, but only you know what you need exaclty.

Maybe Cybele Software is also interesting, if you look for a solution with Delphi.

I would not say that, in regards of Var(). For me personally, I knew Var(), but never worked with that really. So its fair to find where its benefits and disadvantages are, also its do's and don'ts. I expected a hidden pearl, 10 min ago, but it seems that I only found an empty oyster

I have created some small Var() tests (for positive numbers), to check the behaviour under Rx11, probably it behaves different in older versions. It has so many corner cases, better know exactly how and when to use it. See yourself, and maybe find the right story for the use-case. procedure Test_Val; var LTest : String; LResD : Double; LResI : Integer; LPos : Integer; begin LTest := '123'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 123 LPos 0 OK Val( LTest, LResD, LPos ); // LRes 123.0 LPos 0 OK LTest := '123.4'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 123 LPos 4 MAYBE acceptable as TRUNC, if LPos < length ? Val( LTest, LResD, LPos ); // LRes 123.4 LPos 0 OK LTest := '123,4'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 123 LPos 4 MAYBE acceptable as TRUNC, if LPos < length ? Val( LTest, LResD, LPos ); // LRes 123.0 LPos 4 MAYBE acceptable as TRUNC, if LPos < length ? LTest := '123a'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 123 LPos 4 ERR, acceptable as split before char, if LPos = length ? Val( LTest, LResD, LPos ); // LRes 123.0 LPos 4 ERR, acceptable as split before char, if LPos = length ? LTest := '123.4a'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 123 LPos 4 ERR Val( LTest, LResD, LPos ); // LRes 1234.0 LPos 6 ERR ???, MAYBE useful to "digitize" a float ? LTest := '123,4a'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 123 LPos 4 ERR Val( LTest, LResD, LPos ); // LRes 123.0 LPos 4 ERR LTest := '.5'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 0 LPos 1 ERR Val( LTest, LResD, LPos ); // LRes 0.5 LPos 0 OK LTest := ',5'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 0 LPos 1 ERR Val( LTest, LResD, LPos ); // LRes 0 LPos 1 ERR LTest := '.5a'; LResD := 0.0; LResI := -1; LPos := -1; Val( LTest, LResI, LPos ); // LRes 0 LPos 1 ERR Val( LTest, LResD, LPos ); // LRes 5 LPos 3 ERR end;

Interesting, I had overlooked and forgotten this little, ancient piece for years. I thought this was only Integer, but it seems to work with Real = Double as well. The only problem is that it ignores the decimal separator, so the result of '123.4' will be an integer 1234; Which doesn't make sense only in a few corner cases, for handling with Real. But good to know that it exists anyway, and to point into that direction again.