Der schöne Günther

Yes, Optimal fill will convert the spaces back to tabs (after the tabs had been converted to spaces 🤪). Strange, but better than nothing. Thanks 😊

I think "Use tab character" and no "cursor through tabs" is correct?

Is it just me, or does 10.4 now forcefully replace my precious tabs with spaces? I don't understand what is happening, and why it's happening 😪

I'm not familiar with Delphi-Mocks so I might be missing something, but I don't understand why you're wiring up your g_Logger.DoOnException to Application.OnException . It will never get called anyway. Either your test case will catch the exception, or DUnitX will catch it. Not sure, but this probably won't even work in a console application either. What you're actually trying to test is if the VCL's Application.OnException event is being called when an exception in the main thread is not caught by anything and goes up all the way to the VCLs outermost exception handler. This should not be a concern of your logging framework. You can test your handler, of course, but not core parts of the RTL/VCL.

Yes, that's the other fun part. Do close the views that give you trouble before you launch your application from the IDE. Because the IDE will, once again, modify (and possibly corrupt) and save these files before it they make their way into your .exe. I think even the "Save modified files" buttons get un-grayed and you can click them. You must switch to a pure .pas source file, and close the other tabs. Then, hit F9. I know this probably sounds very frustrating, especially if you never ran into problems like these for years. If this is just a very special case and you don't want to adapt to a slightly different workflow, I would remove the TCategoryButtons from the form designer altogether and instead place it at runtime, most likely in the constructor of your TFrame.

There is no way around inheritance, and we have also been using the SplitView for years. I am not sure if the VCL components are to blame, or it's some general mechanism that writes the DFM files. We sometimes use very deep hierarchies of inheritance (placing frames in a gridpanel, that frame gets placed on another frame, and this frame gets placed on yet another frame). When the DFM files are clean and minimal, it works like a charm. It's just disappointing that I, so often, have to revert files that were silently modified (sometimes, even corrupted) by the IDE without me doing anything.

Take a look at your DFM file: https://github.com/dcraggs/Splitview-Inheritence/blob/d4e12a1141cd1a0bfb0832777ae59cf5e08b4a49/uSplitViewInherited.dfm#L53-L63 It contains, unnecessarily, a redundant copy of your SV: TSplitView. Even worse, the SplitView contains an even more redundant copy of the TCategoryButtons. And this time it's empty. This is just one of the many(!) problems DFM serialization has with inherited forms and frames. I roughly spend 20% of my time developing Delphi applications with dealing with DFM corruptions like these. Make your DFM file looks something like this: inherited SplitViewInheritedForm: TSplitViewInheritedForm Caption = 'SplitView Inherited Form' end And every time the IDE makes changes to your DFM file, use your version control system to revert these unwanted changes. Maybe you can make the files write protected once they are "done". I don't know if that will help. Another example is that properties like `RowSpan` or `ColSpan` from components stored in a `TGridPanel` always get lost on subclass frames. Or complete ImageLists get duplicated on subclass frames/forms, further increasing the size of your executable.

The person who handled the billing received the last email from Embarcadero in summer 2019. Maybe because we paid for the Update Subscription for several years in advance, it's different? I don't know. The 10.4 beta sounds promising - Is there something like an email address where I could ask what is going wrong here? I received beta invitations a few years ago. I remember XE6, and I think XE8.

Not sure what you need WM_POWERBROADCAST for, but just working with WM_ENDSESSION and WM_QUERYENDSESSION has worked well for several kiosk applications, for several years now.

Well, I never received anything. These mails probably don't go to the EDN accounts of developers, but to whoever in my company handled the billing for the annual update subscription. I am sure that a few years ago, I still received mails for RAD Studio beta programs.

I have no clue about assembler, maybe this is helpful: https://stackoverflow.com/questions/51364707/

This has nothing to do with threads. You're using GetLastError() altough there was no error for you to care about. https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror

It surely affects your machines energy consumption. Even Google fell for that: Once started, Chrome sucked laptop batteries dry, even after all processes had been killed. It stopped after a Windows reboot. Took them years to find out.

Have been running Windows 1909 with Delphi Seattle for months. Just the usual Delphi issues, nothing out of the ordinary. 🤷‍♂️

The easiest way is probably just temporarily deactivating the OnClick event that bugs you when you set it yourself: var notifyEvent: TNotifyEvent; begin notifyEvent := radioGroup.OnClick; try radioGroup.OnClick := nil; radioGroup.Something := Your_Choice; finally radioGroup.OnClick := notifyEvent; end; end;

He told Windows not to tell RAD Studio anything about the "true" DPI. Windows should "lie", pass 96 DPI and then handle the scaling on the operating system level, instead of the application level. Windows did so when using DPI scaling with 125% or 150%, but not with a "custom" 115%.

I should have mentioned we are using the good old GnuGetText / dxGetText for localization. It seems to do some magic to swap out the method for resolving resource strings from System.pas with something else. I can only say that "It just works".

We are using this. Passing a pointer to a ResourceString instead of the (already translated) ResourceStrings allows us to show localized error messages to the user while using English messages when logging the exceptions to disk.

That sounds like your VM lacks proper drivers for hardware accleration.

Possibly related? http://blog.marcocantu.com/blog/2017-june-delphi-packages-creators-update.html

Then he probably has initialised the variable with nil or something else before entering the loop. Because otherwise, you get a compiler warning.

If you're actively exiting the loop, then everything is fine. You're probably talking about compiler warning W1037.

I can't say how you define severe. Of course there is overhead for the 2nd process, but your 1000s of entries should be well possible. I suppose this is also how professional logging solutions like Gurock SmartInspect (also available for Delphi) do this (Link)

So you need to Be able to cope with 1000s of entries per second Do not lose a single entry when the process crashes fatally Since you say it "Debug logging" and you don't need to survive a powerloss: Use a second process. This can casually flush the log entries to disk when a certain threshold is reached and has no problem with your main process crashing.

By itself, TB does not really have much to do with TA. It's just a type definition, it's full type name is TA.TB. Since it's just a type definition and no instance, you could have multiple instances of TB inside your TA instance. You can have TA.TB instances outside of a TA instance. You can have a TA instance with no TA.TB inside at all.