Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Synchronous User Interaction in Instance-Method

Former Member
0 Likes
1,248

Hey Guys!

I got a problem getting information by user synchronous.

To make it understandable I abstracted the problem a little:

I have a class 'player'. It has an attribute 'name' and a method 'get_name'.

In get_name i want to ask the actual user for his/her name. A dialogue should open with a text-field and an ok-button.

(Solvable with DD_Documents -> no Problem as far).

But then I want to save the given value in text-field in the 'name'-variable.

This is a problem: Not because of getting the data out of the input field but because of the flow-control!

I know I could write a method in the same class to react to the interaction and save the variable. But if I want to use one or more players in a program, it does not wait until the variable is set to go on.

I do not want to go on with the code in the method as long as the user didn't press ok.

Can I wait for an event in a method?

Hope you get my problem!

Thank you for your help!

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
1,176

Hi Wolfgang,

I assume the events used are from classes CL_GUI_DIALOGBOX_CONTAINER and CL_DD_BUTTON_ELEMENT. Seems these events will be triggered asynchronously in the order the user clicks on the popup.

Using Function Module TRM_POPUP_TEXT_INPUT instead of class CL_DD_DOCUMENT could be easier and synchronous for such requirements. Also check function modules like POPUP_TO_GET_VALUE and CC_POPUP_STRING_INPUT.

Regards,

Varun

8 REPLIES 8
Read only

Ryan-Crosby
Active Contributor
0 Likes
1,176

Hi Wolfgang,

You should be able to register an event within your class 'player' that you can then RAISE when the user clicks 'OK' to save their name. All you would need to do is register a handler for the event in a local class for your program and you could then add any event specific logic that you want to have happen when they click 'OK'. (It is commonly used for example in the ALV class CL_GUI_ALV_GRID).

Regards,

Ryan Crosby

Read only

0 Likes
1,176

Thank you for your reply.

This is what I've already tried: Throwing an event from my player, if button is clicked/entered or window is closed. In this event I transfer the input-value. This works fine so far, but resolves in asynchronous communication.

But I do not want an asynchronous communication between calling program and player.

Because if I wanted the name of 5 players, the flow-control would become little complex. Synchronous communication would catch me the players name wit one line.

I want the player's method to ask for name and then (after input) transfer the entered value:

player1->get_name( ed_name = ld_name ).

Thank you very much!

Read only

0 Likes
1,176

Hi Wolfgang,

Do you have a snippet of your code where it is working asynchronously? If I can see what you have maybe I can help propose something that would result in a synchronous communication to your player.

Regards,

Ryan Crosby

Read only

0 Likes
1,176

Hey hey!

Of Course:


method ask_for_name.
  data: ld_txt(255) type c.
  ld_txt = id_text.

  create object mo_dbox_cont
    exporting
      width  = 400
      height = 80.

  create object mo_dd_doc.

  mo_dd_doc->add_form( importing formarea = mo_dd_form_a ).
  mo_dd_form_a->add_text( text = 'Dein Name:' ).
  mo_dd_form_a->new_line( ).
  mo_dd_form_a->new_line( ).
  mo_dd_form_a->add_input_element( importing input_element = mo_dd_f_ie ).
  mo_dd_form_a->new_line( ).
  mo_dd_form_a->new_line( ).
  mo_dd_form_a->add_button( label = 'OK' ).

  mo_dd_doc->merge_document( ).

  set handler dbox_close for all instances.
  set handler dd_btn_clicked for all instances.
  set handler dd_ie_entered for all instances.
  mo_dd_doc->display_document( reuse_control = 'X' parent = mo_dbox_cont ).
endmethod.

the handlers do all throw the same event (inluding the name in a parameter).

On this I react with another method:


method dialogue_input.
   me->name = ed_name.
endmethod.

Then I have another class that uses players:


method main.

  create object s1.
  create object s2.
  create object s3.

  s1->ask_for_name( ).
  s2->ask_for_name( ).
  s3->ask_for_name( ).

