[ASP.NET] Server side viewstate

During the development of an ASP.NET app, I noticed the increasing size of the viewstate as I added more controls to pages. Googled the net a bit and found a way to keep the viewstate on the serverside by overriding SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium methods of the Page class:
- Create a unique key based on the session id, url and timestamp and use this to store the viewstate in the Cache.
- Register a new hidden field to store this key client-side
- When the viewstate needs to be restored, fetch the key from the page and load it from cache
You may also use Session as it may be kept on SQL Server. Anyway, nice idea, dramatically reduced the size of my pages.

[.NET] .NET components in IE, part 1

Same .NET app, trying to make it run as an ActiveX component. Throughout the app, I have made extensive use of the Forms Designer, because I like designing the interface in a visual way. I hate the programmatic ways. Anyway, this allowed me to attach images to my custom buttons (they should really put one generic image button control in the framework) while not being bothered with details about the bitmaps -- they just go into the resources and it knows to load them automagically. Nothing cooler, except that when you run the same component from IE, you hit into something named localization issues. For each ResourceManager instantiation, the framework looks for culture specific resource files in two dozen places (derived from the component's URI). This would not be an issue over the LAN, but over the Internet it is. Moreso, on my system, it sometimes just hangs while doing this. Debugging the app led me to a GetObject call from the ResourceManager. It just stops there. I didn't have the pacience to see if there was a timeout (and even if it is, who cares).

Googled the net for answers, and finally found one great article for MSDN Mag:
http://msdn.microsoft.com/msdnmag/issues/02/07/NetSmartClients/

The solution appears to be removing the use of resource managers by loading the image files manually from external sources. This would reduce the number of HTTP requests to just 2 per component (the component and the .config file). It may or may not be a bug in the framework, but it certainly sends part of easy interface design to hell.

[.NET] ToolTip resource leaks

Working on a .NET app. I've added tooltips to some buttons in a complex user control. The user control was so complex, it contained about 70 controls in it. Creating/destroying this user control multiple times would exhaust the GDI resources on my machine. I first inspected the problem with Process Explorer from Sysinternals (www.sysinternals.org) and found out it was eating user handles like crazy. Then I used a memory profiler for .NET (.NET Memory Profiler 2.6 by Scitech - http://www.scitech.se/memprofiler/), took some heap snapshots and manually inspected the leaking control instances. I finally found the problem to be a ToolTip control that is keeping references to objects. Then i googled the net and found the same problem being found about two years ago :)
To put it simple: one should remove tool tips (at some point) in order to get the whole form disposed.

[.NET] Out of Memory with Graphics.DrawImage and ImageAttributes

I am developing some user controls in .NET using Forms. I need to transparently draw a bitmap on a button, so I'm using ImageAttributes to specify the transparent color. Still, a problem appeard: having many of these buttons shown on the screen would sometimes crash with OutOfMemoryException in the DrawImage method. Removing the ImageAttributes-based rendering would also prevent the creash. Dug the net, found nothing. I remembered a while ago that the best Bitmap format to use in terms of speed was 32bit PARGB. So I converted my Bitmaps to this format and the crash went away. My guess is that during the rendering with specified ImageAttributes, it performs some kind of expensive conversion (both time and resource wise) if not 32bit PARGB. Having the bitmaps in this format, prevents this expensive operation.