Rollo62

Yes, but you could move and align the separate browser over your app, so that it appears as a kind ov WebView Component of your app. This is way way far from perfect, but I had seen some guys doing like this in the long past. Just saying ...

Yup. but using the W3C official WebDriver functionality for that. So it depends on how you want to call it

That is right of course, this was just a 2 minute test on how the signing might behave after closing down K-Software, and if it still works as before, which seems to be OK. Yes, perhaps SSL is the right way to go. At least their pricing seems not that unrealistic. https://www.ssl.com/certificates/code-signing/buy/ Comparing a 3yr plan 3 years - $109.65/yr (save 15%) they end up at 330 USD. Plus the Yubikey itself, wich is a but overpriced with 279USD, which makes a total of 609 USD, at least only hopefully in the initial order. While I get one here for 101 EUR incl. VAT. which is rougly 98USD, which could reduce that to nearly 428USD https://www.yubico.com/de/product/yubikey-5-fips-series/yubikey-5c-nfc-fips/ Would be great to know if all compatible Yubikeys can be used with SSL, or if they have some specific catch included, so that we need the expensive key from them. Additionally they note about eSigner Tier, which seems to be a kind of subscription like for 20USD/Month for 20 Signings with 1 Credential or 64USD/Month for 100 Signings plus 5 Certificates. I have not read the fineprint yet, but it looks as if you would need such subscription too. Is that eSigner Tier additionally needed, or is it a different way beside usual yearly certificates? This seems to me like a very clever marketing strategy, to split cost into more granular parts and make it seem more attractive as it possibly is, my respect for that smart business strategy. But on the other side its just a lot of money to pay still for a pure virtual service, with close to 0 USD production cost, but thats a different story. They also offer 10yr strategies, where I don't know if the world as we know it still exists. Nevertheless, perhaps during that time the YubiKey hardware may have the need to change too, since such chips and firmware are not build from granite. As long as an automation with Singnotaur or signtools is possible and no "fingerprint" or the like is needed on a Yubikey, this is perhaps the way to go.

@Angus Robertson Yes, you were a bit faster hitting send than me I had bought a 3 years license, to get a little more time until the USB tokens questions were settled. My license should be valid until 03/2026. I've paid for the 3yr license in 2023 209 USD and now the best deal with KSOFTWARE25OFF (which is same as black friday -25%OFF), they ask for 981.00USD and the non-rebate cost is 1,308.00USD. This means I better look for an Sectigo-Alternative. Now I'm unsure what happens with my existing rest-license, how will Sectigo handle it, for example if I use the kSign.exe? When I sign something with kSign.exe, which already was deprecated, this still works and shows certificate info "Sectigo Public Code Signing CA R36", everything looks allright here. If anybody has more insight, what goes and what doesn't, please let me know.

Perhaps an AppWizard could fit ( not exaclty ), although its quite outdated, but maybe interesting to read and get ideas anyways. https://www.deltics.co.nz/blog/posts/1774/ https://www.deltics.co.nz/blog/posts/1791/ https://www.deltics.co.nz/blog/posts/1817/

Exactly, thats why I place my unit here in the *.dpr at high position, similar to System.StartUpCopy. I can use my special functions or classes then still later on in the *.dpr, if you prefer that. uses System.StartUpCopy, System.Math, FMX.Types, FMX.Forms, My.App.StartUp, ...

I understand your attempt to make the initial application creation more usable and flexible. AppData:= TAppData.Create('Light Template Micro'); AppData.CreateMainForm(TfrmMain, TRUE, TRUE, asFull); But don't forget that the *.dpr is managed a lot by the IDE and fumbling into this can create various issues. If you want to manage that on your own, I would suggest doing this in another, separate unit, not the *.dpr itself.

