Archive for the ‘Programming’ Category

C#/WinForms: Binding a SortedList to a DataGridView

Friday, April 4th, 2014

I ran into an issue the other day, and I didn’t find a suitable answer online. Maybe my google-fu was weak that day. Regardless, I thought I’d add my workaround here, in case anyone else runs into the same problem and wanders this way.

(more…)

Missing MSVCR80.DLL, MSVCM80.DLL, MSVCP80.DLL

Thursday, May 27th, 2010

I ran into a problem yesterday that took a few hours to decipher. I thought I’d share it here, in case Google manages to lead someone with a similar problem this way.

I made a minor change to a DLL in a program I’ve been working on and distributed it to the end users. The user that had requested the fix was happy with the result, and everything was fine for a couple of hours. Then I received an email from another user complaining the program was failing to load, reporting the error

System.IO.FileLoadException: Could not load file or assembly 'MyLIB, Version=1.0.3798.19982, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

I’d seen this type of error before; typically it means MyLIB.dll requires another DLL that isn’t present. I checked his program folder, but everything was present – no missing DLLs. Tried re-patching and tried re-installing, and still no luck. I ran the dependency walker to see exactly what it was that it was missing. Turns out to be MSVCR80.DLL, MSVCM80.DLL and MSVCP80.DLL – the MS Visual C++ runtime.

Wait, what?

That didn’t make any sense, as he’d had the program running happily a few hours before. I tried re-installing the runtime, but that didn’t seem to help. Much scratching of heads and gnashing of teeth followed.

It turns out that the new build of MyLIB.DLL that I’d built had tied itself to the specific runtime version I had on my PC – 8.0.50727.4053. These runtime DLLs were installing into C:\Windows\WinSxS, where different versions of the same DLLs live side by side in an uneasy truce. I don’t pretend to fully understand what’s going on in there, but anyway. The different versions of runtimes were in different subfolders, the names of which contained the version number. When we checked the machine that the program was failing to run on, the .4053 version wasn’t there. We had to find that specific C++ redistributable version on microsoft.com as install it, which fixed the problem. The version of the runtime I had tried reinstalling earlier was an older version. It was then I realized that I have a new PC, and this is the first time I’ve rebuilt that particular DLL on this machine. Those with older machines were less likely to have the newer runtime installed.

Many sources on the interwebbings were simply saying “get the dll from here, and stick it in your Windows\System32 directory”. This is exactly wrong in this instance.

It would be nice if I could find an option in the project build configuration that says “Use runtime version X or later”, rather than it requiring the specific version it finds on my machine.

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.

Netbeaning it again

Friday, September 19th, 2008

I ran across this comment today:

[…] on more complex forms, [the Matisse GUI editor] becomes unbelievably frustrating and time-consuming. It tries to be too intelligent about what it thinks you want to do and often just moves things around wildly when trying to do simple adjustments or additions of components.

and another comment further down:

I’ve spent hours trying to get the layouts I want with it and it seems to be more trouble than it’s worth sometimes. Sometimes it insists on stretching and stretching my forms.

By this time, I’m banging on the desk shouting “Yes! That’s exactly what I’m seeing!”. Further down still:

About the Matisse problems; they rely on the layout. try changing the layout to NullLayout

Oooh, of course. That makes perfect sense.

One downside is that you need to do this before you start. I tried changing it on a complex window layout I’d manage to coax together, and it promptly collapsed all the controls into a heap. But I tried playing around with it in a test window and sure enough, I was able to drag around and place controls wherever I wanted without the annoying repositioning and resizing of other controls.

Apparently, I also lose some other features in this mode. Exactly what, I’m not sure, as I’ve only had a few minutes to play around with it. Maybe some of the fancy alignment tools have gone. I can probably live without that.

Look ‘n’ feel

I finally got my app running far enough to show me my window layout in all its glory. I was startled to see that the Windows XP appearance of the controls that I see in the GUI editor have been replaced with java-rendered equivalents. This is exactly what didn’t happen with the test application I made to make sure that this sort of thing wouldn’t happen. I’ve been hunting around in case there’s an option hidden somewhere that causes it to render controls in the native-OS form. No luck yet. I’m not sure what the difference is between my test app and the main app. Maybe it’s because I started the test app as a Java Desktop Application, whereas the main app started life as a JOGL app, and got additional windows added in.

I daren’t go any further with this until I see how it looks on a Mac. If I need to rebuild the app as a desktop app with JOGL window added in, I want to make sure that looks right on a Mac before I get too far down the path.