write:/ s1->name.
write:/ s2->name.
write:/ s3->name.

endmethod.

Here comes my Problem: Three dialogues open and no names are written on the screen -.-

In the end I am looking for sth. like a selection-screen which kind of "stops" the program until response.

Thank you!

Read only

0 Likes
1,176

Hi Wolfgang,

I would try this kind of approach and see if it will solve your problem (I'm assuming your EVENTS are raised in the method display_document):

First, I would cut the following lines from the method ask_for_name:

set handler dbox_close for all instances.

set handler dd_btn_clicked for all instances.

set handler dd_ie_entered for all instances.

Second, I would add this DEFINITION of a local class & object declaration (I guessed on parameter & class names):


** Local class definition for event receiver
CLASS lcl_event_receiver DEFINITION.

  PUBLIC SECTION.
    METHODS:

    handle_dbox_close
      FOR EVENT dbox_close OF zcl_player_class
        IMPORTING e_name,

    handle_dd_btn_clicked
      FOR EVENT dd_btn_clicked OF zcl_player_class
        IMPORTING e_name,

    handle_dd_ie_entered
      FOR EVENT dd_ie_entered OF zcl_player_class
        IMPORTING e_name.

ENDCLASS.                    "lcl_event_receiver DEFINITION

DATA: g_event_receiver TYPE REF TO lcl_event_receiver.

Third, I would make the following changes in your main method:


method main.
 
  CREATE OBJECT g_event_receiver
  create object s1.
  create object s2.
  create object s3.
  SET HANDLER g_event_receiver->handle_dbox_close FOR ALL INSTANCES.
  SET HANDLER g_event_receiver->handle_dd_btn_clicked FOR ALL INSTANCES.
  SET HANDLER g_event_receiver->handle_dd_ie_entered FOR ALL INSTANCES.
 
  s1->ask_for_name( ).
  s2->ask_for_name( ).
  s3->ask_for_name( ).
 
write:/ s1->name.
write:/ s2->name.
write:/ s3->name.
 
endmethod.

And lastly, insert the implementation for each of the handler methods:


*&---------------------------------------------------------------------*
*&       Class (Implementation)  lcl_event_receiver
*&---------------------------------------------------------------------*
*        Event receiver for player class
*----------------------------------------------------------------------*
*---------------------------------------------------------------------*
*       CLASS lcl_event_receiver IMPLEMENTATION
*---------------------------------------------------------------------*
*
*---------------------------------------------------------------------*
CLASS lcl_event_receiver IMPLEMENTATION.
  METHOD handle_dbox_close.
    ...
  ENDMETHOD.

  METHOD handle_dd_btn_clicked.
    ...
  ENDMETHOD.

  METHOD handle_dd_ie_entered.
    ...
  ENDMETHOD.
ENDCLASS.               "lcl_event_receiver

Regards,

Ryan Crosby

Edited by: Ryan Crosby on Nov 8, 2011 9:50 AM

Read only

Former Member
0 Likes
1,177

Hi Wolfgang,

I assume the events used are from classes CL_GUI_DIALOGBOX_CONTAINER and CL_DD_BUTTON_ELEMENT. Seems these events will be triggered asynchronously in the order the user clicks on the popup.

Using Function Module TRM_POPUP_TEXT_INPUT instead of class CL_DD_DOCUMENT could be easier and synchronous for such requirements. Also check function modules like POPUP_TO_GET_VALUE and CC_POPUP_STRING_INPUT.

Regards,

Varun

Read only

0 Likes
1,176

Thank you Ryan, still asynchronus and all three screens popping up together. Assigning does not work at all now because of the registration of the event handler for all instances.

Thank you Varun, this is another approach but exactly what I needed!

Read only

0 Likes
1,176

I would say Varun has the right approach... I was not aware that those dialog methods were asynchronous but I know I have used at least one of those FMs for a popup. I believe it will process in a "blocking" mode such that only one will display until the user has input and then it would move to the next call.

Regards,

Ryan Crosby