By using By using anonymous procedures, instead of calling with parameters directly. The question is how you could trigger that call to the anon proc in the right sequence. After the real CreateMainForm a message is sended. TMessageManager.DefaultManager.SendMessage(Self, TMainFormChangedMessage.Create(FMainForm)); There is also a TMainFormChangedMessage or FormAfterCreateHandler which could make sense here. procedure TApplicationEvents.FormAfterCreateHandler(const ASender: TObject; const AMessage: TMessage); //or better procedure TApplication.SetMainForm(const Value: TCommonCustomForm); begin if FMainForm <> Value then begin FMainForm := Value; TMessageManager.DefaultManager.SendMessage(Self, TMainFormChangedMessage.Create(FMainForm)); end; end; Perhaps you can catch one of these in your class and try to re-fine the desired settings you want to change.

And just some more tests, working perfectly for me 👍 //Saves the whole page, as expected Driver.Document.SavePrintedPdfPage( 'screenshot.pdf' ); //Saves the current page fragment, as expected var LBytes := Driver.Screenshot.TakeScreenshot; var LStrmFl := TFileStream.Create( 'screenshot.png', fmCreate ); LStrmFl.Write( LBytes, Length( LBytes ) ); LStrmFl.Seek( 0, TSeekOrigin.soBeginning ); LStrmFl.Free;

Perhaps this port 9515 came from chrome, as a kind of de-facto standard port, this is used in Chrome, Edge and elsewhere, except Firefox, it seems. https://developer.chrome.com/docs/chromedriver/logging/performance-log Yes, that works geckodriver.exe --port=9515 1763973920006 geckodriver INFO Listening on 127.0.0.1:9515 of course, if this port is already occupied, the geckodriver complains d:\Projects\Tests\T534_TstDwDriver\Packages\Bin>geckodriver.exe --port=9515 1763974057118 geckodriver INFO Listening on 127.0.0.1:9515 ^C geckodriver.exe --port=9515 geckodriver.exe: error: Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden. (os error 10048) WebDriver implementation for Firefox while MsEdge started on port 64864, while their WebDriver docs refer to port 9515 also, thats strange ... https://learn.microsoft.com/en-us/microsoft-edge/webdriver/?tabs=c-sharp&amp;form=MA13LH#other-webdriver-installation-options Starting msedgedriver 142.0.3595.94 (6565d6e52817b2cc1cc39186799218803a00a752) on port 0 To submit feedback, report a bug, or suggest new features, please visit https://github.com/MicrosoftEdge/EdgeWebDriver Only local connections are allowed. Please see https://aka.ms/WebDriverSecurity for suggestions on keeping Microsoft Edge WebDriver safe. msedgedriver was started successfully on port 64864.

@ABDERRAHMANE Thanks, this is great stuff. 👍 I fastly checked, but for me the geckodriver starts only with Port 4444. I'm afraid I need to use different ports for the different browsers then, see comments below, to get it running on Firefox. Is the default port 9515 kindof pre-defined by W3C and only FF does its own thing ? procedure TMainForm.StartDriverButtonClick(Sender: TObject); var Server: TWebDriverServer; Driver: IWebDriver; BrowserConfig : TWebDriverBrowserConfig; LBasePort : Integer; //<== HERE added begin LBasePort := 9515; //<== HERE added the default port if ChromeRadioButton.IsChecked then BrowserConfig.Browser := wdbChrome; if FirefoxRadioButton.IsChecked then begin BrowserConfig.Browser := wdbFirefox; LBasePort := 4444; //<== HERE added a specific port end; if EdgeRadioButton.IsChecked then BrowserConfig.Browser := wdbEdge; if OperaRadioButton.IsChecked then begin // for opera you have to set the opera binary file path BrowserConfig.Browser := wdbOpera; BrowserConfig.BinaryPath := 'C:\Users\<YOUR USERNAME>\AppData\Local\Programs\Opera\opera.exe'; end; if BraveRadioButton.IsChecked then begin // for brave you have to set the brave binary file path + you should use the ChromeDriver binary BrowserConfig.Browser := wdbBrave; BrowserConfig.BinaryPath := 'C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe'; end; if BrowserConfig.Browser = wdbUnknown then begin LogsMemo.Text := 'You must select a driver'; Exit; end; // if you have specific path for the driver path then set it with the BrowserConfig.Browser.DriverName // for ex : Server := TWebDriverServer.Create('C:\drivers_folder\' + BrowserConfig.Browser.DriverName); Server := TWebDriverServer.Create(BrowserConfig.Browser.DriverName); try Server.Start( LBasePort ) ; //<== HERE added Driver := TWebDriver.Create( BrowserConfig, 'http://localhost:' + LBasePort.ToString ); //<== HERE added too, to replace the fixed port in 'http://localhost:9515' );

