Rollo62

Hi there, I'm doing some R&D with a minimal app, trying to get some insights on growing festure sets. My system is Delphi D12.1, Android 14, App in DEBUG mode, MinimalApp with TLayout, TLabel and TMemo - not using any other hardware or library yet. There I see sudden exception on startup, quite sporadic, just by changing the permissions and uses-features, and I wanted to find a deeper reason or explanation for this. What I found, even if I completely remove all permissions by hand from the *.dproj, from all "_Base" and sub positions ( = not any SUP_INTERNET ). There is no more AUP_... in the file, nor any checkbox in the Permissions Options, and no permission in the Android.Manifest.template.xml either. Meaning: <PropertyGroup Condition="'$(Base)'!=''"> ... <AUP_INTERNET>true</AUP_INTERNET> //<== Removed even this line, and any other AUP: in this file ... </PropertyGroup> But still, the IDE generated an INTERNET permission in the manifest file <uses-sdk android:minSdkVersion="23" android:targetSdkVersion="34" /> <uses-permission android:name="android.permission.INTERNET" /> So why is INTERNET always there, is this because of "Mobile" app is kindof "Internet", or what? Is this a BUG or a FEATURE?

I've tried the same minimal app in RELEASE, and YES, the INTERNET permission is gone. Your answer can be a good explanation to what happens, so I would note to myself that android.permission.INTERNET => is required always, in DEBUG mode. This would make sense and that would be a good explanation, unless there is another hidden requirement lurking around the next corner.

This was just for testing, not needing CAMERA right now, only in some apps. Yes, interestingly the exception occured when CAMERA is off (1.), and not when its ON (2.). I tried to enable it, from some proposals during my research, at least this helped to fix the exception. Since I see sporadic exceptions from time to time during debugging, after un-suspicious changes in code, for no specific permission-related reason, I assume that the ADB, gdb server and the whole debugging system has a lot to do with this shaky behaviour.

Hi there, I was looking into @Uwe Raabe's CmonLib at Github and found here a global TUtilities record. type TUtilities = record private class var FAppName: string; FCompanyName: string; public ... class property AppName: string read FAppName write FAppName; class property CompanyName: string read FCompanyName write FCompanyName; end; I'm doing something similar, to provide the global CompanyName and AppName for various purposes, but best of all as early as possible in the process, for example for logging, or the like. Where doese CompanyName, AppName come from,. do you do this in code? What would be the best approach to provide such data for each project in a simple way, as early as possible from external data? - I would love to load such data from settings-file *.json, *ini, *yaml or whatever before compilation, unfortunately I think there is no option to do so. - Using ressources, deployment or the like to include such settings-file could work, but when analysing the content, its already much too late in the startup process. This might work only for certain cases, but not the most earliest. - Ok, I could use the IDE's global defines option manually, to add each of the desired data, but I really don't like to fumble in that nasty options dialog by hand. - Yes, I could use pre-build-events to manage that from a settings-file, but thats also only a half-cool solution. - And I could write my IDE expert doing this, perhaps there are already some available, but I like to have my IDE as clean from experts as possible. - I could use my own StartUpCopy.pas in the *.dpr, to define the earliest settings there, also a too clumsy solution. - Actually I simply added a local settings-include-file (*.inc) , with defining data as defines, and include this wherever needed, which is also not the best solution. Do you have similar needs and how do you do that, is there any cool solution I have not considered yet?

@Uwe Raabe Very interesting, I will look into that. Its perhaps not needed to be before unit initializations, but yes, if that is possible, then its OK too. I have two main topics currently for that, "Logging" and "Setup file access". By the latter I mean, to load variable settings from files, not at compile time, but at runtime. For this I could see sometimes the need to access that as soon as possible, while the "FileNamesAndPaths" might not be setup yet. Of course I can hardcode the fractions or subfolders in the "FileNamesAndPaths", but exactly this I want to avoid. I usually avoid initialization sections and try to make such lazy app initializations only in the FormShow event, to stay as mobile friendly, as possible. But that doesn't always work. At least a handful of fixed constants would be good to be store outside the IDE project, to easy handle it. Regarding your proposal, my thought was to encapsule this in its own StartUp unit: uses My.StartUp, Vcl.Forms, Main.VclForm in 'Main.VclForm.pas' {MainForm}; {$R *.res} begin TMyStartUp.PreInitialize; Application.Initialize; ... But again, if needed earlier it might fail. @Kas Ob. I'm not getting your point 100%, but assume you mean an Pre-Build-Event calling an batch file. Yes, that would be possible, but again, I have to setup all this in the IDE before. Or do you mean there is the possibility in the Tools/Options or else, to set such event globally, one for all projects? Yes, maybe creating my own initial project in the repository is an option too, but this I would need to maintain too, with each IDE update.

