Leaderboard

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

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:

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.

You didn't account for any font scaling. So if the user has a high dpi screen and a font scaling larger than 100% the your 26 and 8 won't be right. Then again, because you didn't provide full code and details we are all guessing a bit.

It is always a good idea to not hard code any widths related to the visual apsects of controls. They might change when the OS changes version. You have to get the width of the non-client area of a ComboBox so that you can add it your calculated MaxTextWidth to get a proper control width. But... ComboBox does not play nicely and getting its ClientWidth is not possible with functions like GetClientRect thus ComboBox does not have a properly calculated ClientWidth for it so you will have to make another plan to get it. There is a Win32 function called GetComboBoxInfo. It returns a record with details about the combobox like size of the control, the size and position of the button and size of position of the edit control in it. You will use the width of the edit control and deduct that from the width of the ComboBox and there you have the non-client area width. Just add that to the MaxTextWidth and you have the size the ComboBox should be. Remember to do these calculations and setting of the ComboBox size again when the Windows theme or settings change or the font changes.