>>>>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...?

Me neither. That's why I use public variable and Do Form ... Linked for medeless forms.