Learn Object Oriented Pogramming ( OOPS )

Definitions

Public attributes
Private attributes
Instance attributes
Static attributes
Public methods
Private methods
Constructor method
Static constructor
Protected components
Polymorphism


Public attributes
Public attributes are defined in the PUBLIC section and can be viewed and changed from outside the class. There is direct access to public attributes. As a general rule, as few public attributes should be defined as possible.

PUBLIC SECTION.
DATA: Counter type i.



Private attributes
Private attributes are defined in the PRIVATE section. The can only be viewes and changed from within the class. There is no direct access from outside the class.

PRIVATE SECTION.
DATA: name(25) TYPE c,
planetype LIKE saplane-planetyp,

Instance attributes
There exist one instance attribute for each instance of the class, thus they exist seperately for each object. Instance attributes are declared with the DATA keyword.

Static attributes
Static attributes exist only once for each class. The data are the same for all instances of the class, and can be used e.g. for instance counters. Static attributes are defined with the keyword CLASS-DATA.

PRIVATE SECTION.
CLASS-DATA: counter type i,

Public methods
Can called from outside the class

PUBLIC SECTION.
METHODS: set_attributes IMPORTING p_name(25) TYPE c,
p_planetype LIKE saplane-planetyp,


Private methods
Can only be called from inside the class. They are placed in the PRIVATE section of the class.



Constructor method
Implicitly, each class has an instance constructor method with the reserved name constructor and a static constructor method with the reserved name class_constructor.

The instance constructor is executed each time you create an object (instance) with the CREATE OBJECT statement, while the class constructor is executed exactly once before you first access a class.

The constructors are always present. However, to implement a constructor you must declare it explicitly with the METHODS or CLASS-METHODS statements. An instance constructor can have IMPORTING parameters and exceptions. You must pass all non-optional parameters when creating an object. Static constructors have no parameters.


Static constructor
The static constructor is always called CLASS_CONSTRUCTER, and is called autmatically before the clas is first accessed, that is before any of the following actions are executed:

Creating an instance using CREATE_OBJECT
Adressing a static attribute using ->
Calling a ststic attribute using CALL METHOD
Registering a static event handler
Registering an evetm handler method for a static event
The static constructor cannot be called explicitly.

Protected components
When we are talking subclassing and enheritance there is one more component than Public and Private, the Protected component. Protected components can be used by the superclass and all of the subclasses. Note that Subclasses cannot access Private components.

Polymorphism
Polymorphism: When the same method is implemented differently in different classes. This can be done using enheritance, by redefining a method from the superclass in subclasses and implement it differently.

Other Related Topics :

Object Oriented ABAP-Local and Global Classes
A easy Reference for ALV grid Control
Class vs. interface
Abstract Vs Interfaces
Object Oriented ALV-Using two Containers we can display data
Object Oriented ALV-Sample program to insert Logo in ALV
Learn Object Oriented ABAP online and Download Tutorial

Click Here to Read More !!!!

Object Oriented ABAP-Local and Global Classes

Object Oriented ABAP-Local and Global Classes



For Complete Document Download pdf


Designed By Srikanth Vadlamani

Click Here to Read More !!!!

A easy Reference for ALV grid Control

A easy Reference for ALV grid Control

ALV with Class ,



Download for Complete Document

Designed By Srikanth Vadlamani

Click Here to Read More !!!!

Class vs. interface

Also read Abstract Vs Interfaces

Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme. I use interfaces when I see that something in my design will change frequently.


For example, the Strategy pattern lets you swap new algorithms and processes into your program without altering the objects that use them. A media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program.