Hi there, sorry for the little joke in the title, but what currently makes me headaches is the fact that after May will be broken. I used iOS as stable debugging platform for many years now, which seems to breakdown hard in a few days. The alternative Android was never that stable for debugging over the same many years, getting better now, but no replacement. The big problem now is, that Apple seems to enfore the use of their latest tools after 01.05.2024, which would make the use of XCode 14.3.1 for releases impossible. For the possible XCode changes and reasons I figured out the following possible facts for my record. Perhaps they were not all correct, maybe only a few, so please feel free to correct me, if you have more insights into the XCode ecosystem. In general, there seems to be a huge change in the new XCode debugging system. Overview of the changes seen in XCode 15: Topic Old (Xcode 14.3.1) New (Xcode 15) Comments Debugging platform partly still 32-bit using 64-bit only The new debugging platform seems to remove older 32-bit code internally completely. Debugging Framework GDB-based LLDB-based New debugging framework based on LLDB, incompatible with older GDB-based framework. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Debugging Libraries libgcc.dylib, libc++.dylib, New debugging libraries, incompatible with the older libraries used by D12.1. libstdc++.dylib libc++abi.dylib Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Symbolication Manual Automatic Xcode 15 introduces automatic symbolication, incompatible with manual symbolication used by D12.1. Debugging Protocol GDB protocol LLDB protocol New debugging protocol, incompatible with the older GDB protocol used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers Breakpoint Handling Software breakpoints Hardware breakpoints Uses hardware breakpoints, incompatible with the software breakpoints used by D12.1. Debug Information STABS debug format DWARF debug format New debug information format, incompatible with the older STABS format used by D12.1. Edit: LLDB-ready https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers I would like to know if this huge XCode change is really upcoming soon, and what can we do about it in the near future? Is there any workaround in sight? I'm afraid, that we have to wait for the next Delphi Update or Patch, which maybe changes a lot of the internals ( libraries, PAServer, workflows, ... ). Are there any news from Embarcadero, about this topic, so that we could see any light in the tunnel? Would be great if there is a way, to make XCode 15 compatible with Delphi, or vice versa. My considerations so far: - Use Android for Debugging, even if it not that stable. Perhaps there are ways to improve Android debugging too. - Forget Mobile debugging, rely only on Logging ( the worst case for me ). - Still use XCode 14.3.1 for debugging, while releasing under XCode 15. This is problematic, because I think XCode 14.3.1 dosen't allow to use iOS 17.4, and perhaps two versions cannot switch easily on the macOS host. Are there any tested workflows, like xcode-select --switch /Applications/Xcode14.app/Contents/Developer and xcode-select --switch /Applications/Xcode15.app/Contents/Developer ? That also means, we would possibly need two sorts of devices with iOS 16.x ( DEBUG + Log ) and iOS 17.4 ( RELEASE + Log ) for proper tests ( Permanent upgrade / downgrade is not an option ). - Embarcadero already had worked out a stable Update 2, to simply make iOS 17.4 debuggable and testable. ( The best case for me ). - Any smart hack, to make XCode 14.3.1 producing releases still? Perhaps, setting a build-ID could do the job, but I'm completely unsure about that. When Apple finds such hacks, this may also be considered as infringement and lead in blocking the app in the store, which could be even harder. - Other ideas / news / thoughs, are there any ? Edit: See above table, it seems that Delphi >= Alexandria can already make use of LLDB debugging system: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/LLDB_Debuggers

