Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Command Button Class Design

Status
Not open for further replies.

bernardmanning

Programmer
Oct 14, 2003
61
GB
Hi, I wonder if somebody could give me some feedback on this proposed classed design.

This class is based around the command button control and the hierarchy looks like this :-

FoxproBaseCommandButton
|
V
MyStandardCommandButton
|
---------------|
| V
| MyAppCommandButton
| Method Click - Private
| Method PreClick - Public
| Method PostClick - Public
|
MyCommandButton

My intention is that when we create classed controls to do certain tasks we use the MyAppCommandButton class and prevent the user from placing code in the click event when it's subclassed. If the user wants to perform an action either before or after the click then it goes in the preclick or postclick methods.

The design idea behind this is that the class code will always be 100% correct, at least in theory, so the click event code will never need overriding.

The MyCommandButton class doesn't have pre or post click event and is to be used for other buttons that don't have classed code.

My problems are :

1 - Issues around the developer knowing which button to use and when

2 - The fact that the same control has a different class interface and doesn't have a good level of abstractions eg, one uses pre and post methods whilst the other uses the click method.

3 -The fact that when using one class code is placed in one set of methods, pre and post, and when using the other control code is placed in another methods, the click.

I think I may be better off subclassing all my buttons from the MyAppCommandButton class so that all the buttons in my app have the same class interface and standard methods.

Do you think it's a good idea to have the click event private so that you cannot override it?

Any feedback would be appreciated.

Bernard
 
Bernard,

I think this is essentially a good approach. It is one that I have occasionally used myself. It promotes good encapsulation, and properly separates the processing from the user interface.

The main suggestion I would make is that, instead of PreClick and PostClick, you have a singe OnClick method. I can't foresee any circumstances in which the programmer would want to split the click action into two different stages (if that situation ever does arise, it would call for a special sub-class).

The other thing I have done is to disable the button immediately before calling OnClick, and enable again afterwards. That would take care of the occasions when the click action takes a long time; it would give visual feedback to the user to indicate that the button was indeed clicked.

The three issues you identified can all be overcome by using MyAppCommandButton exclusively (in other words, dispense with MyCommandButton).

I'd be interested to hear what you eventually decide.

Mike



Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site: My Crystal Reports web site:
 

Hi Mike,

Thanks for the reply, you always seem to be the person who answers my postings and your input is appreciated.

Thanks for the tip about disabling and re-enabling, this is a good idea.

This design is not one of my own and I, like yourself, didn't see the need for the MyAppCommandButton and the MyCommandButton.

I didn't like the fact that they both behaved in different manners and essentially did the sme thing.

One other factor is that the designer of this class has these methods :-

Pre_Click
Standard_Click_Event
Post_Click

The instrinic foxpro Click method is private and calls the

Pre_Click
Standard_Click_Event
Post_Click

methods is turn.

Both the standard_click_event and the click event are private and cannot contain code at an instance level.

Do you think having the click events as private is a good thing?

It would seem to me that this is the one event for a command button you would want to be visible at a subclass level?

This would allow you to do this kind of thing at the interface level

Button.Click method

Do SomeThingElse
DODEFAULT()

If the click events are private then you'd have to change the parent class or create another child class.

This doesn't seem like a good idea as sometimes you may wish to do something slightly different with the command button on one form and not do it anywhere else.

I understand the need to encapsulate the code but this just seems to be one area that you need flexibilty.

I'd appreciate your opinions on this one

Many Thanks, Bernard










I would like to simply see a class that has



A click event





 

ignore the bit at the bottom of the post

"I would like to simply see a class that has



A click event "

it's a cut and paste job!
 
Bernard,

My inclination would be to NOT make the Click event private. I can see why the original designer might have done that. If someone puts code in the Click at the instance level, it would override the code that calls the other three events. But that's a risk you take with all clases. If you follow that argument, all events would be private except for hooks.

Also, I can see no good reason for making Standard_Click_Event private. I would have thought this was the obvious place to put the instance-specific code. Is there any code there at the class level?

On balance, I still feel that Pre_Click and Post_Click are unnecessary, and only server to clutter the property sheet. But I might be wrong.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site: My Crystal Reports web site:
 

Hi, and thanks for the reply.

Yeah, I can see the reasoning behind making the click private, but I'm not sure that I'd do it.

There is no code in the click_standard method I think it's suppose to be 'placeholder' method.

I realise alot of class design is down to individual cases and it difficult for you to say whether the post and pre hooks are required, but I do think they just clutter it up and make it overly complicated.

You can achieve the same thing by doing this in the click event at an instance level, can't you?

* this is code that occurs before the click
DODEFAULT()
* this is code that occurs after the click

you could prevent the default code from running by placing a condition around it

IF WeNeedToRunIt()
DODEFAULT()
ENDIF
* post process

Many thanks for your comments...

Bernard


 
Hi Bernard,

I can think of no reason to make the click of a command button private. Since this wasn't your design, do you know the reason the original designer made the click private? Are they possibly calling a form method that IS editable? thisform.onclick()

Also, I think it redundant to use DODEFAULT() with a command button. What is the default action? I dropped a command button on a form and put NODEFAULT in it's click event and could not discern a difference in it's behavior.

Regards,

Mike
 
Mike,

<< I think it redundant to use DODEFAULT() with a command button. What is the default action? >>

I think the point is that there might be code in an ancestor class. You don't want someone to write code in a sub-class or instance and overwrite that ancestor code.

<< I dropped a command button on a form and put NODEFAULT in it's click event and could not discern a difference in it's behavior.>>

But that has nothing to do with DOFEFAULT(). Remember, DODEFAULT() executes programmer-supplied code. NODEFAULT inhibits the built-in behaviour.

Mike



Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site: My Crystal Reports web site:
 
Yup, DODEFAULT() is to run the parent class code. Since I used the _base class for my test, it's irrelevant.

Point being that I don't think that the click event of a Command Button has default behavior other than running the method code supplied by the programmer. If true, NODEFAULT is also irrelevant for the click event of a Command Button.

The only argument I can think of to make the click private is to have the click method call a form method. Thus keeping method code in the form, where it belongs.

Regards,

Mike
 

Hi,

In this case the command button is a classed control and the parent class click event does contain code.

I believe the programmer who designed this, its a work in progress by the way, wants to try and keep the code abstracted within the class control, rather that have a load of subclassed code at the form level.

I agree with this in principle, but I think we do need the option to place code at a sub-classed level to provide the highest level of flexiblity.

I always like to use NODEFAULT just to make it 100% clear that I've overridden the method by design rather than by accident.

Thanks, Bernard
 
So, the click is made private so that it can't be called from code, but it will occur if the button is clicked?

Regards,

Mike
 
Mike,

So, the click is made private so that it can't be called from code, but it will occur if the button is clicked?

Not quite. Making an event private (or, rather, protected or hidden -- PEMs can't be private) does not prevent the event from firing. Actually, that's the same with methods. You can still call them, and events will still fire. But you can't add code at the instance or sub-class level.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site: My Crystal Reports web site:
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top