Hi there, I'm not sure whether this new project is already known throughout the community and whether it has already got enough attraction. @Remy Lebeauhas written about it in the Blog here and a separated reposity is available here. That is very good news that Indy OpenSSL seems to get a little more traction now, to solve such very basic network topics. I hope that this new project will be a big hit and will take Indy OpenSSL to the next level. From VCL to FMX across all platforms.

Ok, but still unclear if this can be used as internal "server" too, especially on mobile. As described above, the apps will act as a real embedded HTTP web server, right? This will make little sense for any mobile app, perhaps. But in any app on any platform, to have just a "local" server, that doesn't conflict with firewalls, permissions, etc., and which is just responsible for the UI part, that will make a lot of sense. This will enable an easy way to separate the UI from the business logic, IMHO. So can it be used that way, or is it even intended for that purpose?

Firewall ? Ping ?

I roughly get the point of this, by peeking through the docs. Opens a few questions: Does this work also locally, standalone, meaning that one App contains a kindof internal service, together with a TWebBrowser in the same app? So that there is no real server is used, only perhaps internal communications with the TWebBrowser component. Other question, if this could work as above on Android and iOS too? Perhaps the answer to 1.) and 2.) is "No", which would explain why 2.) is not available for mobile platforms yet. Is this part of the HtmlComponents package and already available for testing, by using the current download link again?

<OT> Thanks for pointing to this. I did not stumble into this issue yet, buut .... maybe .... It could explain the nasty misbehaviour I had recently with the GoogleMaps App herself. The lower buttons didn't react and it was not possible to operae as it should. I had the verdict that an recent update of the Samsung S23 Ultra caused this issue, but perhaps somehow remotely related to above behaviour. At least no visual effect appears anyhow, as far I can say, only un-clickable in the footer row. </OT>

CrossPost https://www.delphipraxis.net/1539305-post6.html I thought this basic question was clarified already here 🤔

This is of coarse a question of personal naming preferences. "Common" and "Implementation" sounds to me too much like implementation details. Thats why I personally like MyTask and all other related details are defined after, like MyTask.Types MyTask.Intf MyTask.Impl MyTask.Factory My goal is, that when using MyTask, I would never consider anything of the "details" above, in the best case. Thats also why its the shortest name and only talking about the task itself. And yes, there surely can be different naming variants too, like MyTask.Utils, wherever this makes sense to use them separately.

In general you are right, but maybe I have not explained the setup good enough. I want to define a sub-system, which might be a little more complex, so that I can divide it into several sub-units, to modularize the whole task and to avoid monolithic classes. The main "access" unit shall only provide access to this sub-system, but of coarse the main purpose is to avoid any circular references in the first place. The modularization helps to separate concerns only needed within this sub-system and improves testability. You are right that code tends to get entangled over the years, but to entangle and repair only this "one" sub-system is much easier IMHO, than to entangle these main separate sub-units, which are maybe cluttered wildly all over the project. I use also a clear naming convention that supports the whole context, for example like: MyTask.Types MyTask.Main.Interfaces MyTask.Main.Implementations MyTask.Sub.Interfaces MyTask.Sub.Implementations MyTask <= I use this as the main accessor unit containing type ETypes = MyTask.Types.ETypes; TTypes = MyTask.Types.TTypes; IMain = MyTask.Main.Interfaces.IMain; ISub = MyTask.Main.Interfaces.ISub; TMyMain_Factory = class function New_Main : IMain; function New_Sub : ISub; end; .... This way, I only need MyMain unit to handle the tasks from outside. When I just need lightweight access to the types or interfaces in other classes, I still can use MyTask.Types, MyTask.Sub.Interfaces or MyTask.Main.Interfaces without any harm. Not sure if this would make any big benefit. The whole implementation details shall be well hidden behind the MyTask unit. Just roughly throw the code in here, to get a better picture of what I meant. The whole thing needs of coarse strict discipline too, not to use side-effects, which is probably the weak point. My argument is, if you use this approach it shall be guaranteed that you never get any circular reference issues. While using loosely couples units, you're never sure if you see any circular or other side-effects.

