Adding Methods to Framework Windows

1. Many tasks are repetitive within one or many applications. Try to avoid coding the same thing multiple times. If you create method signatures (prototypes) in your framework, you won’t have to constantly repeat that step. Some times you will just define the method signature in the framework object, and then override the method in the descendant object(s). Some times you will put code in the ancestor. These are design decisions.

2. Name some common tasks that will be invoked by an end-user who is working with a window (especially windows that allow data and/or data manipulations):

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ 3. Placement of methods within the hierarchy is a critical decision. Where do the

ue_insert and ue_delete methods belong in the framework?

_____________________________________________________________________ 4. The answer to that question is always “it depends.” Object-oriented programming

takes much design work. If your Master-Detail windows could be editable, then you would have to put the above methods in w_sheet in our hierarchy. You want to be careful about where you place methods so as to avoid over-engineering descendant classes.

5. The decision to make your methods functions or events is also a design issue. This needs to be a thought-out before you arbitrarily create methods. A good rule of thumb is if it is initiated by an end-user, it is an event. If it is something the system initiates internally, it is a function. But you need to also remember that only functions can be overloaded. Only functions allow you to set an access privilege such as Private or Protected. Review Module 4 for more details about choosing events or functions. 6. Open w_sheet in the Window painter.

Task 3: Adding Methods to Framework Windows

1. Many tasks are repetitive within one or many applications. Try to avoid coding the same thing multiple times. If you create method signatures (prototypes) in your framework, you won’t have to constantly repeat that step. Some times you will just define the method signature in the framework object, and then override the method in the descendant object(s). Some times you will put code in the ancestor. These are design decisions.

2. Name some common tasks that will be invoked by an end-user who is working with a window (especially windows that allow data and/or data manipulations):

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ 3. Placement of methods within the hierarchy is a critical decision. Where do the

ue_insert and ue_delete methods belong in the framework?

_____________________________________________________________________ 4. The answer to that question is always “it depends.” Object-oriented programming

takes much design work. If your Master-Detail windows could be editable, then you would have to put the above methods in w_sheet in our hierarchy. You want to be careful about where you place methods so as to avoid over-engineering descendant classes.

5. The decision to make your methods functions or events is also a design issue. This needs to be a thought-out before you arbitrarily create methods. A good rule of thumb is if it is initiated by an end-user, it is an event. If it is something the system initiates internally, it is a function. But you need to also remember that only functions can be overloaded. Only functions allow you to set an access privilege such as Private or Protected. Review Module 4 for more details about choosing events or functions. 6. Open w_sheet in the Window painter.

7. Add the following new user events (un-mapped). All of these events return (None) and have no arguments:

ue_print( ) ue_save( )

An example follows:

8. Add the following new user events (un-mapped). These events return a long and have one integer argument named as seen below:

ue_delete( integer ai_del_location ) ue_insert( integer ai_ins_location ) An example follows:

9. Save and close w_sheet.

10. Because of inheritance, descendants will inherit any non-private members of their ancestors.

11. Open w_data_sheet and verify the existence of the four new events.

7. Add the following new user events (un-mapped). All of these events return (None) and have no arguments:

ue_print( ) ue_save( )

An example follows:

8. Add the following new user events (un-mapped). These events return a long and have one integer argument named as seen below:

ue_delete( integer ai_del_location ) ue_insert( integer ai_ins_location ) An example follows:

9. Save and close w_sheet.

10. Because of inheritance, descendants will inherit any non-private members of their ancestors.

12. Close w_data_sheet.

13. Verify existence of the four events on w_master_detail_sheet. You have reduced the amount of effort necessary by half because of inheritance. Remember, code will be added later, as we learn new concepts and techniques.

14. Before closing the Window painter, select Tools-Keyboard Shortcuts… from the menu and then add the following shortcuts:

15. EditÆGo ToÆ Events – Ctrl+Shift+E 16. EditÆGo ToÆ Functions – Ctrl+Shift+F 17. EditÆGo ToÆ Instance Variables – Ctrl+Shift+I 18. EditÆActivate AutoScript – Ctrl+Tab

19. You will want to commit to memory some of the default shortcuts under Additional Painter Shortcuts. While you will not immediately understand their use, as we start into modules where coding is involved, you will use these many times. Good shortcuts to remember are:

a. Control Drop-down – Ctrl+1 b. Script Drop-down – Ctrl+2 c. Show/Hide Prototype – Ctrl+4 20. Close any open painters.