Der schöne Günther

In case anyone wonders, here is the original "study": https://stripe.com/files/reports/the-developer-coefficient.pdf Sure, this PowerPoint has nice colours and everything, but I really don't know what to make of things like (emphasis by me)

I depend on contact lenses. When I don't have them in (at home), I can barely see anything. But then, I can just crank Windows DPI up to 200% and everything is fine on my 27" screen (2560x1440). Normally, I have 125% DPI on that screen. I am, however, not using Delphi at home anymore as it is extremely blurry on 125% DPI. All my other code editors don't have this problem and can instantly switch to higher/lower DPIs with no issues. At 200% DPI, the Delphi IDE should probably look fine, I never tried. What operating systems are you using? Quite some things have improved in the last versions...

This might come across as ignorant, but I never really got behind what DUnitX does better than DUnit. For sure, it does things differently. But better? What are the advantages? Why should I consider migrating all DUnit test projects to DUnitX?

What exactly is your question? You have a window handle (HWND) and you want to get the full path to the executable behind it?

I am working on a legacy project which has it enabled. I did not dare to disable it, so all new units get a compiler directive to switch full bool eval off while you have to be extra careful and always keep in mind that full boolean eval is enabled when editing "old" units. Reason? I suppose there was none and "full Boolean evaluation" sounded better than "mediocre Boolean evaluation"

It was some article that referred to a presentation from the early 90s, that's for sure. We once tried making a small application for iOS & Android, and yes, the application had so many fatal crashes with no way of debugging it that we finally gave up.

Are there more information available about the crashes themselves? And didn't Delphi get famous by demonstrating how an unhandled access violation would just produce a messagebox and continued to work afterwards instead of bringing the whole app down?

The TStringHelper was designed for immutable strings. If I'm not mistaken, Strings on platforms such as iOS are immutable whereas they are still "copy on write" on Windows. All the TStringHelper methods return a new string instance.

Why would you consider it bad? The arguments are evaluated before calling SetLength(..), so Length(..) returns the length before it was resized High(someArray) is a simple lookup, the size is known

Absolutely. Interesting and entertaining to read. Please, more of those.

I always found using System.Classes.TBits easier to use than raw bit operations... if myValue.Bits[3] then (...)

Can't you just provide a simple test case with code that actually compiles, your input and your expected result?

(I am not sure if this should go to Off-Topic.) I am not sure Embarcadero intended this - The new DocWiki template for Rio has nice colours that look less depressing, but they've really overexaggerated the borders padding. Please take a look at the attached pictures for comparison. What would be the best place at Embarcadero to ask about this?

Exactly. For regular user applications, you hopefully have a global exception handler that turns an exception object into something readable for the end user. Translating computer speech to text that is shown on screen does not belong into the backend code for handling license data and whatnot.

But I don't understand - Isn't that just destructive? It throws away the additional information the default exception dialog would have shown you. It displays a generic message which is not helpful. A simple doSomething() is just better.

That's not harmful, it's just unnecessary code. What really rustles my jimmies is something like this: try doSomething(); except ShowMessage('There was an error'); end;

This is just an idea, maybe it matters whether the executable is being debugged, started from IDE or started from explorer? Maybe it inherits some settings from its parent process (the IDE).

Interesting option, I never knew. Anyways, I suppose this should only affect applications from Delphi environments that are over a decade old?

That's usually how I can spot if an application has been made with Delphi - They forgot to make dialogs close with [Esc] or the tab ordering is completely random 🙃

The IDE offers to relocate a class to another unit by right-clicking under "Refactoring" but - surprise! - it never works. Does MMX have this feature? I see it has elaborate ways to add to an existing class or even move things around within the class declaration. But so far, I have not been able to find anything that allows me to move a class (declaration and implementation) to another unit. Is that correct?

Just tried it out, thank you so much 😍

Do you have plans for incorporating the "real" thing as this would be possible with "XAML Islands" [1] [2] or will you stick with mimicking? [1] https://docs.microsoft.com/windows/uwp/xaml-platform/xaml-host-controls#uwp-xaml-hosting-api [2] https://github.com/Microsoft/Windows-appsample-Xaml-Hosting

Hard to imagine, given that the result of TRestClient.Create(..) is not known at compile-time. This would not be a "const", but a readonly variable. Maybe one day Delphi will also have that?

I believe the modifiers are lost when translating a hotkey to a string: Raw hotkey value = 0x0646 ShortCutToText() = F TextToShortCut() = 0x0046 program Project1; uses System.SysUtils, Vcl.Menus, Winapi.Windows, Winapi.CommCtrl; procedure p(); const VK_F = $46; HOTKEYF_CTRL_ALT = (HOTKEYF_CONTROL or HOTKEYF_ALT); // Ctrl+Alt+F var hotkey: Word; asText: String; begin hotkey := VK_F or (HOTKEYF_CTRL_ALT shl 8); WriteLn('Raw hotkey value = 0x', IntToHex(hotkey, 4)); asText := ShortCutToText(hotkey); WriteLn('ShortCutToText() = ', asText); hotkey := TextToShortCut(asText); WriteLn('TextToShortCut() = 0x', IntToHex(hotkey, 4)); end; begin p(); ReadLn; end.

Moreover, your "SLI" record that appears to wrap IShellLink fails to check the return value of SetHotkey