With the Strategy pattern, you can simply encapsulate the algorithm behind an object. If you do that, you can provide new media plug-ins at any time. Let's call the plug-in class MediaStrategy. That object would have one method: playStream(Stream s). So to add a new algorithm, we simply extend our algorithm class. Now, when the program encounters the new media type, it simply delegates the playing of the stream to our media strategy. Of course, you'll need some plumbing to properly instantiate the algorithm strategies you will need.
This is an excellent place to use an interface. We've used the Strategy pattern, which clearly indicates a place in the design that will change. Thus, you should define the strategy as an interface. You should generally favor interfaces over inheritance when you want an object to have a certain type; in this case, MediaStrategy. Relying on inheritance for type identity is dangerous; it locks you into a particular inheritance hierarchy. Java doesn't allow multiple inheritance, so you can't extend something that gives you a useful implementation or more type identity.

Interface vs. abstract class

Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks.
Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.

Many developers forget that a class that defines an abstract method can call that method as well. Abstract classes are an excellent way to create planned inheritance hierarchies. They're also a good choice for non leaf classes in class hierarchies.
**********************************************************************************

The Main Difference Between the Abstract Class And the Interface are:

1) When inheriting A Interface We have to inherit all the methods of the Interface there's no other option whereas with abstract classes we can inherit the members that we are in need of.

2) The Main difference between these is that Interface cannot have any declaration within it. Just the interface has to have body of the method and the method is to be used by the classes inheriting it. Whereas in the case of Abstract Class it can have declarations (Other than the abstract method) and it can be further extended in the classes inheriting the Abstract Class.
******************************************************
Abstract Class: A class that cannot be instantiated. An abstract class is a class that must be inherited and have the methods overridden. An abstract class is essentially a blueprint for a class without any implementation.

Interface: Interfaces, like classes, define a set of properties, methods, and events. But unlike classes, interfaces do not provide implementation. They are implemented by classes, and defined as separate entities from classes
********************************************************
Abstract Class:

(1) It contains both abstract methods and non abstract methods

(2) object can't be created just through reference we are calling all the methods

(3) it is implemented by subclass , i.e which class is extended from this,abstract class contains only non abstract, this situation also code will compile fine, but problem at runtimeabstract can't be declared with a Final, Synchronized, Native, just your requirements you implement some methods in the abstract classthis class also contain Constructor

========

Interface contains all abstract methods,all methods compulsory implemented by particular classinterface does not contain Constructor,


Abstract Classes: Classes which cannot be instantiated. This means one cannot make a object of this class or in other way cannot create object by saying ClassAbs abs = new ClassAbs(); where ClassAbs is abstract class.Abstarct classes contains have one or more abstarct methods, ie method body only no implementation.Interfaces: These are same as abstract classes only difference is we an only define method defination and no implementation.When to use wot depends on various reasons. One being design choice.One reason for using abstarct classes is we can code common functionality and force our developer to use it. I can have a complete class but I can still mark the class as abstract.Developing by interface helps in object based communication.

When to use Interface over abstract class?
abstract classes are designed with implemantion gaps for sub-class to fill in.
interfaces are sintacticlly similar to classes but they lack insance variables & methods.
abstract classes can also have both abstract methods & non-abstract methods. where as in interface methods are abstract only, & variables are implicitly static&final.


When to Use Inheritance
Inheritance is a useful programming concept, but it is easy to use inappropriately. Often interfaces do the job better. This topic and When to Use Interfaces help you understand when each approach should be used.

Inheritance is a good choice when:

· Your inheritance hierarchy represents an is-a relationship and not a has-a relationship.
· You can reuse code from the base classes.
· You need to apply the same class and methods to different data types.
· The class hierarchy is reasonably shallow, and other developers are not likely to add many more levels.
· You want to make global changes to derived classes by changing a base class.

These considerations are discussed in order below.

