ABAP Coding

Home / SAP / Archive by category "ABAP Coding" (Page 8)

Web Dynpro – Adding an Icon in a Dynamic Table Column

Here was another fun task I wanted my new ABAP Web Dynpro to be able to add an icon in a dynamic table column.  Again, I expected this to be easy…  well, not as much as I figured, so I thought it might be something you could use.  (and I’m looking for some fun things to write about).

 *** again, start with getting the reference to the table, and then getting all the columns
l_table ?= view->get_element( ID = ‘TB_XXX’ ).
lt_cols = l_table->get_columns( ).
LOOP AT lt_cols into wa_cols.
*** in this example, I want column DOC_ICON to show an icon, rather than text.
IF lv_col_fld = ‘DOC_ICON’.
*** for the correct column, you need to assign an image, rather than the standard text.  In this ***example, I just needed to tell it what to bind for the value (remember, I had this value already,
***so I just need to assign the correct context node.
lv_image = cl_wd_image=>new_image( bind_source = ‘XXX.DOC_ICON’ ).
*** this is the magic.  Telling it what cell editor to use what sets it as text vs. an Image.
Wa_cols->set_table_cell_editor( LV_IMAGE ).
ENDIF.
ENDLOOP.

And that’s the magic…  Hope this can make your life easier…  Because like the catchphrase goes, I learn things the hard way, so you don’t have to.

Web Dynpro – Changing Dynamic Table Header

Well, this strangely was a lot tougher than I expected.  I just wanted the ability to change the column headers based on my own descriptions (or perhaps by language).  Dynamic table header changes took more research than I originally expected, so here’s what I found…  Hope if can help you…

*** get the reference to your table
l_table ?= view->get_element( ID = ‘TB_XXX’ ).
*** get all of the columns so you can name them as you like
lt_cols = l_table->get_columns( ).
LOOP AT lt_cols into wa_cols.
*** Get the text you want to add to the column headings and assign to lv_col_text
lv_col_fld = “column name”.
l_col_hdr = wa_cols->get_header( ).
l_col_hdr->set_text( lv_col_text ).
wa_cols->set_header( l_col_hdr ).
ENDLOOP.

Happy coding =)

Web Dynpro – Creating a Dynamic Table

I hope you’re not getting tired of Web Dynpro.  I will get back to the function SM and VC stuff soon, but lately I’ve been consumed with converting my Rapier product to ABAP Web Dynpro, so as you can guess, that’s where all of my fun learning experiences have been.  For those you tired of this, I promise to be back in functional side again soon.  I’m not finished with my conversion, so that means its time to add new functionality…  Today it’s creating a dynamic table.  For everyone else, I hope you find this useful 🙂

So, to set the stage, a lot of the Rapier functionality is based on dynamic tables.  The idea is that you can define how you want your input and output fields to work.  That means, I needed to be able to build a dynamic table.  I had to a lot of online hunting to pull all this together, but finally got it working how I wanted.  Thought I’d share this with y’all.

I implemented all of this in the wdomodifyview method.

*** Coding for Dynamic Table
DATA: lt_col TYPE cl_abap_structdescr=>component_table,
col like LINE OF lt_col,
struct_type TYPE REF TO cl_abap_structdescr,
table_type TYPE REF TO cl_abap_tabledescr,
node_info TYPE REF TO if_wd_context_node_info,
node TYPE REF TO if_wd_context_node,
tab_XXX TYPE REF TO data,
row_XXX TYPE REF TO data,
l_root TYPE REF TO cl_wd_uielement_container,
l_node TYPE REF TO if_wd_context_node,
l_table TYPE REF TO cl_wd_table,
lt_cols TYPE CL_WD_TABLE_COLUMN=>TT_TABLE_COLUMN,
wa_cols TYPE REF TO CL_WD_TABLE_COLUMN,
l_col_hdr TYPE REF TO CL_WD_CAPTION,
lv_col_text TYPE string,
lv_col_fld TYPE string.
data: lv_image TYPE REF TO cl_wd_image.
data: nd type ref to if_wd_context_node,
nd_list type WDR_CONTEXT_CHILD_MAP,
wa_list TYPE WDR_CONTEXT_CHILD.
data: n type i,
idx TYPE i.
FIELD-SYMBOLS: <table> TYPE table,
<row> TYPE data,
<fs_col> TYPE any,
<fs_col2> TYPE any.

