The "THING" so far: I've been working on my own IDE, not so much as to make the ULTIMATE IDE, but to get a handle on writing working code to support an application object model, which will support scripting engines. I've defined my classes like so: Workspace: top level object, basically same as the program running instance (thus it is a 'static' class) Project: A Project is a holder for a collection of Documents and a collection of other Projects Projects: A collection of Projects. Supports the _NewEnum method, which returns an object that supports IEnumVariant so script engines (and VB itself) can walk the collection Documents A collection of Documents. Also supports the _NewEnum method. Document Generic name for any referenced file. Currently, here's how far I am. All objects have been roughed out, all may be created, and support a minimal base of functionality, basically the collection objects collect, and the item objects may return their names. All classes may be instanced. Here's how they play together. When the app starts, it calls the constructor method of the Workspace object (it may be a static object, but it still needs this init). This method looks for a project name (soon it will get from command line or menu command, for now it's hard coded), and uses that filename to create a Project. The Project object, in its constructor, in turn passes that file as it creates a Documents object (a project is a collection of files...). Then it passes the same filename as it creates a new Projects collection (and a collection of files). The Documents constructor looks through this file for any FILES filenames stored in the project file it got. If any exist, Documents creates a Document for each one. Note a Document is NOT a window, each is separate (but for testing, it now opens a dummy MDI window for each). The Projects constructor is the most fun. Since it has a file containing a collection of Projects, it creates a Project for each one. Note the wonderful recursion happening here, since Project is a class we already defined. After the Workspace constructor is finished, it calls a rudimentary LoadProject method to the Project Explorer, a Tree View control. Workspace holds the top Project, so it creates a Project Image in the list, using the IProjects:_getName property method to get the same Project Name it loaded off the file when the Project object was created. The top Project also has a list of Documents, so then this list is run through and added under a File TreeView Item image. So each Project is fleshed out with a top Project group, and it's member files. Again, here's where it gets cool. IProjects_getProjects returns the collection of other projects we opened, those projects under the top main project. This list is walked, but the code to put these into the TreeView is already done: just call that same LoadProject method of the Project Explorer! Eventually, the Project Explorer list will hold an object pointer for each object represented by its view; this is about 4 lines of code to implement, I'm just getting their now. So, by clicking on an item, the Project Explorer already HAS all the info it needs to implement whatever methods on that object we need performed. Dang, you know, these COM objects are supporting real OOP in asm. The code is beginning to come in fast to support the objects. After all, there ain't much difference between a Documents collection and a Projects collection. The Enumeration object is already a library Class. After I look at the differences between the two collection Classes, those also may become library Classes, as offhand I don't think they differ in their methods beyond the constructor and destructor, so the could INHERITE those other methods from some standard Class. And it's kinda fun to see a couple of month's work finally starting to pay off.