I like to use such an approach especially if a topic is divided into a set of several related units, which tend to rely on or build a common type system. In my opinion this helps to point out the internal relations, to better organize the units and to avoid circular references. In that case I have defined one main "access" unit, which works as a fascade to cover a few closely related internal units, while in the other sub-units different implementation details are encapsuled. The idea is, that the main "access" unit provides all necessary classes and types in one single unit, with no need to include many other sub-units. This helps to separate various sub-concerns nicely, and bring the complete functionality in one place. That way, of course I still can use the sub-units separately, if there is any need. Perhaps this is another philosophical question, or is there another rule of programming that speaks hardly against this?

Thanks for pointing to this, there I also find the link to Darian Miller's great version list https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List Thanks for that great summary. Which makes me reconsider my simplified, internal nomenclature, which also uses 3 elements Major, Minor, Update. Nevertheless, I think this list is perhaps not 100% clear regarding the patch nomenclature, or I miss something, for example. VER360 D29.ATHENS. 12.1.0.1 12.1 Patch 1 VER360 D29.ATHENS. 12.1.0.0 RAD Studio 12 Athens Release 1 VER360 D29.ATHENS. 12.0.0.2 12 Inline Release VER360 D29.ATHENS. 12.0.0.1 12.0 Patch 1 VER360 D29.ATHENS. 12.0.0.0 RAD Studio 12 Athens VER350 D28.ALEXANDRIA.11.3.0.0 RAD Studio 11 Alexandria Release 3 VER350 D28.ALEXANDRIA.11.2.0.1 11.2 Patch 1 VER350 D28.ALEXANDRIA.11.2.0.0 RAD Studio 11 Alexandria Release 2 VER350 D28.ALEXANDRIA.11.1.0.2 11.1 Patch 2 VER350 D28.ALEXANDRIA.11.1.0.1 11.1 Patch 1 VER350 D28.ALEXANDRIA.11.1.0.0 RAD Studio 11 Alexandria Release 1 VER350 D28.ALEXANDRIA.11.0.0.4 11.0 January PAServer Patch VER350 D28.ALEXANDRIA.11.0.0.3 11.0 November Patch VER350 D28.ALEXANDRIA.11.0.0.2 11.0 PA Server Patch for iOS VER350 D28.ALEXANDRIA.11.0.0.1 11.0 Patch 1 VER350 D28.ALEXANDRIA.11.0.0.0 RAD Studio 11 Alexandria VER340 D27.SYDNEY. 10.4.2.3 10.4.2 RTL Patch 1 VER340 D27.SYDNEY. 10.4.2.2 10.4.2 General Patch 1 VER340 D27.SYDNEY. 10.4.2.1 10.4.2 Compiler Patch 1 VER340 D27.SYDNEY. 10.4.2.0 10.4.2 RAD Studio Sydney Update 2 VER340 D27.SYDNEY. 10.4.1.4 10.4.1 Sydney Patch 4 VER340 D27.SYDNEY. 10.4.1.3 10.4.1 Sydney Patch 3 VER340 D27.SYDNEY. 10.4.1.2 10.4.1 Sydney Patch 2 VER340 D27.SYDNEY. 10.4.1.1 10.4.1 Sydney Patch 1 VER340 D27.SYDNEY. 10.4.1.0 10.4.1 RAD Studio Sydney Update 1 VER340 D27.SYDNEY. 10.4.0.0 RAD Studio 10.4 Sydney ... This leads me to the rule for versioning: Major Release Update Patch version version version version 10. 4. 2. 2 Where the 4 elements have the meaning: Major = is the major version Release = is a kind of Minor version Update = is a kind of kumulative, big Patch or Build Patch = is a kind of Build, as small patch, or inline release, or maybe build, where the numbering and naming can be not very consistent. Patch can be a running number, no matter if the original patch number may differ. VERnn0 = A combination of relocated running Major and Release, with the options to have a 3rd number for exotic reasons (not happened in the near past). Is my understanding of the everchanging naming wilderness correct, to get a more consistent view about this? At least for future releases. The question will be, how to detect the Update and Patch parts by runtime correctly? I think this is not consistently possible at all, and always will be a manual process, or a lot of hardcore trickery, by checking DLL versions or the like.

Nope. This link works https://www.cravencountync.gov/263/GIS-Mapping but clicking from there into https://gis.cravencountync.gov/ doesn't work on Windows 11. Ok, I'm not living in USA, so maybe some kind of IP-blocking? Edit: Yes, after VPN I can reach this from Windows. https://gis.cravencountync.gov/images/activebookings.html