Thanks, from my investigations based on your input, unfortunately I came to the similar conclusions. But I see one option, Option C below, which is maybe easiest reachable and realistic solution, IMHO. If Delphi could integrate a small Debugger Engine in each App, which is able to debug via PAServer on a Pascal level, which is better than nothing. Embarcadero should have a large library with basic knowledge to design a simple debug engine, that may allow breakpoints, step-over, step-into features and returning all variable readouts. Yes, this might not work down to a machine or CPU level, but this is not really needed maybe in 98% of all cases ( at least from my point of view), in contrast this could be probably reached very fast ( in terms of Delphi speed ). Even if this is only an intermediate solution, while offering debugging until a final solution is there, this would make sense to me ( I see that same useful for Android too, BTW ). This could offer at least a stable, but limited debug solution, which is a bit out of the reach for Apples attempts to destroy 3rd party access. I hope the following analysis could trigger some more input and ideas to think deeper about a clever and fast debug solution. See this analysis below ( ! machine-translated from German to English, from mixed but mainly Claude 4.5 analysis). Why Delphi iOS 17+ Debugging Doesn’t Work – and Whether It’s Solvable Summary Core problem: Delphi compiles to 100% native machine code without an embedded runtime VM. It is precisely this architectural decision—which makes Delphi apps fast—that prevents debugging on iOS 17+. Flutter/MAUI work because they embed a VM/interpreter in the app that can be debugged over a normal TCP socket—a path that Apple has not blocked. Part 1: How Flutter and .NET MAUI Solved the Problem Flutter: Dart VM Service Model ┌─────────────────────────────────────────────────────────────┐ │ FLUTTER APP on iPhone │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Native Container (Runner.app) │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ │ │ DART VM (embedded) │ │ │ │ │ │ • Executes Dart bytecode (debug mode) │ │ │ │ │ │ • VM Service listens on TCP port │ │ │ │ │ │ • Provides debug protocol │ │ │ │ │ └─────────────────────────────────────────────┘ │ │ │ │ ↓ │ │ │ │ TCP socket on localhost:50642 │ │ │ └─────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ↓ Port forwarding via USB/WiFi ↓ ┌─────────────────────────────────────────────────────────────┐ │ MAC │ │ Flutter Tools → connects to VM Service URI │ │ → Breakpoints, Hot Reload, Stepping possible │ └─────────────────────────────────────────────────────────────┘ Key point: The Dart VM runs inside the app. Debugging happens via an application-level protocol over the network layer, not via OS-level LLDB/ptrace. .NET MAUI: Mono Interpreter + Diagnostic Ports ┌─────────────────────────────────────────────────────────────┐ │ .NET MAUI APP on iPhone │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Mono Runtime (embedded) │ │ │ │ • Debug mode: UseInterpreter=true │ │ │ │ • Diagnostic port on TCP 9001 │ │ │ │ • dotnet-dsrouter connects Mac ↔ Device │ │ │ └─────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ↓ dotnet-dsrouter (port forwarding) ↓ ┌─────────────────────────────────────────────────────────────┐ │ MAC │ │ Visual Studio connects via Diagnostic Protocol │ │ → Breakpoints, variable inspection possible │ └─────────────────────────────────────────────────────────────┘ Both use: Xcode/devicectl only to install and launch the app. The actual debugging runs entirely through the embedded VM. Part 2: Why Delphi Cannot Simply Copy This Approach Delphi’s Architecture (the problem) ┌─────────────────────────────────────────────────────────────┐ │ DELPHI APP on iPhone │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Pure ARM64 machine code │ │ │ │ (compiled with LLVM/DCCIOSARM64) │ │ │ │ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ NO runtime VM │ │ │ │ │ │ NO bytecode interpreter │ │ │ │ │ │ NO embedded debug server │ │ │ │ │ └─────────────────────────────────────────┘ │ │ │ │ │ │ │ │ Debugging requires: external LLDB attach │ │ │ └─────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ↓ Requires: ptrace() / mach_task_ports() → BLOCKED by Apple on iOS 17+ for third-party tools The fundamental obstacle | Aspect | Flutter/MAUI | Delphi | |----------------------|------------------------------------|----------------------------| | Code execution | VM/Interpreter (debug) | Native machine code | | Debug mechanism | In-app TCP service | OS-level LLDB attach | | Apple’s blockade | Not affected | Directly affected | | Required rework | None (designed that way) | Fundamental | Part 3: What Would Embarcadero Have to Do? Option A: Embed an Object Pascal Interpreter (theoretically possible, practically unrealistic) Effort: 2–4 years of development, complete redevelopment 1. Develop an Object Pascal bytecode interpreter 2. Embed it in every debug build 3. Implement a debug server protocol (similar to DAP) 4. Completely rebuild the IDE/PAServer Problem: Would undermine Delphi’s core promise of “native code”. The entire RTL, VCL/FMX, and all units would have to work in two different modes. Option B: Use Xcode as the Debug Backend (more realistic) How Flutter does it: 1. Install app with Xcode/devicectl ✓ (already works) 2. Launch app with Xcode/devicectl ✓ (already works) 3. Use Xcode-controlled debugserver ← MISSING 4. Send LLDB commands via Xcode automation ← MISSING What Embarcadero would need to implement: PAServer (Mac) │ ├── xcrun devicectl → install app ├── Xcode Automation (AppleScript/XPC) → launch app with debugger ├── LLDB via Xcode’s debug session → set breakpoints └── Debug protocol bridge → translate commands from Delphi IDE Problem: Apple’s debugserver is only accessible to Apple-signed tools. PAServer would have to act as a proxy for Xcode, which is technically complex and fragile. Option C : Hybrid Approach with Embedded Debug Agent 1. Embed a small debug agent (library) in debug builds 2. Agent communicates via socket with PAServer 3. Agent uses internal APIs for stack traces, variable inspection 4. Breakpoints via software interrupts (limited) Limitations: - No real stepping through machine code - No hardware breakpoints - Only works at Delphi code level, not in system libraries Part 4: Why It’s “Stuck” at Delphi Technical Debt 1. PAServer architecture: Built for iOS 7–16, based on the old lockdownd protocols 2. LLDB integration: Relied on undocumented APIs that Apple removed 3. No VM: Delphi has no interpreter layer that could serve as a debug target Business Reality - Delphi iOS is a niche product compared to Flutter (millions of developers) - Flutter is funded by Google with hundreds of full-time developers - Embarcadero has limited resources and must prioritize Part 5: Realistic Expectations What Embarcadero COULD do in the short term (6–12 months) 1. devicectl integration: PAServer uses xcrun devicectl for install/launch 2. Xcode-proxy debugging: IDE launches Xcode in the background and uses its debugger 3. Improved logging tools: Stream console output directly into the IDE What is NOT realistic - Full source-level debugging without Xcode - Hot Reload like Flutter (requires a VM) - Debugging without a Mac running Xcode Conclusion The harsh truth: Delphi’s greatest strength (native code without a VM) is simultaneously its iOS 17 problem. Apple blocked the only debug path that purely native third-party tools could use. Flutter and MAUI were never affected by this blockade because they were designed from the start with a different architecture—an embedded VM that can be debugged over ordinary network sockets. For Embarcadero there is no easy way to copy the Flutter model without either: - Developing a complete Object Pascal interpreter, or - Fully relying on Xcode as the debug backend Both options require massive investment and architectural changes.

