>>>OK - we need to talk..
>>>You are right: my command should... be:goform.helpdesk_maintform1.cmdenterquery.Enabled=.t....
>>>THIS WORKS AND I AM HAPPY!!! - but I want to understand what I am doing here.
>>>DO FORM updatcal name goform linked - what does this do? does it put my form
>>>in memory so I can reference the objects on the form. I always thought DO FORM
>>>calls a form?
>>
>>It's roughly the same as CREATEOBJECT() in that it creates a memory variable by which you can manipulate the form and its objects. It still runs the form, but you now have access to it from the outside.
>>
>>BTW, you might want to re-read Ed's posts. He's right about the correct OOP way of doing this.
>
>I try to do everything as "OOP-as-possible" but to do it that way wouldn't you have to save every form you create via the form-designer as a class in order to utilize CreateObject()? Either that or do it all through code including adding of all the objects and PEMs?

I'm not, by any stretch of the imagination an "OOP purist". More like "OOP impurist. Lots depends on the nature of the particular job. In my case I use what I decide is going to be the easiest to maintain. As a matter of fact, modal dialogs are almost never subclassed. It works for me. Someone else, however...?