*** build table columns
loop at XXX into wa_XXX where visible = ‘X’.
col-name = “anything”.
*** note, if you use describe_by_name, LV_COL_FIELD must be a table-fieldname combination,
*** then the method will find the data type.  I wasn’t able to find any way to just enter in the date
*** type.
col-type ?= cl_abap_datadescr=>describe_by_name( LV_COL_FLD ).
append col to lt_col.
endloop.

*** build dynamic structure
struct_type = cl_abap_structdescr=>create( lt_col ).
*** returns meta information about the node
CALL METHOD wd_context->get_node_info
RECEIVING
node_info = node_info.

*** this simply checks to see if the node already exists to stop potential short dumps.  This is
***important depending on where you implement this code, and if it runs multiple times.
nd_list = wd_context->get_child_nodes(  ).
READ TABLE nd_list with KEY name = ‘XXX’ TRANSPORTING NO FIELDS.
if sy-subrc <> 0.
*** creates info object and adds it as a lower level node      CALL METHOD node_info->add_new_child_node(
exporting
name = ‘XXX’
static_element_rtti = struct_type
is_static = abap_false
RECEIVING
child_node_info = node_info ).
endif.
*** child node of lead selection or specific index
CALL METHOD wd_context->get_child_node
EXPORTING
name       = ‘XXX’
RECEIVING
child_node = node.
clear n.
n = node->get_element_count( ).
if n = 0.
*** Return RTTI object for sturcture type of static attributes
CALL METHOD node_info->get_static_attributes_type
RECEIVING
rtti = struct_type.
endif.

*** now you have all of the context nodes created…  next up, creating the table.
*** create table
table_type = cl_abap_tabledescr=>create( p_line_type = struct_type ).
FREE tab_xxx.
CREATE DATA tab_xxx TYPE HANDLE table_type.
ASSIGN tab_xxx->* to <table>.
refresh <table>.

*** create lines
FREE row_configequiphis.
CREATE DATA row_xxx TYPE HANDLE struct_type.
ASSIGN row_xxx->* to <row>.

*** populate the values for the table.  Don’t worry too much about this implementation.  This is
***uses dynamic tables to populate the structure.  What you need to do is populate all of your
***rows and columns to make a table that will be bound to your new table.
LOOP AT wd_this->it_xxx INTO wa_xxx.
loop at wd_this->it_xxx into wa_xxx.
ASSIGN COMPONENT wa_xxx-yyy OF STRUCTURE <row> to <fs_col>.
if sy-subrc = 0.
ASSIGN COMPONENT wa_xxx-yyy OF STRUCTURE wa_xxx to <fs_col2>.
if sy-subrc = 0.
<fs_col> = <fs_col2>.
endif.
endif.
endloop.
APPEND <row> to <table>.
ENDLOOP.

*** bind the table
node->bind_table( new_items = <table>
set_initial_elements = abap_true ).

*** build table
l_root ?= view->get_element( ‘TC_TABLE’ ).
l_node ?= wd_context->get_child_node( ‘XXX’ ).

cl_wd_dynamic_tool=>create_table_from_node(
ui_parent = l_root
table_id = ‘TB_TABLE’
node = l_node ).

There’s all the magic.  It’s as simple as creating the nodes, populating those nodes, and then binding them to the table.  Sounds easy right???  as you can see from the code above, it was a lot more complex than I imagined.  Hope this makes life easier for you.

 

Web Dynpro – Logoff Button

This one turned out to be pretty easy, but it sure did take some effort to get to that point…  I guess that’s the irony of it all.  ha ha ha.  So, here was my goal.  I have a web dynpro application that uses a generic user to login as the default.  Then you login with an internet user.  Now the trick that had me stumped for a while was how do I log off the internet user, and reset the application back to the initial login screen the default user.  So this is my solution for creating a logoff button that would reset the transaction back to my original internet user.