Additionally to that, I think it is a good idea to handle save/load very carefully. If possible try to implement some measures to detect if a stored file is corrupted, or not, before blindly re-loading it. At least try to catch any possible exceptions and in that case try to reset everything to default values, otherwise your app might not be able to get started anymore.

I always wondered, why this is not already there. Are there technical or historical reasons? I would even go further by extending the namespaces uses System.Classes , My.Module // Refered the usual way , MyOther.Module , ./Core/My.Core.Module // Refers sub-folders like Core , ./Core/MyOther.Core.Module // , Core/My.Core.Module // Refers sub-folders like Core this way too, why not? , Core/MyOther.Core.Module // , ../../Alien/My.Relative.Alien.Module // Refers subrelative folders , ../../Alien/MyOther.Relative.Alien.Module ; Perhaps this causes headaches in certain places, when using them as namespaces .... ( but not that much headache ). type TMyModule = My.Module.TMyModule; // Refered the usual way TMyOtherModule = MyOther.Module.TMyOtherModule; TMyCoreModule = ./Core/My.Core.Module.TMyOtherModule; // Refers sub-folders like Core TMyOtherCoreModule = ./Core/MyOther.Core.Module.TMyOtherCoreModule; // TMyCoreModule2 = Core/My.Core.Module.TMyOtherCoreModule; // Refers sub-folders like Core this way too, why not? TMyOtherCoreModule2 = Core/MyOther.Core.Module.TMyOtherCoreModule; // TMyAlienModule = ../../Alien/My.Relative.Alien.Module.TMyOtherAlienModule; // Refers subrelative folders TMyOtherAlienModule = ../../Alien/MyOther.Relative.Alien.Module.TMyOtherAlienModule; ;

