Leaderboard

Executor is one of my favorite projects started in 2007 and now over the summer I did a version 2 of it (Free on MIT license). If you remember old programs like Slickrun and Launchy it was originally a bit of a "techy" alternative to these, that besides launching things can also do clipboard stuff, manage active windows, manage running apps, text manipulation, a lot of hotkey trickery, built-in calculator etc. I develop in a bunch of languages, but I really love to develop in Delphi. It's where I can get idea to something working in the least amount of time, and the project compiles in 2 seconds, where if I'm sitting in Android Studio or Xcode I can fetch a new drink while waiting for the compiler. The project is using Delphi VCL. Originally Executor supported Windows all the way back to Windows XP. Which put quite some restraints on the development side. That minimum requirement was bumped up to Windows 7, also supporting both 64bit and 32bit, adding High DPI support as well. High DPI was a bit of a challange as Executor over those many years have had several skinning systems, some supporting borderless full alphablending on the main form with overlay full alpha blending images. These of course don't look pretty if trying to stretch a full alphablending image to 250% desktop scaling, and the author of the skin might not be active anymore, so you can't expect it to be updated with several resolution of the image assets (TVirtualImage, TVirtualImageList). Because of the skinning support and a lot of visual customization options, there's also a lot of paint events, ownerdrawing, hooking into WM_PAINT, WM_ERASEBKGND, WM_MOVE, CN_DrawItem etc. So I'm not using VCL styles, I tried a couple of times to use VCL styles, as it it would be nice to use for my settings form for dark mode etc. But with my limited experiments it was hard to isolate the VCL styles to only effect specific forms (the settings form and some other trivial forms), and it would then introduce a lot of side effects on the main form, where I'm doing a lot of custom visual stuff, seeming to collide with my code for this. Also in general I'm trying to not be depended on thrid party components and technologies, also caring about system footprint (cpu,gpu,mem,io etc). Some other nice challanges has been the 32bit and 64bit versions of Windows, as Executor can scan folders like the start-menu and other system folders, these are off-limit if not matching bitwise, and also various security restrictions was gradually added with each new version of Windows. Then scanning for UWP apps was another additional challange, as UWP seems like a bit of a "clunky add-on" that changed quite a bit in each version of Windows in terms of Windows API. Cheers and happy programming, Martin Website: https://executor.dk YouTube video:

Hi All I have released a new YAML Parser/Emitter library for Delphi XE2 or later. It is pure delphi code, tested with Win32 and Win64 but it should work for other platforms too (no winapi dependencies). Supports YAML 1.1 (partially) & 1.2 JSONPath queries with filter expressions Multiple Document streams. https://github.com/VSoftTechnologies/VSoft.YAML

I read this blog post: https://blog.dummzeuch.de/2024/06/04/an-improved-abstract-error-handler-for-delphi/ and noticed I had something similar, but noticed that Delphi since some recent version introduced a function ReturnAddress that is generally available, it doesn't even have code in System.pas so I suspect it's something the compiler introduces. I also notice older Delphi versions don't have this yet so I'm not sure at what version this got introduced. Does anybody know or can check? (Also I guess using ReturnAddress would future-proof your code in case the [ebp+...] offset changes again, and also should be available on other processortypes?)

Yes, we used option C which worked well. If I remember correct we were on Fusion at the time, later switched to Parallels when we moved over to MacBook Pro M1's. At the same time we stopped using the iOS simulator due to lack of support for some third-party libraries. We're now only debugging on real iOS devices.

Good discussions are worth repeating 🙂

With a few missing TFormatSettings fix - it now works on different locales - and is tested on Linux (2 tests failing due to file path issues in the tests). It should work on OSX and mobile but I haven't tested that.

Most front cameras support fixed (TFocusMode.Locked) only. One way (likely the easiest) to resolve this would be to use a patched FMX.Media.Android unit. Copy the unit to the project folder and change this routine: procedure TAndroidVideoCaptureDevice.SetFocusMode(const AFocusMode: TFocusMode); var Params: JCamera_Parameters; // Patch code vars: LFocusModes: JList; LFocusMode: JString; I: Integer; LIsSupported: Boolean; begin Params := Camera.getParameters; if Params = nil then Exit; // Patch code BEGIN LIsSupported := False; LFocusModes := Params.getSupportedFocusModes; for I := 0 to LFocusModes.size - 1 do begin LFocusMode := TJString.Wrap(LFocusModes.get(I)); if ((AFocusMode = TFocusMode.AutoFocus) and LFocusMode.equals(TJCamera_Parameters.JavaClass.FOCUS_MODE_AUTO)) or ((AFocusMode = TFocusMode.Locked) and LFocusMode.equals(TJCamera_Parameters.JavaClass.FOCUS_MODE_FIXED)) or ((AFocusMode = TFocusMode.ContinuousAutoFocus) and LFocusMode.equals(TJCamera_Parameters.JavaClass.FOCUS_MODE_CONTINUOUS_PICTURE)) then begin LIsSupported := True; Break; end; end; if not LIsSupported then Exit; // Patch code END FFocusMode.Value := AFocusMode; UpdateFocusModeParameter(Params); Camera.setParameters(Params); SetAutoFocus; end; This means that if the mode is not supported, it doesn't try and change it, so it will remain either the default, or the last supported mode it was set to.