One of the common problems we programmers face (and hopefully we are aware of) are memory leaks, or leaks of any other kind of resources. For example, Windows limit the number of GDI or USER32 objects that a process can allocate at one time. When things go down the wrong road you would want to have the tools to help you find (again) the correct path to free-what-you-create.
In a Delphi application, the THintWindow class implements the small pop-up window that appears over a control at run time, when the control has its ShowHint property set to True (and has a value assigned to the Hint property).
The implementation of the THintWindow (at least what gets displayed by it, not how) is rather simple: it will display whatever string value is assigned for the Hint property of a control. If you want more control over what gets displayed by the hint window, and how, and when the hint window will popup – you can create your own version by extending the THintWindow class.
To use your own hint you would assign your own class to the global HintWindowClass variable at application start-up time, so that the new hint window type is used for hints. You can even fine tune the display of the hint window just before it pops-up using the OnHint and OnShowHint events of the TApplicationEvents.
That’s all nice and clear. But, what if the control you are using is Virtual Treeview which has its own version of the hint window implemented in TVirtualTreeHintWindow? What if you want to extend this by including some graphics along with the text that the hint window displays? Further, what if you need to have different hint values for every node displayed by the tree?
Of course, you are not working on a new application – all logic is already there, lots of methods and events already implemented.
The answers: here’s how to simply extend both the TVirtualTreeHintWindow and the TVirtualStringTree to add some node specific graphics to the hint window displaying node specific hints.
I guess you might not know what the term “dangling pointer” means, but if you have ever done some more complex programming in Delphi (where you do not only put controls on a form and handle a few events – rather you create and use objects at run-time) you might have experienced weird Access Violations when you tried accessing properties of an object you though is “Assigned” (or not nil).