The Road to Delphi

Delphi – Free Pascal – Oxygene

Avoiding the memory leak caused by the Delphi intellimouse support


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.


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;

Author: Rodrigo

Just another Delphi guy.

8 thoughts on “Avoiding the memory leak caused by the Delphi intellimouse support

  1. Pingback: Avoiding the memory leak caused by the delphi intellimouse support

  2. 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”.

  3. Thanks for the tip. Any reason for the Assigned check however? Surely just setting the property to nil would do…?

  4. 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).


    • 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”

  5. @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).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s