I had a half-working form, when I realized I would have better used a TVirtualStringList instead of the simpler TTreeView. Instead of making a new form, I decided to try right-click "change class" in the form editor, because why not. Of course I did expect things to not work anymore, I rearranged my code to keep the tree data in a record, followed online instructions on how to create nodes, everything looked fine. All the while I commented out some old code and often relied on the compiler to tell me where something is wrong. I finally run it, the tree loads correctly, complete with images, but crashes when I tried to do drag-drop. What I didn't notice at first, the drag-drop related event handlers had different parameters between the two controls, and the old ones were still in use. My bad, but why did it even compile? I would have expected the compiler to complain about the signature mismatch.The LFM file only contains a name of the method to use as event handler, not a signature. The correct signature for the method in your class declaration is only provided by Lazarus' code completion (which you didn't use of course, though I don't know whether Lazarus would update that anyway). The compiler has no clue about the LFM file, from it's point of view it's simply a resource file, nothing more.
I also noticed that usually the empty event procedures created by the IDE have a Sender: TObject argument, but sometimes a specific control instead (TBaseVirtualTree in this case). Out of curiosity, I replaced some TObject elsewhere with the specific class of the control, and it works (plus saves me some "Sender as TWhatever"), of course as long as I only assign that procedure to controls of that same class. Here I wonder, is it ok to do this, or am I looking for trouble?Checking the type of a "generic" argument is good practice, not looking for trouble.
Issue 23032 (https://bugs.freepascal.org/view.php?id=23032).Good to know that it's already reported. :)