I’m sure this sounds easy to any of you Web Dynpro experts out there, but it had me hunting through textbooks, google and my few Web Dynpro contacts.  Finally came up with the trick…  so here you go.

First, in your main window, you need to create an outbound exit plug.  Be sure to give it a parameter of URL.

I recommend setting a context element to hold the intial URL.  You’ll need it later.

Next, in the main view, give your button or however you want to execute the log off procedure.

Once you call the log off procedure, you simply need to take the initial URL and add ‘?logout_submit=true’ to the end.

Here’s an example:

CONCATENATE lv_e_url ‘?logout_submit=true’ INTO lv_e_url.
data: L_REF_MAIN_WINDOW type ref to IG_XXX.
L_REF_MAIN_WINDOW =   WD_THIS->GET_XXX_CTR( ).
L_REF_MAIN_WINDOW->fire_LOGOFF_EXIT_plg( URL = lv_e_url ).

Note:  XXX is the main window name.  LOGOFF_EXIT is the exit plug name.

See what I mean…  it really is that easy =)  good luck.

 

 

ABAP – Suppressing BAPI Messages

I just learned a fun trick when using a BAPI.  I’ve been designing a dynpro transaction and I used a BAPI to pull some information.  What I discovered is that certain BAPI’s have some messages that automatically get displayed, and also caused a weird behavior of leaving the screen (without requesting it.  ha ha ha).  So today I talk about suppressing BAPI messages within a method or form.

Well, I learned a quick fix for this, when calling a function, add the DESTINATION = ‘NONE’.

this will suppress the messages of the BAPI, and just execute the data retrieval I was looking for.

This is a quick one…  I hope you find it useful.

ABAP – Refresh ALV Grid

I recently had to go through and add a button to refresh ALV grid in a custom transaction.  I initially expected this to be easy.  And looking back, it actually is pretty easy, if you kept your program modular.  However, I had to handle things differently than I expected.

I thought I would need to do something with the refresh button that comes with the standard ALV grid.  However, after a some extensive google digging, I couldn’t find anything that told me how I could do that.  Everyone else took care of the issue by creating their own button.  Here’s the basic steps to do it yourself.

You will need to setup the following 2 handlers.  I created a local class to house these methods.  You can take care of it anyway you prefer.

DATA: l_event_receiver_grid TYPE REF TO lcl_event_receiver.
(where lcl_event_receiver is the local class)

SET HANDLER l_event_receiver_grid->on_toolbar_add_button
FOR grid.
SET HANDLER l_event_receiver_grid->on_user_command
FOR grid.

For the add_button:

DATA: ls_toolbar TYPE stb_button.
MOVE ‘ZRFO’ TO ls_toolbar-function.
MOVE ICON_REFRESH TO ls_toolbar-icon.
MOVE ‘Refresh’ to ls_toolbar-quickinfo.
MOVE ‘ ‘ TO ls_toolbar-disabled.
APPEND ls_toolbar TO e_object->mt_toolbar.
this adds a button that looks exactly like the standard refresh button.  You can feel free to play around with the look and feel, but this will get your started.

In the on_user_command, you will need to look at sy-ucomm, and find when it matches ZRFO (in this example).

refresh grid table.
rebuild the grid table

then call the display method.  For me, I uised the set_table_for_first_display method.  So updating the grid table and calling this is enough to perform the refresh.

This will give you a great start if you want to add a refresh button your custom transaction.

I hope you find this helpful.

Web Dynpro – Using the Code Wizard

Well, I believe I mentioned it in a previous post, but I’m still struggling with the differences between BSP and Web Dynpro.  AWDP is a fun tool, and I like it the more I get into it, the learning curve is still killing me 🙂  Today the Code Wizard is one of my recent discoveries.

For example, I figured out the whole context model, why you do it, etc.  But I had a hell of a time figuring out how to get the value into or out of the context variables I created.  I finally discovered the Web Dynpro Code Wizard…  which, with a few clicks, generated all of the code I needed to read or set the context node.  So simple, yet I hunted on-line for an hour, and eventually found it in the ABAP Web Dynpro book I purchased.

