Smalltalk and Object Orientation: an Introduction - Free

names) and the actions for buttons (the messages to send if they are selected). We can now get the
system to define these for us aut omatically. This is done using the ‘Define’ option from the canvas tool.
This brings up the definer window as illustrated in Figure 27.9. This allows the user to select which
aspects and which actions they wish to define. This can be used to ensure that modifications made to the
definitions by the developer do not get over written.
Figure 27.9: The Definer
Different things happen to inpu t fields (and to lists and tables) than to action buttons. In the case of
an input field the system defines an instance variable on the class and creates an accessor method as
illustrated in Figure 27.10. This accessor method also provides a lazy initialization approach to the
instance variable.
For an action the definer merely creates a stub method which returns self. This ensure that when the
window is created an exception is not generated when a button is pressed. Th e user is then able to
redefine the action methods to perform the desired operations.
Figure 27.10: The defined entry aspect
27.7 Initialization
It is important when using an a pplication model to ensure that any initialization performed does not
overwrite that accomplished higher up in the ApplicationModel class hierarchy. For example, in
Figure 27.11 we define an initialization method for th e simple to do list Organizer presented in Figure
27.12. The first thing that this method does is to send a message initialize up the class hierarchy
using:
super initialize.
This ensures that the initialization steps performed by the ApplicationModel will be carried out
first. This is essential because if initialize merely overwrote the inherited method, then the user
229