Inheritance and "Is a" Relationships
Two ways to show class relationships in object-oriented programming are "is a" and "has a" relationships. In an "is a" relationship, the derived class is clearly a kind of the base class. For example, a class named PremierCustomer represents an "is a" relationship with a base class named Customer because a premier customer is a customer. However, a class named CustomerReferral represents a "has a" relationship with the Customer class because a customer referral has a customer, but a customer referral is not a kind of customer.
Objects in an inheritance hierarchy should have an "is a" relationship with their base class because they inherit the fields, properties, methods, and events defined in the base class. Classes that represent a "has a" relationship with other classes are not suited to inheritance hierarchies because they may inherit inappropriate properties and methods. For example, if the CustomerReferral class were derived from the Customer class discussed previously, it might inherit properties that make no sense, such as ShippingPrefs and LastOrderPlaced. "Has a" relationships such as this should be represented using unrelated classes or interfaces. The following illustration shows examples of both "is a" and "has a" relationships.



Designed By Srikanth Vadlamani

Click Here to Read More !!!!

Abstract Vs Interfaces

abstract
An formally unfinished class or method, marked with the keyword abstract. It is a way of preventing someone from instantiating a class that is supposed to be extended first. An abstract class is deliberately missing some or all of the method bodies. An abstract method is deliberately missing its method body. An abstract class is similar to an interface which is missing all the method bodies. An abstract class provides a base for someone to extend an actual class. You can't use new on abstract classes, but you can use abstract references, which always point to objects of a class that extends the abstract class. Interfaces are implicitly abstract as are all their methods.




To use make practical use of an abstract class, you must define a non-abstract class that extends the abstract one. It can use any of the inherited non-abstract methods. It must implement any of the abstract ones.
Sometimes a abstract class may extend another abstract class. In that case it need not implement all the non-abstract methods.

Interfaces
Under the hood, an interface is like a class with some restrictions.
1. All its methods must be abstract instance methods, no static methods allowed.
2. Yet, all the variables defined in an interface must be static final, i.e. constants. Happily the values need not be known at compile time. You can do some computation at class load time to compute the values. The variables need not be just simple ints and Strings. They can be any type.
3. No static initialiser blocks. You must do your initialisations in one line per variable. And, of course, no static initialiser helper methods defined in the interface. If you need them, them must be defined outside the interface.

Instantiating
interface methods are always instance methods. To use them, there must be some associated Object that implements the interface. You can't instantiate an interface directly, but you can instantiate a class that implements an interface. References to an Object can by via the class name, via one of its superclass names, or one of its interface names.
Under what circumstances would you use abstract classes instead of interfaces? When you declare a method as abstract, can other nonabstract methods access it? In general, could you explain what abstract classes are and when you might use them?
Those are all excellent questions: the kind that everyone should ask as they begin to dig deeper into the language and object-oriented programming in general
Yes, other non abstract methods can access a method that you declare as abstract.
But first, let's look at when to use normal class definitions and when to use interfaces. Then I'll tackle abstract classes.

To be Continued.....

Designed By Srikanth Vadlamani

Click Here to Read More !!!!

Object Oriented ALV-Using two Containers we can display data

*&---------------------------------------------------------------------*
*& Report Z_OO_ALV
*&
*&---------------------------------------------------------------------*
*& We can Use Two containers in OOALV
*&
*&---------------------------------------------------------------------*

REPORT z_oo_alv LINE-COUNT 50.

*types gt_struct type sflight.

DATA BEGIN OF gt_struct.
INCLUDE STRUCTURE sflight.
DATA rcol(4) TYPE c.
DATA colors TYPE lvc_t_scol.
DATA END OF gt_struct.

*ALV GRIDs

DATA gr_alvgrid TYPE REF TO cl_gui_alv_grid.
DATA gr_alvgrid1 TYPE REF TO cl_gui_alv_grid.

DATA gc_custom_control_name TYPE scrfname VALUE 'CC_ALV'.
DATA gc_custom_control_name1 TYPE scrfname VALUE 'CC_ALV1'.

*CONTAINERs

DATA gr_ccontainer TYPE REF TO cl_gui_custom_container.
DATA gr_ccontainer1 TYPE REF TO cl_gui_custom_container.

*FIELDCATALOGs

DATA gt_fieldcat TYPE lvc_t_fcat WITH HEADER LINE.
DATA gt_fieldcat1 TYPE lvc_t_fcat WITH HEADER LINE.

