Since the Delphi 2006 version, you can activate the full mouse wheel support (Intellimouse) by adding to the Uses statement the IMouse unit. for example to activate the Intellimouse support to a TMemo component you must set the ScrollBars property to ssHorizontal, ssVertical or ssBoth and add the IMouse unit to your project.
and the result will look like this.
So far all will work ok, but if you add the next line to your project, to report the memory leaks.
ReportMemoryLeaksOnShutdown:=True;
you will receive a awful message like this
this is due which in the IMouse unit the Mouse.PanningWindow is never released. to avoid this memory leak you must add these lines to your project in the finalization part of your main unit or in the unit where your declare the IMouse unit.
if Assigned(Mouse.PanningWindow) then
Mouse.PanningWindow := nil;
The Road to Delphi 
Pingback: Avoiding the memory leak caused by the delphi intellimouse support
February 6, 2011 at 3:47 am
It’s the report # 30652 at Quality Central. Closed as “can’t rep”.
You should report this on QC again, providing a demo project, so they can’t mark it as “can’t reproduce”.
February 6, 2011 at 3:10 pm
Alex there is also 50416 report, Which appears closed as well. I don´t know why Embarcadero mark this bug as “Cannot Reproduce”
February 6, 2011 at 1:11 pm
Thanks for the tip. Any reason for the Assigned check however? Surely just setting the property to nil would do…?
February 6, 2011 at 3:04 pm
CR checking using the Assigned function is just for safety.
February 7, 2011 at 10:30 pm
How is it “for safety” ?
If it’s already NIL then setting it NIL will be a NO-OP, surely ? (confirmed, using that “not needed by a starter, not useful for any pro” user technique of reading the VCL source).
Also I wonder why go to the bother of a unit finalization section (which also demands an initialization section, even just an empty one, to make legal). Why not simply set Mouse.PanningWindow := NIL as the last thing your application project file does ? i.e. even before the finalization chain…. nothing in finalization should cause a PanningWindow to be re-set once cleared at that point.
Of course, if you have the VCL source you can fix this bug for once and for all by simply adding a call to StopPan in the existing finalization section of IMouse (and ensuring that your replacement unit supercedes the pre-compiled VCL unit, obviously).
:)
February 8, 2011 at 2:44 am
Jolyon, first thanks for your comments. Maybe “is for safety” is not the right phrase forgive my limited English . you are right about which only using Mouse.PanningWindow := nil is enough. about using the unit finalization section is just a proposal to the reader, you or anyone can choose another location to dispose the Mouse.PanningWindow.
finally about modify the RTL/VCL Source , personally i prefer another options. just for “safety”
February 8, 2011 at 4:43 pm
@Rodrigo – fix it in the VCL and it is fixed in all your applications. Keep patching your project specific application files and you could forget.
Modifying the VCL source *is* the safe option, imho.
But if you don’t want to fix it in the VCL, I mentioned the easier fix (a final action in the DPR, rather than a finalization section) only as a helpful suggestion for others who might have thought there was something about the technique that *required* a finalization section (and who may have been confused by the use of the phrase “to your project” as meaning the project source [DPR] which of course has no “finalization” section. Such confusion was perhaps only a remote possibility, but I had to read that para twice to be sure of what you meant ,so thought it worth clarifying).
:)