It turns out, you click the wizard button, select the node you want to work with, then tell it if you want to read it, set it, append it, etc…  hit the green check mark.  And magically, all the code I needed was inserted into my method.  Who knew it could be that easy.  LOL.

Anyway, if you’re playing with AWDP, take advantage of the code wizard.  it won’t create your whole application, but it’s great at the little stuff =)

thanks for reading,

Mike

Web Dynpro – Dynamically Changing the Web page Title

Well, as I begin digging into my first ABAP Web Dynpro program, I”m slowly starting to figure out what is going on.  Expect some posts on AWDP in the future, since it’s now becoming my latest hobby =)  Today’s challenge was dynamically changing the web page title.

tip number 1.  If you want to change the title of the web page, you know the title that shows up on the tab of Windows Explorer, you can’t do this dynamically until you have Netweaver 7.02 or later.  If you have at least this basis release, you can use the following command:

  wd_this->wd_get_api( )->get_component( )->get_application( )->set_window_title( wd_this->lv_title ).

Now the bad news is that if you don’t have 7.02 or later, you can only change it in the application description.

So, I just need to start tracking these little tidbits as I go.  As always, I’m learning things the hard way so you don’t have to.

Thanks for reading,

Mike

Web Dynpro – Initial Challenges

Wow, I have to admit, I thought after going through a book and doing some exercises, I’d have no problem converting a BSP application to Web Dynpro.  Was I ever wrong!!!  The learning curve is steeper than I expected.  It is very different, and admittedly, I haven’t wrapped my head around all the concepts of how it works.  But, if you know me, you know that I just keep plugging till I figure it out =)

Initially, I set the goal of “simply” creating the initial login page.  Even that has been a challenge.  I haven’t quite figured out how I can layout a page the way I want.  For example, I’ll have a common header and footer for every page.  I found an application that seems to do just that (or close enough for my initial go-around), but digging through it to figure out what’s happening has been challenging.  I’ve been battling a cold as well, so that certainly makes my brain a little more foggy than usual, but I expected it would just fall into place…  well, not there yet, but I’m still hacking away.

Second was to recreate my navigation tree on the left side of the application.  This again is used for every single page, and pretty much drives the entire application.  This again I thought would be simple.  I did it in BSP, how hard could it be?  Well, pretty hard it turns out.  I’m working to understand the “Context” right now, which if I understand it correctly, is like variables, so my next mission is figure out how to populate the Context variables I created.  The funny thing is that once I grasp the Web Dynpro concepts, it should be a piece of cake because I’ll be able to reuse all of the ABAP methods I originally created for the BSP, just move the data to Web Dynpro…  This will be an ongoing post topic for me, so if you happen to be a Web Dynpro guru, and you recognize something, throw me a bone in the comments.  I’d really appreciate it.

Anyway, that’s all for today.  Thanks for reading,

Mike

ABAP – Using the SCREEN structure

lately in my development activities I’ve spent a lot of time developing screen.  One of the pieces of our latest product is a high end configuration screen to give the user as much control as they want for the final product.  Now as many of you know, I have no formal ABAP training, but it’s amazing what you can learn from books, the internet, and just good old trial and error.  Well, one of the things I’ve been using a lot is screens.  If you’re a developer, I’m sure this is old hat, but to me this has become invaluable.  In a previous post, I talk about how important it is to be consistent in naming your screen elements.  Today I’m going to step back and talk a little about the SCREEN structure.

For me, some of the big things I wanted to be able to dynamically control is if the element is visible in SE51 and if you can change it.  For this, there are simple fields in the SCREEN structure:

  • Invisible – setting this to 1 make the field disappear from the screen
  • input – setting this to 1 makes the field editable.

Now the big thing to remember is that if you are doing something dynamic, like I’ve done using tables to control the settings, you must lock the changes in.  Locking them in is very simple.  MODIFY SCREEN.  That simple statement, locks your changes in.  If you forget it, you’ll spend a lot of time being frustrated, wondering why the element isn’t behaving like you’re telling it to (believe me, I know this from experience.  ha ha ha).

Thanks for reading,

Mike