Posts Tagged ‘programming’

ImageList and .NET leaks

Wednesday, April 14th, 2010

Even with garbage-collected managed memory systems like those found in C#/.NET applications still suffer from leaks.

Most of the time, the “leak” is an object that has a reference to it being held by a static object. These can be a pain to identify, and near impossible in a large application without the aid of additional memory tracking tools. SciTech’s .NET Memory Profiler software is such a tool, and has proven itself invaluable in detecting these problems.

It surprises me how often leaks come back to (mis)use of the innocent looking ImageList object. For example, I have an ImageList object that contains a set of icons for different document types, and use it for ListViews, TreeViews, and anywhere else in the UI where I’m presenting collections of documents. It’s all too easy to set the image list:

myListView.SmallImageList = MyApp.DocumentIcons;

…then assume that when this particular UI goes away, all the contents go away too.

Under the surface, pointing a ListView control at an ImageList also causes the ImageList to store a reference back to the ListView. This way, if an icon is modified in the ImageList, all the ListViews and other controls that are using it can be updated too. The downside is when you forget to reset the SmallImageList property in the ListView control when the control containing the ListView is being disposed. Because the ImageList refers to the ListView, the ListView won’t go away. The ListView refers to the parent UI, the parent UI refers to the document, the document refers to the data, and so on. So when we set our document reference to null, while we might expect the whole lot to be disposed, they continue to persist in memory,  accessible only through the ImageList object.

SciTech’s tool allows me to take snapshots before and after opening and closing a document or particular UI, and compare them to see what objects have been created but not freed. I’ve been using it for a few days and have already found a couple of commonly used UserControls in a UI-heavy application that weren’t being disposed of correctly.

Netbeans 6

Saturday, August 9th, 2008

So I’m converting a C# app to Java and I’ve decided to use Netbeans as my editor. It’s been a while since I played with Netbeans, and last time I played with it, I didn’t really do anything major with it. Now I’ve got version 6.1 installed and this time I’m giving it a bit of a workout.

On the whole, I’m liking it. I started by creating a test application with a swing based window and OpenGL rendering, which forms the basis of what I’m aiming to do with it. Getting the OpenGL bindings – jogl – installed and linking was half google and half trial-and-error. It also took a little research to get the Java API docs downloaded and recognized by the IDE, but they’re there now.

Programming in Java is not something I’m terribly used to. I worked on J2ME programming for cell phones a few years ago, which seems worlds away from write J2SE apps for a desktop computer. The cell phones we were targetting at the time had so little space for the jar files that we had to think twice before creating a new class because of the additional jar space it would require. Oh, and I have floating-point arithmetic now, which is nice.

I’m starting with an almost line for line conversion of the C# app, which means cutting and pasting the code into Netbeans, then massaging it until all the red underlines disappear. A lot of this is pretty mindless (good for me!), e.g. a C# property Value { get; set } turns into a Java getValue() and setValue(). Netbeans feels sluggish compared to MS Developer Studio, but Netbeans also points out compile errors as you’re writing, rather than discover them at compile time. The Netbeans auto-completion functionality seems a bit too intrusive. Often I’m coming to a jarring halt in mid flow because it’s auto-completed something I wasn’t expecting and it takes a second or two to make sure I’m not ending with doubled code. It’s probably configurable, and seems intrusive because I’m not used to it.

One of the major changes to the app is the windows interface. The original is all built in C#/.NET Framework 2.0, and I’m re-implementing this using the swing toolset. This is where we come to Netbeans’ GUI designer.

Oh my life.

Initially, I thought it was pretty cool. Placement of controls within the window seemed pretty easy and the guides snapping controls into positions with reasonable borders and spacing seems superior to the GUI designer in Developer Studio. Great, I thought, this is going to take no time at all. Famous last works.

As the window contents became more complicated, strange things began to happen. I’d have five buttons in a row and go to add a sixth. When I try to position the sixth, a couple of the other five pop down the window by some random quantity, stretching the container. I try to push them back into position, but one won’t go. Every time I try to reposition it, it pops down by a bit more, again stretching the window.

When I was first using Microsoft’s gui designer, I found it to be an exercise in frustration, mainly because I didn’t fully understand the docking and anchoring mechansisms, and control orders, and being stuck with the old 1.1 .NET Framework and DevStudio 2003. The 2005 editor is much improved, and understanding how the window system works helps a great deal. I’m hoping there’s a similar trick to the Netbeans system, that some day it will suddenly make sense!

Maybe I need to rely more on frames – keep a minimum of controls within a frame, and use many frames to build the whole window.

Maybe I need to play around with the layout manager a bit more. I think that’s what it’s called. Seems to responsible for how controls are laid out within a container. There’s a particular mode that sounds like it allows completely free-form placement of control, which is what I’m expecting, but apparently requires an additional component to be added and distributed with the app.