Well, your support for Delphi helped a lot to push Delphi back to 8th position in the TIOBE Index https://www.tiobe.com/tiobe-index/ TIOBE is, of course, a questionable index, but it's always nice to see such an increase, which was achieved through incredibly expensive marketing measures Thanks for helping with that too.

That is correct: https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread.Queue I assume if somebody asks to "Queue" something, he would intrinsically expect that this might not naturally be synchronously. Maybe its just me, always trying to think as simple as possible, the world is complex enough

Right, but if you don't know or cannot for 100% ensure that you ALWAYS will be called from within the background thread, then ForceQueue is a little safer than Queue, because it doesn't care.

Very interesting. I currently have looked just last week into a similar or same approach that is used in the TP-Link TAPO devices. https://github.com/ClementNerma/tapo-rest I think this is what you are going to implement, right? Tapo does it by resources /handshake1 and /handshake2, to get access. I wonder if this SCRAM-MCF process is a kind of standarized process, or not. Because what Tapo is doing looks very much proprietary to me, but it seems to follow similar ideas.

Right, that is the fast solution, to keep everything as-is https://developer.android.com/reference/android/R.attr#windowOptOutEdgeToEdgeEnforcement I was sure that this option is deprecated in Android 16, but I havent found this again. This is the only note I've got there at the moment https://medium.com/@mickcolai/from-android-14-to-15-a-practical-guide-to-adapting-the-legacy-view-system-for-edge-to-edge-a0232d7aea30 So probably this is only a temporary solution.

There was an older post already https://en.delphipraxis.net/topic/10373-unable-to-cast-uint64-to-double-on-32bit-compile-in-windows-11-arm-has-anyone-experienced-this/ So this is an older problem.

As a side note: In such cases I prefer TThread.ForceQueue(nil, ...), in cases where it is not 100% sure, that calling this part from background or main UI thread, and could be both possible threads somehow. With that ForceQueue you are always on the safe side.

That would be my first guess too. When using this on the Form or Frame level, those commands should be notified through all child components on that form as well: https://docwiki.embarcadero.com/Libraries/Sydney/en/FMX.Forms.TCommonCustomForm.BeginUpdate

Maybe its worth noting that there are also major differences, depending on the order of except/finally, which make the separate, existing try try version more reasonable and clear to me. Of coarse a new tr-except-only with more robust, or B.) like behaviour, would make things clearer too, but on the cost of flexibility. Order: A handles first and then cleans up; B cleans up first and then handles. That is the key difference. Resource lifetime: In A, resources are still available during handling (DoExcept); in B, they have already been released at this point. For logging/error messages, B is usually more robust because cleanup is guaranteed to happen beforehand. :Errors in DoFinally In B, errors in the cleanup code can be caught by the outer except; in A, they cannot. Rethrow behavior: If DoExcept in A throws a raise; or a new exception, DoFinally still runs afterwards. In B, DoFinally has already run before DoExcept even starts. //A.) try try DoSomething; except DoExcept; end; finally DoFinally; end; //B.)" try try DoSomething; finally DoFinally; end; except DoExcept; end;

I find these warnings handy for looking from time to time if something has changed or where you might have a 2nd or 3rd look at it. In a strongly typed language, I see these hard cast overrides always a bit problematic, which are not in the original "Pascal sense" and a kind of cause for possible future errors outside of the compilers scope. Thats why I do like them as a kindly reminder, but in basic IDE units or 3rd party libraries I would not like to see them at all, because its not my code and hard to interpret their meaning. At least it would be worth to leave it with a comment: "I did this on purpose", best of all explaining the reason why exactly.