*LAYOUTs

DATA gs_layout TYPE lvc_s_layo.
DATA gs_layout1 TYPE lvc_s_layo.

DATA pt_exclude TYPE ui_functions. "internal table declaration to be passed.
*DATA pt_cell TYPE lvc_t_cell with header line.



DATA : gt_list LIKE gt_struct OCCURS 50 WITH HEADER LINE,
gt_list1 LIKE gt_struct OCCURS 50 WITH HEADER LINE.

*DATA v_ucomm TYPE sy-ucomm.

CALL SCREEN 100.


*&---------------------------------------------------------------------*
*& Module display_alv OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE display_alv OUTPUT.

PERFORM display_alv.

ENDMODULE. " display_alv OUTPUT

*&---------------------------------------------------------------------*
*& Module PAI INPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE pai INPUT.
CASE sy-ucomm.

WHEN 'EXIT'.
PERFORM exit_program.
WHEN 'PICK'.
PERFORM cell_info.

ENDCASE.

ENDMODULE. " PAI INPUT


*&---------------------------------------------------------------------*
*& Form display_alv
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM display_alv.
PERFORM prepare_field_catalog CHANGING gt_fieldcat[].
PERFORM prepare_layout CHANGING gs_layout.
PERFORM data_retrival.

IF gr_alvgrid IS INITIAL.

CREATE OBJECT gr_ccontainer

EXPORTING

container_name = gc_custom_control_name

EXCEPTIONS

cntl_error = 1
cntl_system_error = 2
create_error = 3
lifetime_error = 4
lifetime_dynpro_dynpro_link = 5
OTHERS = 6.

IF sy-subrc <> 0.

ENDIF.

CREATE OBJECT gr_alvgrid
EXPORTING
* I_SHELLSTYLE = 0
* I_LIFETIME =
i_parent = gr_ccontainer
* I_APPL_EVENTS = space
* I_PARENTDBG =
* I_APPLOGPARENT =
* I_GRAPHICSPARENT =
* I_NAME =
* I_FCAT_COMPLETE = SPACE
EXCEPTIONS
error_cntl_create = 1
error_cntl_init = 2
error_cntl_link = 3
error_dp_create = 4
OTHERS = 5
.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

PERFORM exclude_tb_functions CHANGING pt_exclude.
PERFORM set_col.

CALL METHOD gr_alvgrid->set_table_for_first_display
EXPORTING
* I_BUFFER_ACTIVE =
* I_BYPASSING_BUFFER =
* I_CONSISTENCY_CHECK =
* I_STRUCTURE_NAME =
* IS_VARIANT =
* I_SAVE =
* I_DEFAULT = 'X'
is_layout = gs_layout
* IS_PRINT =
* IT_SPECIAL_GROUPS =
it_toolbar_excluding = pt_exclude "excluding toolbar functions
* IT_HYPERLINK =
* IT_ALV_GRAPHICS =
* IT_EXCEPT_QINFO =
* IR_SALV_ADAPTER =
CHANGING
it_outtab = gt_list[]
it_fieldcatalog = gt_fieldcat[]
* IT_SORT =
* IT_FILTER =
EXCEPTIONS
invalid_parameter_combination = 1
program_error = 2
too_many_lines = 3
OTHERS = 4
.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.



ELSE.

CALL METHOD gr_alvgrid->refresh_table_display
* EXPORTING
* IS_STABLE =
* I_SOFT_REFRESH =
EXCEPTIONS
finished = 1
OTHERS = 2
.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDIF.


PERFORM prepare_field_catalog1 CHANGING gt_fieldcat1[].
PERFORM prepare_layout1 CHANGING gs_layout1.
PERFORM data_retrival1.


IF gr_alvgrid1 IS INITIAL.

CREATE OBJECT gr_ccontainer1

EXPORTING

container_name = gc_custom_control_name1

EXCEPTIONS