Have you set the NSAppTransportSecurity and other Flags in the info.plist, according to your needs? Here is a sample, for various settings: <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <!-- Example for >= iOS 9 --> <key>NSExceptionDomains</key> <dict> <key>example.com</key> <dict> <key>NSIncludesSubdomains</key> <true/> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSExceptionRequiresForwardSecrecy</key> <false/> </dict> </dict> </dict>

Is this something that could match your needs? (untested) type QCL_WORD = SmallInt; t_bus_flags_w4 = record private data: QCL_WORD; function GetBit(Index: Integer): Boolean; procedure SetBit(Index: Integer; Value: Boolean); public property AlarmState: Boolean index 0 read GetBit write SetBit; property AlignmentState: Boolean index 1 read GetBit write SetBit; property InversionWait: Boolean index 2 read GetBit write SetBit; property OutOfMinBound: Boolean index 3 read GetBit write SetBit; property OutOfMaxBound: Boolean index 4 read GetBit write SetBit; property BelowSafetyHeight: Boolean index 5 read GetBit write SetBit; property InWorkingPos: Boolean index 6 read GetBit write SetBit; property LockingLatchState: Boolean index 7 read GetBit write SetBit; property BatteryWarning: Boolean index 8 read GetBit write SetBit; property BatteryAlarm: Boolean index 9 read GetBit write SetBit; property EVRState: Boolean index 10 read GetBit write SetBit; property LoadWeightZone: Byte index 11 read GetBit write SetBit; // 2 Bits property ColumnIsConsistent: Boolean index 13 read GetBit write SetBit; property LiftSetAcquireReq: Boolean index 14 read GetBit write SetBit; property MovementModeAbsolute: Boolean index 15 read GetBit write SetBit; end; implementation function t_bus_flags_w4.GetBit(Index: Integer): Boolean; begin Result := (data and (1 shl Index)) <> 0; end; procedure t_bus_flags_w4.SetBit(Index: Integer; Value: Boolean); begin if Value then data := data or (1 shl Index) else data := data and not (1 shl Index); end; // For 2-Bit-Property LoadWeightZone we need some special Getter and Setter function t_bus_flags_w4.GetLoadWeightZone: Byte; begin Result := (data shr 11) and 3; // Extract 2 Bits at Position 11 end; procedure t_bus_flags_w4.SetLoadWeightZone(Value: Byte); begin data := (data and not ($3 shl 11)) or ((Value and $3) shl 11); // Set 2 Bits at Position 11 end;

No nooo, its just like in the Jurassic Park: The strange AI animals can be nice to watch and study, but be very sure to keep the cage door closed

Maybe you could vote for an extension of @Jim McKeeth nice ColorPicker here.

Yeah, it should look like this, originally. But unfortunately the AI refuses to reproduce logos, socks, styles and so on, in the right way. Nevertheless, I'm sure this is quite the right picture of a messy programmer, at least as I am If anybody will tell you that AI ist not ruling the word yet, this proofs him work. AI already dictates how the the political correct content shall look like and refuses to produce anything else you ask for.

b51995d0-8bea-4723-8cf8-ced1a256af59.webp

I still have not a smooth workflow under iOS, as before. With the injection of the current lldb SymLink into the PAServer package, I could at least start an app on a device. It behaves as follows: Compile and RunNoDebug - Deploy and Launch after compile - iOS app gets loaded - After deployment, the app tries to start but immediately fails (due to missing debug support) - The app pops up shortly, then crashes immediately - At least I can start the app manually Compile and RunWithDebug - Deploy and Launch after compile - After deployment, the process stucks (due to missing lldb), PaServer messages look as below - The problem is, that the IDE crashes too and must be restarted, same as PaServer. The PaServer process seems to continue even after close. - I used to kill all PaServer processes ( can be more than one ), by shell command, but thats an ugly solution. - I've found a possible solution by PaServer command s ( stop server = kill the process ) and restart PaServer again - But that doesn't prevent the IDE crash. It is really a messy workflow now, if pressing the wrong button it crashes, debugging is no longer possible. XCode_1540, RadStudio 12.1 Upd 1 Does this behave now same on all machines, or is it only here? I really hope for a fix, that bring back normal debugging soon, I hope by patch of IDE & PaServer. Is there anything I still can improve by myself?

Great, nothing is overengineered here at all. I was looking for something like that for a long time, already wanted to design my own, used MustangPeak under VCL in some projects. Color theory is a science on its own. Solving any task completly without leaving out necessary parts in the first place is NOT a definition of Overengineering, IMHO In case of someone is overwhelmend from reality, you could consider to introduce several "dummy-mode levels", to hide any frightening complexity from the more sensitive users.