I think that's just another kludge, so it would be just as well to stick with the minimized+not-in-taskbar. Most of the time the object oriented wrapping of the underlying Windows API mechanics is a benefit, but there are few rare cases when some things are a little more difficult. Hiding the main window on startup was also not obvious with MFC and Borland C++ Builder. If you ever wrote Windows apps "in the raw" it was pretty easy to control such things, but all the frameworks hide those details from you. Nevertheless, the productivity gain makes it well worth the price of dealing with the occassional quirk like this. After developing a few graphical apps in C#, there isn't much draw to going back to using the API in C. Matt Gerrans

Thanks Daniel! With some modifications that worked perfectly. Andreas Färnstrand

What you need is a SerializationBinder for the new assembly. See the sample code on MSDN for System.Runtime.Serialization.SerializationBinder for something similar to what you want... Yes, even I am blogging now!

leppie wrote: Your method also fails to consider that text might be selected in the RTB, so much more work to handle that, now add some color and threads, and you have a nice mess. Yeah, you're right. But how am I supposed to know if that's required? I guess that's the whole point here. You contributed a solution, I contributed a solution. Yours is a general purpose one. However it depends on Win32 API calls (and therefore isn't platform-independent... yeah, I know... I don't know if that's required either ;-)). Mine has some drawback with complex states of the RichTextBox. But following the Simplicity XP rule[^] (as well as the KISS principle[^]) ScrollToCaret() would still be my first suggestion. If it turns out not to meet the requirements it has to be re-written. You see, if one starts with the more complex solution and it is unnecessary someone might replace it during refactoring anyway (following the Refactor Mercilessly rule[^]). Best regards Dennis