cntl_error = 1
cntl_system_error = 2
create_error = 3
lifetime_error = 4
lifetime_dynpro_dynpro_link = 5
OTHERS = 6.

IF sy-subrc <> 0.

ENDIF.

CREATE OBJECT gr_alvgrid1
EXPORTING
* I_SHELLSTYLE = 0
* I_LIFETIME =
i_parent = gr_ccontainer1
* I_APPL_EVENTS = space
* I_PARENTDBG =
* I_APPLOGPARENT =
* I_GRAPHICSPARENT =
* I_NAME =
* I_FCAT_COMPLETE = SPACE
EXCEPTIONS
error_cntl_create = 1
error_cntl_init = 2
error_cntl_link = 3
error_dp_create = 4
OTHERS = 5
.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

PERFORM set_col1.

CALL METHOD gr_alvgrid1->set_table_for_first_display
EXPORTING
* I_BUFFER_ACTIVE =
* I_BYPASSING_BUFFER =
* I_CONSISTENCY_CHECK =
* I_STRUCTURE_NAME =
* IS_VARIANT =
* I_SAVE =
* I_DEFAULT = 'X'
is_layout = gs_layout1
* IS_PRINT =
* IT_SPECIAL_GROUPS =
* IT_TOOLBAR_EXCLUDING =
* IT_HYPERLINK =
* IT_ALV_GRAPHICS =
* IT_EXCEPT_QINFO =
* IR_SALV_ADAPTER =
CHANGING
it_outtab = gt_list1[]
it_fieldcatalog = gt_fieldcat1[]
* IT_SORT =
* IT_FILTER =
EXCEPTIONS
invalid_parameter_combination = 1
program_error = 2
too_many_lines = 3
OTHERS = 4
.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.



ELSE.

CALL METHOD gr_alvgrid1->refresh_table_display
* EXPORTING
* IS_STABLE =
* I_SOFT_REFRESH =
EXCEPTIONS
finished = 1
OTHERS = 2
.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDIF.

ENDFORM. "display_alv


*&---------------------------------------------------------------------*
*& Form prepare_field_catalog
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->GT_FIELDCAT text
*----------------------------------------------------------------------*
FORM prepare_field_catalog CHANGING pgt_fieldcat TYPE lvc_t_fcat.
DATA ls_fieldcat TYPE lvc_s_fcat.
ls_fieldcat-tabname = 'gt_list'.
ls_fieldcat-fieldname = 'CARRID'.
ls_fieldcat-scrtext_m = 'Air line code'.
ls_fieldcat-col_pos = 0.
ls_fieldcat-outputlen = 10.
* ls_fieldcat-emphasize = 'C400'.
* ls_fieldcat-key = 'X'.
APPEND ls_fieldcat TO pgt_fieldcat.

ls_fieldcat-tabname = 'gt_list'.
ls_fieldcat-col_pos = 1.
ls_fieldcat-fieldname = 'CONNID'.
ls_fieldcat-scrtext_m = 'Connection code'.
* ls_fieldcat-emphasize = 'C900'.
APPEND ls_fieldcat TO pgt_fieldcat.

ls_fieldcat-tabname = 'gt_list'.
ls_fieldcat-fieldname = 'PRICE'.
ls_fieldcat-scrtext_m = 'PRICE'.
APPEND ls_fieldcat TO pgt_fieldcat.

ENDFORM. "prepare_field_catalog


*&---------------------------------------------------------------------*
*& Form prepare_layout
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->GS_LAYOUT text
*----------------------------------------------------------------------*
FORM prepare_layout CHANGING gs_layout TYPE lvc_s_layo.

gs_layout-stylefname = 'FIELD_STYLE'.
gs_layout-zebra = 'X'.
gs_layout-grid_title = 'FLIGHT'.
gs_layout-sel_mode = 'A'.
gs_layout-ctab_fname = 'COLORS'.

ENDFORM. "prepare_layout

