As the Help states, The TStatusBar Delphi control displays a row of panels, usually aligned at the bottom of a form. Each panel is represented by a TStatusPanel object listed in the Panels property.
Much like any other VCL control, the TStatusBar can be adopted and extended to offer greater functionality. A simple case would be to use the status bar to display long hints from other controls.
What does not come out of the box is the possibility to have each panel on a status bar display its own hint (tooltip) when the mouse “stops” over a panel.
Even though the TStatusBar provides the Hint and ShowHint properties to let you assign the tooltip text which appears when the user moves the mouse over the control – you cannot have each panel on a status bar have its own specific hint!
You cannot? You can! Here’s how to implement TStatusPanel.Hint for each panel on a status bar…
Tab set controls are commonly used to display tabbed pages within a dialog box.
The TTabControl control can be used to add a control with multiple tab settings to a form. The TTabSet control presents horizontal tabs users can click to initiate actions.
Both TTabSet and TTabControl are a single object (not made up of several pages hosting different controls, like the case is with TPageControl). When the current tab changes, the tab control must directly update its contents to reflect the change in an OnChange event handler.
To have a set of tabs for the tab set control you specify a list of strings as the value of the Tabs property. Ever wondered how to have specific hint for each tab?
Say you are developing a game like Chess, Go, Checkers, Tic-Tac-Toe or Memory. In each of those games the game board is a rectangle looking playfield of different size (rows x columns). Tic-Tac-Toe is 3×3, Checkers is 8×8, while Go can be 19×19 or 13×13 and similar.
In a game with an arbitrary number of game fields you might want to have the board look as closely to square as possible (rectangle where height and width are the same). Think of Memory. Let’s say we have 24 cards, that is 12 pairs. If you want to place them in a rectangular grid, most similar to square, you would go for 4 x 6 (or 6 x 4) board size (as it would look more square like than 3 x 8 and 2 x 12 or 1 x 24 would be too wide).
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.