>Is the following an example of a sound practice, or is there a better approach?
>
>Command button class named: cmd_ClassNew
>
>First instance: ThisForm.PageFrame.Page1.cmd_New1
>Second instance: ThisForm.PageFrame.Page2.cmd_New2
>
>In cmd_ClassNew.Click there is code to run ThisForm.AddProc().
>
>In both cmd_New1.Click and cmd_New2.Click is code to store the current view as ThisForm.CurrentView. Then I issue DoDefault() and perform things like PageFrame.ActivePage and Object.SetFocus relevant to the particular instance.
>
>The ThisForm.AddProc() method contains code to add a new record based on the ThisForm.CurrentView. I use a case statement to handle the logic.
>
>Any opinions? I apply this logic to other objects as well, but command buttons were the easiest to describe. Seems I've read somewhere that objects should only know about themselves (or something like that) and wondered what the best way to handle class/instance logic was. Just trying to make sure I'm doing the best by my apps. Thanks!
>
>Renoir


First I like to name my form objects as meaningful names as possible. If I have a "Add Invoice" button. I would call the button, "cmdAddInvoice".

I believe that if both buttons need to call this AddProc. You're not gaining much by storing that in the base class.

I would need to see the other objects where you're doing something similar to give advice. Though normally, what you said is correct, it is better for the subclass of the buttons to have to know something specific about a form.

For one thing this can make it more difficult to use your subclassed buttons. Later you might have a form that calls AddProcs() instead of AddProc(). You would then have to create a new subclass just for that form.