*&---------------------------------------------------------------------*
*& Form data_retrival
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM data_retrival.
SELECT carrid
connid
price
FROM sflight
INTO CORRESPONDING FIELDS OF TABLE gt_list
UP TO 50 ROWS.
ENDFORM. "data_retrival


*---------------------------------------------------------------------*
* FORM EXIT_PROGRAM *
*---------------------------------------------------------------------*
FORM exit_program.
CALL METHOD gr_ccontainer->free.
CALL METHOD gr_ccontainer1->free.
LEAVE TO SCREEN 0.
ENDFORM. "exit_program
*&---------------------------------------------------------------------*
*& Module STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
SET PF-STATUS 'STAT'.
* SET TITLEBAR 'xxx'.

* IF W_CUSTOM_CONTAINER IS INITIAL.
*
**sets TITLEBAR
* PERFORM TITLEBAR.

ENDMODULE. " STATUS_0100 OUTPUT


*&---------------------------------------------------------------------*
*& Form prepare_field_catalog1
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->GT_FIELDCAT text
*----------------------------------------------------------------------*
FORM prepare_field_catalog1 CHANGING pgt_fieldcat1 TYPE lvc_t_fcat.
DATA ls_fieldcat TYPE lvc_s_fcat.
ls_fieldcat-tabname = 'gt_list1'.
ls_fieldcat-fieldname = 'SEATSMAX'.
ls_fieldcat-scrtext_m = 'MAX. SEATS'.
ls_fieldcat-col_pos = 0.
ls_fieldcat-outputlen = 10.
* ls_fieldcat-emphasize = 'C400'.
* ls_fieldcat-key = ' '.
APPEND ls_fieldcat TO pgt_fieldcat1.

ls_fieldcat-tabname = 'gt_list1'.
ls_fieldcat-col_pos = 1.
ls_fieldcat-fieldname = 'SEATSOCC'.
ls_fieldcat-scrtext_m = 'SEATS OCCUPIED'.
APPEND ls_fieldcat TO pgt_fieldcat1.

ENDFORM. "prepare_field_catalog


*&---------------------------------------------------------------------*
*& Form prepare_layout1
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->GS_LAYOUT text
*----------------------------------------------------------------------*
FORM prepare_layout1 CHANGING gs_layout1 TYPE lvc_s_layo.

gs_layout1-stylefname = 'FIELD_STYLE'.
gs_layout1-zebra = 'X'.
gs_layout1-grid_title = 'DETAILS'.
* gs_layout-sel_mode = 'C'.
gs_layout1-info_fname = 'RCOL'.
* gs_layout-no_toolbar = 'X'.

ENDFORM. "prepare_layout

*&---------------------------------------------------------------------*
*& Form data_retrival1
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM data_retrival1.
SELECT seatsmax
seatsocc
FROM sflight
INTO CORRESPONDING FIELDS OF TABLE gt_list1
UP TO 50 ROWS.
ENDFORM. "data_retrival

*&---------------------------------------------------------------------*
*& Form exclude_tb_functions
*&---- subroutine to exclude toolbar options --------------------------*
* text
*----------------------------------------------------------------------*
* -->PT_EXCLUDE text
*----------------------------------------------------------------------*
FORM exclude_tb_functions CHANGING pt_exclude TYPE ui_functions.

DATA ls_exclude TYPE ui_func.

ls_exclude = cl_gui_alv_grid=>mc_fc_maximum.
APPEND ls_exclude TO pt_exclude.

ls_exclude = cl_gui_alv_grid=>mc_fc_minimum.
APPEND ls_exclude TO pt_exclude.

ls_exclude = cl_gui_alv_grid=>mc_fc_subtot.
APPEND ls_exclude TO pt_exclude.

ls_exclude = cl_gui_alv_grid=>mc_fc_sort.
APPEND ls_exclude TO pt_exclude.

ls_exclude = cl_gui_alv_grid=>mc_fc_sum.
APPEND ls_exclude TO pt_exclude.

