I am working on a VB.NET WinForms app that was "upgraded" by Visual Studio (originally 1.0 or 1.1) from VB6 code (which was itself upgraded from VB5). Except for the few new forms I've created since taking over maintenance of this app, all of the forms in the application have a method called DefInstance which allows you to grab an in-memory copy of the form if there is one. What I can't figure out is why: when would I ever need to reference a form object in memory when it's not immediately in scope where I'm working. To my mind this violates all kinds of sound programming principles and seems like an invitation for memory leaks or worse.
The questions: (1) is this DefInstance thing an merely unfortunate remnant of the VB6 heritage of this app, and (2) should I make a point of removing DefInstance methods throughout the application?
I received this answer from a Microsoft employee:
http://msdn.microsoft.com/en-us/library/aa289529(VS.71,printer).aspx
In short, DefInstance is a "not best practices" compatibility method for older apps that haven't been made into true .NET WinForms apps. Being a web programmer until earlier this year I had never worked with VB6 "WinForms" applications nor had to deal with the compatibility compromises that the upgrade wizard makes in forcing them into .NET.