Delphi’s TGridPanel control is an ideal pick when you want to create grid-flow like user interface layout for your controls.
To place controls on a grid panel you specify the number of rows and columns (RowCollection and ColumnCollection properties) and simply drop a control on it. Unlike standard TPanel, when you drop a control on a GridPanel it will be placed in the next available empty cell in the grid. As you add more controls the grid will grow either by rows or columns being added automagically (or not, if the ExpandStyle poroperty is set to emFixedSize). What’s more you can even determine how each cell will be sized: will it have a fixed size, or a percentage of the grid size – so you can have controls nicely uniformly distributed in a grid.
That’s all great when you know the design at design-time – and you know what number of controls you want to be hosted by the grid panel.
The second law of thermodynamics, in short version and when read by a programmer, states that “any collection of objects tends not to be sorted” 🙂
We developers, we have a tendency of organizing objects into lists, collections, queues, stacks …
Since you’ll be using the for loop to iterate over elements – why not sort the elements first. What’s more, a sorted list is easier (read: faster) to be searched upon.
In one of my applications, a tab on the page control hosts a TWebBrowser displaying PDF (and other supported) documents. Having the “PDF View” tab active, other tabs of the page control are hidden from the user – as this is how the page control functions.
One users asked: “Can we undock this tab so that it floats and then activate other tabs on the page control? We would also want to dock the viewer tab back. Further, we have two monitors and would like to move the floating viewer to the second monitor.”
I’m sure you’ve seen it already. When the program starts it takes a picture of the current desktop, the picture is then cut into a number of rectangular pieces (all of the same size). A piece at some random position is “removed”. The main code randomly swaps that piece with the one next to it. Only pieces adjacent to the removed one can be moved into it.
Looking for the best approach to change the background color (and other properties) of the focused data entry control in a Delphi (VCL) application?
By (Windows) design, the control on a data entry form which has the input focus is not drawn (/highlighted) differently from other controls (i.e. those without the input focus). In case of the TEdit (or TMemo and alike) control, only the blinking insertion point is displayed.
To provide visually more attractive user-friendly interfaces for your Delphi applications, you could decide to change the background color (and maybe some other properties) of the currently selected control – the one that has the input focus. Of course, this would include restoring to the original background color when the focus shifts to another control.
Here’s a small Delphi program I wrote some 20+ years ago. As far as I can remember this was one of my first (maybe even the first one really) Delphi applications which would not fall into the “hello world” category. Back then I was quite impressed how easy was to call Windows API functions directly from Delphi code to create small but powerful (and hopefully not useless) programs. The original code (I think days of Delphi 2 or 3), as the case is with Delphi, compiles without too much editing even today in RAD Studio 10.X.
If you are familiar with the application called “Magnifier” (comes with Windows as a part of Ease of Access features) then you already know its desired purpose: it displays zoomed in portion of the screen. Now, Magnifier has 3 modes: full screen, lens and docked. What is missing in Magnifier (even today with Windows 10) is the ability to enlarge the part of the screen that is below the mouse and display in a separate freely positioned window.
Finally, last step in making my (/your) Delphi application not only high-dpi aware but also high dpi button-glyph-display-size-as-expected-ware. In my last post I’ve shared how to programmatically upsize images in TImageList so that menus, popups, toolbars and other controls using image lists appear more appealing on high dpi displays. This time I’m dealing with button images, more precisely programmatically upsizing the bitmap set for the Glyph property.
So, you’ve made your Delphi application high-DPI aware and after a few manual fixes the UI looks more or less usable on 4K displays having logical DPI values set to more than 100% (96 DPI). However, you open up the application’s main menu (or any popup menu) set to display images from an image list – and your fancy images appear super small (or are not drawn at all when you move your mouse over items)? The same small images appear on toolbars? You then note buttons having their Glyph property set to display some 16×16 pixels graphics – caption font is ok, but the glyph is also barely visible. Now what? How to have those images at the correct size for the applied DPI scaling?
So you want to go down the high-DPI road? Feeling alone? I did 🙂 The classical answer “it works on my machine” will not be sufficient here. Your non high-dpi aware Delphi application might look nice on your development machine, but it certainly looks super small or ugly stretched on your client’s shiny new 4K resolution laptop – and it really does not work – at least not how you and your client would expect!
Woohoo! After a few weeks of struggle I’ve finally high-dpi enabled my used-across-the-globe Delphi application.
It was not a too hard job – it just took a lot of time and experimenting (read: fixing) how the UI of the application appears on various 4K displays having various settings for “Make text and other items larger or smaller” (Windows Vista/7/8), which is the same as “Set a custom scaling level” (Windows 10).