Rollo62

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.

See also here https://www.thedelphigeek.com/2021/02/readers-writ-47358-48721-45511-46172.html