ls_exclude = cl_gui_alv_grid=>mc_mb_subtot.
APPEND ls_exclude TO pt_exclude.

ls_exclude = cl_gui_alv_grid=>mc_mb_sum.
APPEND ls_exclude TO pt_exclude.

ls_exclude = cl_gui_alv_grid=>mc_mb_filter.
APPEND ls_exclude TO pt_exclude.

ENDFORM. "data_retrival1

*&---------------------------------------------------------------------*
*& Form cell_info
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM cell_info. "CHANGING pt_cell TYPE lvc_t_cell.
DATA lt_cell TYPE lvc_t_cell WITH HEADER LINE.
CALL METHOD gr_alvgrid->get_selected_cells
IMPORTING
et_cell = lt_cell[].
LOOP AT lt_cell.
WRITE : lt_cell-col_id , lt_cell-row_id.
ENDLOOP.
* MODIFY pt_cell[] from lt_cell[].
ENDFORM. "cell_info

*&---------------------------------------------------------------------*
*& Form set_col
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM set_col .

DATA ls_cellcolor TYPE lvc_s_scol.

LOOP AT gt_list.
IF gt_list-price GT 500.
ls_cellcolor-fname = 'PRICE'.
ls_cellcolor-color-col = 5.
ls_cellcolor-color-int = 1.
ls_cellcolor-color-inv = 0.
APPEND ls_cellcolor TO gt_list-colors.
else.
ls_cellcolor-fname = 'PRICE'.
ls_cellcolor-color-col = 3.
ls_cellcolor-color-int = 1.
APPEND ls_cellcolor TO gt_list-colors.

ENDIF.
MODIFY gt_list.
ENDLOOP.

ENDFORM. "set_col

*&---------------------------------------------------------------------*
*& Form set_col1
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM set_col1.
data : ind type sy-tabix,
indx type sy-tabix.
loop at gt_list1.
ind = sy-tabix / 2.
indx = sy-tabix - ind.
if indx eq ind.
gt_list1-rcol = 'C500'.
endif.
MODIFY gt_list1.
endloop.

ENDFORM. "set_col

*FORM TITLEBAR.
*SET TITLEBAR 'TITLE'.
*ENDFORM.

*double click on TITLE and write ur title


Designed By Srikanth Vadlamani

Other Useful Link :
Object Oriented ALV-Sample program to insert Logo in ALV
ALV Function Module
Customize ALV grid layout at run time
Download ALV grid Control Tutorial
Understand ALV report ( Just Copy and paste )
Dynamic selection on ALV at run time
Dynamic selection on ALV at run time
Click Here to Read More !!!!

Object Oriented ALV-Sample program to insert Logo in ALV

*&---------------------------------------------------------------------*
*&amp;amp; Report Z_OOALV_LOGO
*&
*&----Sample Program using ooalv­­­-----> by SrikanthV-------------------*
*&
*&
*&---------------------------------------------------------------------*

REPORT z_ooalv_logo.

****DECLARATION FOR LOGO INSERT
CONSTANTS: cntl_true TYPE i VALUE 1,
cntl_false TYPE i VALUE 0.
DATA:h_picture TYPE REF TO cl_gui_picture,
h_pic_container TYPE REF TO cl_gui_custom_container.

DATA: graphic_url(255),
graphic_refresh(1),
g_result LIKE cntl_true.



DATA: BEGIN OF graphic_table OCCURS 0,
line(255) TYPE x,
END OF graphic_table.

DATA: graphic_size TYPE i.

CALL SCREEN 100.

*&amp;---------------------------------------------------------------------*
*& Module PICTURE OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE picture OUTPUT.

DATA: l_graphic_xstr TYPE xstring,
l_graphic_conv TYPE i,
l_graphic_offs TYPE i.

