Joe,

>Are you saying the NULLs are a non-issue because the resourses they consume are unimportant, or because I should be finding another way 'round it?

They don't take up enough resources to matter.

>DO FORM would be an alternative, except I make all forms objects, not SCXs, so I can benefit from inheritance. As far as I can tell, DO FORM only has two advanatges (and many disadvantages) over object-based forms, one being the fact that a form summoned with DO FORM can return a value directly, and second, that it can be summoned without a variable reference. It was this second point that made me think there had to be a way to summon without reference using CREATEOBJECT() as well, but it seems I am incorrect.

DO FORM based forms have every bit as much inheritance as a CreateObject() form. Perhaps you haven't found the Tools, Options, Forms, Form Template to specify what form class should be used in the CREATE FORM process. VFP6 now has clauses to allow direct specification of form class and classlib to use in CREATE FORM. You can use the class browser to change the form class.

Your non-saved CreateObject() did exactly what you specified it went out of scope at the bottom of the WITH, so it destructed.

>Thanks for the reminder on the Forms collection...I forget that is there a lot of times. *smile* I will keep it in mind if I need to reference my public forms, but like I said, I generally have no need to reference the forms once they are created...they are self-contained.

It really sounds like you shold be using a Form Manager class, that handles instantiation requests and stores the CreateObject() in it's own array property:

with this
   .mnForms = .mnForms + 1
   .maForms[.mnForms] = createobject( pcForm )
endwith

This would replace your plethora of publics wiht a single goFormManager, which can even be a property or contained object of goApp.