Starting the debugger in a modal screen

Usually in ABAP, when you want to start the debugger from a certain point, you just have to write "/H" in the

command window. But if you are in a modal screen or in a message display, you cannot write the traditional

"/H", here is how to do it :

1. Open notepad and paste these lines in a document : [FUNCTION] Command=/H Title=Debugger Type=SystemCommand
2. Save this document anywhere on your local pc. ex: c:\breakpoint.txt
3. Drag&drop this file from the explorer to your ABAP modal screen.... 

To Find 1st and 3rd Saturday in a month

A Simple Program to find 1st and 3rd Saturday in a month .

INHERITANCE & POLYMORPHISM

Inheritance defines the relationship between classes, in which a class (subclass) uses the structure and behavior that has already been defined in one or more other classes (superclasses). So simply this means "Inheritance is about reuse!".

Allow me to use a concrete example to explain inheritance: Collection.

A collection is any number of objects (more precisely object references).  However, there could be many types of collection. Therefore, I will implement each type of collection as a class. In principle this approach is correct. However, you will soon establish that all collections have several components in common like:

1.                Each class requires a method in order to add objects to a collection.

2.                Each class requires a method in order to delete objects from a collection.

3.                Each class has a method which identifies the number of object references in the collection and so on.

Inheritance is the solution to this situation. You implement all of the similarities in the class which is Superclass. You then implement the individual types of collection in their own classes which are Subclassesof the Superclass. As a subclass, these classes inherit all of the components of the Superclass. Attributes, methods and events are inherited. In addition, you can implement additional attributes, methods and events in the subclass.

POLYMORPHISM

Polymorphism occurs, where classes implement the same functionality with different methods (one functionality, several methods but the same name). This can occur via an inheritance relationship, in that the methods belonging to the superclass are redefined in the subclasses and implemented differently. ABAP Objects requires the method names to be the same and the signature to be the same (signature = method interface).

Polymorphism can be achieved in 2 ways:

(1) Two independent classes implement methods with the same names and the same signature with the intention, that the methods should be called dynamically from a third location.

(2) A superclass implements a method, and in a subclass you want to re-implement the same method, as the superclass implementation is not suitable for the subclass.
The first scenario will not occur very often in ABAP Objects, as the interface concept was created precisely for such cases.

EVENTS

Events are recognized in particular by programming interfaces of the GUIs (Windows, Motif, etc.), for example, you can "ask" the GUI to trigger an event if the user moves the mouse over a specific part of the screen. When the event occurs you are telling the GUI to change the shape of the mouse pointer.

Events allow for the loose coupling of components (classes or objects) in a system. The event trigger does not normally know at the time of coding who is going to react to the event. Those components, which want to react to the event, register at the event runtime, in that they tell the runtime environment which method is to be executed when the event is raised. In this way many components can register for an event.

Event handler methods can proceed synchronously as well as asynchronously. At present, ABAP Objects only supports synchronous calling of the event handler method.

Code listing for: Z_006_EVENT
Description: EXAMPLE OF EVENTS

*---------------------------------------------------------------

*  THIS EXAMPLE SHOWS THE USE OF EVENTS.

*---------------------------------------------------------------

*

* The event trigger does not normally know at the time of

* coding who is going to react to the event. Those components,

* which want to react to the event, register at the event

* runtime, in that they tell the runtime environment which

* method is to be executed when the event is raised. In this way

* many components can register for an event.

*

*---------------------------------------------------------------

REPORT  Z_006_EVENT.

*----------------------------------------------------------------

*       CLASS CL_NAME

*----------------------------------------------------------------

CLASS CL_NAME DEFINITION.

  PUBLIC SECTION.

    " DEFINE EVENT

    EVENTS OBJECT_CREATED

              EXPORTING VALUE(EX_OBJ) TYPE REF TO CL_NAME.
    METHODS: CONSTRUCTOR,

             " DEFINE EVENT HANDLER METHOD

             PROCESS_EVENT FOR EVENT OBJECT_CREATED OF CL_NAME.

  PRIVATE SECTION.

    DATA MSG(16) TYPE C.

             " register method with runtime will be executed

              " when event OBJECT_CREATED fires.

ENDCLASS.                    "CL_NAME

*----------------------------------------------------------------

*       CLASS CL_NAME IMPLEMENTATION

*----------------------------------------------------------------

CLASS CL_NAME IMPLEMENTATION.

  METHOD CONSTRUCTOR.

    MSG = 'OBJECT CREATED'.

    " Register the event handlers for the corresponding/all

    " instance/s.

    SET HANDLER PROCESS_EVENT FOR ALL INSTANCES.

    " Raise event OBJECT_CREATED.

    RAISE EVENT OBJECT_CREATED EXPORTING EX_OBJ = ME.

                           "ME refers to current instance

  ENDMETHOD.                    "CL_NAME

  " EVENT HANDLER

  METHOD PROCESS_EVENT.

    WRITE: 'EVENT FIRED :', ME->MSG.

  ENDMETHOD.                    "PROCESS_EVENT

ENDCLASS.                    "CL_NAME IMPLEMENTATION

DATA INSTANCE TYPE REF TO CL_NAME.

START-OF-SELECTION.

  CREATE OBJECT INSTANCE.

  CLEAR INSTANCE.

Program Output : 006

EVENT FIRED : OBJECT CREATED

VISIBILITY

An important feature of object-orientation is the encapsulation of attributes and methods - ultimately of functionality - in classes. A class guarantees its user specific properties and specific behavior. The sum of these properties is called the class interface. The Visibility mechanism defines the class interface which is available to the users.

There are three commonly defined types of visibility in object-oriented technology:

Public
The relevant class component (attribute, method, event etc.) is visible to all classes.

Protected
The relevant class component (attribute, method, event etc.) is visible to the class itself and all inheritors. (We will return to the terms Inheritor and Inheritance later in this document.)

Private
The relevant class component (attribute, method, event etc.) is only visible to the class itself.