CALL METHOD cl_ssf_xsf_utilities=>get_bds_graphic_as_bmp
EXPORTING
p_object = 'GRAPHICS'
p_name = 'EDS'"IMAGE NAME - Image name from SE78
p_id = 'BMAP'
p_btype = 'BCOL'
RECEIVING
p_bmp = l_graphic_xstr
EXCEPTIONS
not_found = 1
OTHERS = 2.


graphic_size = XSTRLEN( l_graphic_xstr ).
CHECK graphic_size > 0.

l_graphic_conv = graphic_size.
l_graphic_offs = 0.

WHILE l_graphic_conv > 255.
graphic_table-line = l_graphic_xstr+l_graphic_offs(255).
APPEND graphic_table.
l_graphic_offs = l_graphic_offs + 255.
l_graphic_conv = l_graphic_conv - 255.
ENDWHILE.

graphic_table-line = l_graphic_xstr+l_graphic_offs(l_graphic_conv).
APPEND graphic_table.

CALL FUNCTION 'DP_CREATE_URL'
EXPORTING
type = 'image'
subtype = cndp_sap_tab_unknown " 'X-UNKNOWN'
size = graphic_size
lifetime = cndp_lifetime_transaction "'T'
TABLES
data = graphic_table
CHANGING
url = graphic_url
EXCEPTIONS
* dp_invalid_parameter = 1
* dp_error_put_table = 2
* dp_error_general = 3
OTHERS = 4 .
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
EXIT.
ENDIF.

CREATE OBJECT h_pic_container
EXPORTING container_name = 'LOGO'.
CREATE OBJECT h_picture EXPORTING parent = h_pic_container.

CALL METHOD h_picture->load_picture_from_url
EXPORTING
url = graphic_url
IMPORTING
RESULT = g_result.



ENDMODULE. " PICTURE OUTPUT


Designed By Srikanth Vadlamani

Other Useful Link :
ALV Function Module
Customize ALV grid layout at run time
Download ALV grid Control Tutorial
Understand ALV report ( Just Copy and paste )
Dynamic selection on ALV at run time
Dynamic selection on ALV at run time



Click Here to Read More !!!!

Learn Object Oriented ABAP online and Download Tutorial

Learn Object Oriented ABAP online and Download Object Oriented ABAP Tutorial



http://www.savefile.com/files/768258

Click Here to Read More !!!!

Object Oriented method

Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. Historically, a program has been viewed as a logical procedure that takes input data, processes it, and produces output data. The programming challenge was seen as how to write the logic, not how to define the data. Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).


The first step in OOP is to identify all the objects you want to manipulate and how they relate to each other, an exercise often known as data modeling. Once you've identified an object, you generalize it as a class of objects (think of Plato's concept of the "ideal" chair that stands for all chairs) and define the kind of data it contains and any logic sequences that can manipulate it. Each distinct logic sequence is known as a method. A real instance of a class is called (no surprise here) an "object" or, in some environments, an "instance of a class." The object or class instance is what you run in the computer. Its methods provide computer instructions and the class object characteristics provide relevant data. You communicate with objects - and they communicate with each other - with well-defined interfaces called messages.

The concepts and rules used in object-oriented programming provide these important benefits:

The concept of a data class makes it possible to define subclasses of data objects that share some or all of the main class characteristics. Called inheritance, this property of OOP forces a more thorough data analysis, reduces development time, and ensures more accurate coding.
Since a class defines only the data it needs to be concerned with, when an instance of that class (an object) is run, the code will not be able to accidentally access other program data. This characteristic of data hiding provides greater system security and avoids unintended data corruption.
The definition of a class is reuseable not only by the program for which it is initially created but also by other object-oriented programs (and, for this reason, can be more easily distributed for use in networks).
The concept of data classes allows a programmer to create any new data type that is not already defined in the language itself.
One of the first object-oriented computer languages was called Smalltalk. C++ and Java are the most popular object-oriented languages today. The Java programming language is designed especially for use in distributed applications on corporate networks and the Internet.

Other Useful Link :

Learn Object Oriented ABAP online and Download Tutorial

Click Here to Read More !!!!