PeterBelow

Perhaps you can use the Screen.OnActiveFormChange event for this. But keep in mind that it is not only called when a new form is shown but also when focus changes between forms. It may also happen too late for your purpose.

Good to know one can learn something new even at my age :)...

If you want to be able to edit this new property in the IDE Object Inspector I don't see a way to do this since it would require not only a change of the source code of the TComponent class but also a rebuild of all design and run-time packages that use TComponent, and you do not have the source code for all of them, as far as I know. If using this property in code would be enough there may be a way to fake it using a class helper for TComponent that uses the existing Tag property to store an index of the actual string held in some global container, like a TStringlist.

Depends on how you store the loaded names. If these are records from a database, for instance, and you access them via a query or table component each result row will have its own memory, regardless of what it contains. With a query you have the option of removing duplicates in the SQL statement used, but only if the row does not have any other columns with non-duplicate content. If you load the names into a TStringlist you can set the list's Duplicates property to dupIgnore, it will then discard values already in the list when you try to add them.

You have to use OnKeyPress and check for Ctrl down there. The behaviour you see is perfectly OK, by the way. Ctrl-<letter> combos have created control characters since the ancient days of DOS, and ^I (#9) is the TAB character...

The debugger will show exceptions before they are trapped in try except blocks in the code. The dialog you got allows you to tell it to not show this particular exception type in the future. To re-enable it you have to go into the IDE options dialog (Tools -> Options). Under the "Debugger" node you find (under "Embarcadero Debuggers") two lists with the exception classes to ignore. Just uncheck the one you blocked. Note that the dialog may look a little different if you use a Delphi version older than 12.

No, since it is not a user-triggered change from the combobox's view.

You would have to draw cell content yourself (OnDrawCell event) to achieve that, but in my opinion such behaviour is a horrible idea in the first place. It would give a very uneven grid appearance and you will also have the problem that larger font sizes than the grid default will also require a bigger row hight to avoid text cut off at the bottom. Either adjust the column width or (more difficult) implement word wrap for cells with longer text. That also requires drawing the cell yourself and adjusting the row hight, which is tricky since it will trigger a redraw of the row and thus fire OnDrawCell again. An alternative is to use the grid with reasonable default font size and column autofit and place a panel or frame with individual edit and memo fields below it. Clicking on a grid row shows the content of the row in the individual controls of the panel, the content of which the user can scroll if required.

The "buttons" in such a group are of class TGrpButtonItem and that class does not seem to offer a way to adjust the alignment. But the TButtonGroup itself has a number of events you can handle to draw the buttons yourself, like OnDrawButton. Better study the source to see how the buttons are drawn by default to see how you can modify that.

The IDE is 32 bits. The 64 bit compiler is a separate executable, which is why it can only be used if you compile via MSBuild. It is intended for use on build servers as I understand it, not while you're working in the IDE.

Well, what do you want to achieve here? Look at the source code for TControl, from which TPanel inherits the Caption property and its SetText and GetText accessor methods. procedure TControl.SetTextBuf(Buffer: PChar); begin Perform(WM_SETTEXT, 0, Buffer); Perform(CM_TEXTCHANGED, 0, 0); end; Setting a control's Caption or Text properties ends up sending messages to the control. WM_SETTEXT stores the passed string and CM_TEXTCHANGED is a notification for the control that the caption or content has changed, which typically makes the control redraw itself. TCustomPanel, the immediate ancestor of TPanel, has a private message handler procedure CMTextChanged(var Message: TMessage); message CM_TEXTCHANGED; that just calls Invalidate to redraw the panel. If you want to react to a change of the panel Caption you have to add a handler for this message to your modified TPanel class. You cannot override the parent method since it is not virtual or dynamic and also private. But you can call the inherited message handler inside your handler using the inherited keyword. If you just want a panel that does not show the Caption: it has a ShowCaption property that you can set to false to achieve that. You could set that in an overridden Loaded method.

Interbase is a SQL database. The book you are using seems to be very old, probably written for an ancient Delphi version like Delphi 7, which used the Borland Database Engine (BDE) for database access and the Database Desktop app for managing the database. This is about 20 years out of date; the BDE has not been offficially supported for more than a decade and it and its tools are difficult to install and get to work on Windows 10 or 11. If you want to learn to program in Delphi get the free Delphi Community edition. It comes with a modern version of Interbase and allows you to build application using a local database. The IDE has an integrated database view that can be used for simple database management, but the Interbase installation has its own toolset, like ISQL, which you can use to execute DDL (Database Definition Language) scripts to manage the database.

Interfaces can only have methods, not fields. Your Thing property needs a GetThing method as read accessor and the implemention can then refer to the FThing field of the class implementing the interface. Interfaces also imply lifetime management by reference counting (that comes from their original purpose in Delphi to work with COM). All classes derived from TInterfacedObject have the necessary infrastructure build in, but beware: classes derived from TComponent inherit an implementation of the relevant methods (_AddRef and _Release) that is not reference-counted, since the lifetime of components is controlled by their Owner. So do never store an interface reference obtained from a component in a field/variable that may outlive the component itself, that is a sure way to produce access violations when the compiler-generated code tries to finalize said reference when the field/variable goes out of scope!

In the OnPostError handler you have to store the error code (E.Errorcode) or the class of the exception passed to the handler (E.Classtype) into a field of the datamodule. Since you told the handler to abort the operation the exception you trap in the try except block will always reflect that, but you can examine the value stored by the handler to figure out what went wrong. But be careful, it is not a good idea to execute code from an except block that may trigger another exception. Just set a flag, that indicates the action to take and act on that after the try except block. Oh, by the way, do not store the E parameter's reference in the handler, that may become invalid after the handler returns since it probably destroys the exception object...

That is not relevant for Unicode UTF-16, which is what the String type uses in all Delphi releases since more than a decade. Who relies an ANSI/MBCS strings these days anymore? Windows has used Unicode internally for ages...

If you look at the VCL source (if you have it) in the design the VCL follows each component having an event also has a virtual or dynamic method, usually protected, that fires the event. This method can be overridden in descendants to change the way the component handles the event. So, in your case, you would implement such a method to provide the default processing and optionally to also fire an associated event, if a handler has been assigned to it.

Have you tried to explicitely set the OS compatibility of the affected bds.exe to Windows 7? I don't have Win11 installed yet but it should have this option like Win10 and older Windowses in the EXE properties dialog.

Try to not use anchors but set the new panel's Align to alTop instead. If you want vertical spacing set the panel's AlignWithMargin property to true and set its Margin.Bottom to the spacing you want and all other Margin members to 0.

Have you tried using scrollbox.clientwidth instead of scrollbox.width?

You don't. Use a TPaintbox as a drawing surface, it has a Canvas and an OnClick event. TImage is another candidate, it contains (by default) a bitmap you can draw on using the image component's Canvas, and it also has an OnClick event. As explained in other replies a TCanvas is just a wrapper for a window's device context, it cannot receive mouse events directly.

Moving from D7 to Delphi 12 (Athens) is a very big jump. If you can build the old codebase at least you don't have to worry about old 3rd-party components, but there have been a lot of changes on the way, the most important one perhaps the move from ANSI to Unicode (UTF16) characters. Sizeof(char) = sizeof(byte) = 1 is no longer true, and that hits hard if the old code misused string variables for storing binary data. Incrementing a pointer of type PChar will now increment it by 2, not by 1, and that can easily cause old code to overwrite memory, which may be at the root of your problem. It may work for debugging just due to a different stack layout caused by different options, e.g. for using stack frames. A stack overwrite can corrupt a return address and that may lead to the exception you see. As recommended in other replies using a tool like MadExcept may be the best way to nail down the problem location, but if it is indeed a stack corruption the actual cause may be far from the location where it finally manifests. In this case doing an in-depth code review may be a better option, since there are likely more of these problematic code bits in your project.

Do you know that you can supply up to four images in the bitmap you use for the Glyph property? See here for what they are used for. If your bitmap only contains one glyph image the control will synthesize the disabled image from it and the results are often not that good.

The old translation tool has been deprecated for a couple of versions already and was removed from D12 completely. Check if it is still available as add-on via GetIt, the IDE seems to still use it. It was probably dropped finally since it's Windows only and i'm not sure if it ever worked for FMX projects even there.

May be a problem in the dproj file, the IDE has never been very good in converting that from a previous Delphi version. Make a backup of the project's dproj file, delete it, and then open the project's dpr file. That will create a new dproj file without any garbage from the previous version. You may have to adjust the project options, though.

I think all you have to is to define the events with published scope and then register the property editor for that event handler type.