2016-02-18 1 views
0

Je veux changer ma barre de titre dans un dynpro lorsqu'une méthode de classe spécifique est déclenchée. J'ai donc pensé que je pouvais appeler une fonction dans mon rapport, où se trouve mon dynpro, lequel change utilise le 'SET TITLE' pour changer le contenu de la barre de titre.Appel (Report-) Fonction de la classe Méthode

Est-ce possible et comment exactement? Ou y a-t-il même un meilleur moyen?

Merci!

+0

Pourquoi? Quelle est la raison commerciale derrière tout cela? La réponse dépend de la raison réelle pour cela ... – vwegert

+0

Custom class ou standard? De quel rapport s'agit-il? – Suncatcher

+0

Mon colleauge a créé un rapport (programme exécutable) qui appelle toutes ses méthodes d'une classe. Cela devrait devenir un logiciel pour un compteur. Mais c'est juste une pratique maintenant. Par exemple, si quelqu'un payait ses affaires, la barre de titre devrait recevoir un nouveau numéro pour un nouveau client. Donc, le problème est que, dans le rapport actuel, il ne se passe vraiment que des méthodes d'appel. Et je ne sais pas comment changer la barre de titre d'une méthode de classe. – Dyrdek

Répondre

1

Utilisez SET TITLEBAR pendant le traitement PBO - peu importe si elle est utilisée à partir d'une méthode, d'un FORM ou du module directement. Je recommande d'avoir une seule instruction SET TITLEBAR qui est toujours appelée au même point dans le flux de contrôle au lieu de jeter le code avec les instructions SET TITLEBAR pour une meilleure facilité de maintenance.

0

Récemment, j'ai dû implémenter quelque chose de similaire, j'ai donc défini une hiérarchie de classes où j'ai créé une classe abstraite avec une méthode 'CALL_DYNPRO'. Cette méthode est destinée à charger un dynpro spécifique dans les classes concrètes. Donc, en fonction d'une action que j'ai définie en interne, je génère l'instance appropriée, puis la méthode 'CALL_DYNPRO' charge le dynpro que j'ai créé avec leurs propres statuts et titres gui.

Ce qui suit est plus ou moins le code que j'ai créé.

********************************* The abstract class 
class lc_caller definition abstract. 
    public section. 
    methods: call_dynpro. 
endclass. 

class lc_caller implementation. 
    method call_dynpro. 
    endmethod. 
endclass. 

********************************* The concrete classes 
class lc_caller_01 definition inheriting from lc_caller. 
    public section. 
    methods: call_dynpro redefinition. 
endclass. 

class lc_caller_01 implementation. 
    method call_dynpro. 
    call screen 101. 
    endmethod. 
endclass. 

class lc_caller_02 definition inheriting from lc_caller. 
    public section. 
    methods: call_dynpro redefinition. 
endclass. 

class lc_caller_02 implementation. 
    method call_dynpro. 
    call screen 102. 
    endmethod. 
endclass. 

********************************* Factory  
class caller definition. 
    public section. 
    class-methods call importing i_type type char01 
       returning value(r_instance) type ref to lc_caller. 
endclass. 

class caller implementation. 
    method call. 
    data: caller1 type ref to lc_caller_01, 
      caller2 type ref to lc_caller_02. 
    case i_type. 
     when '0'. 
     create object caller1. 
     r_instance = caller1. 
     when '1'. 
     create object caller2. 
     r_instance = caller2. 
     when others. 
    endcase. 
    endmethod. 
endclass. 

start-of-selection. 
data obj type ref to lc_caller. 
obj = caller=>call('0'). 
obj->call_dynpro(). 

Ceci est le code à l'intérieur des PBO.

Dynpro 101

module status_0101 output. 
    set pf-status 'FORM1'. 
    set titlebar 'VER'. 
endmodule. 

Dynpro 102

module status_0102 output. 
    set pf-status 'FORM2'. 
    set titlebar 'TRA'. 
endmodule. 

Si demain je dois appeler un autre dynpro créer et coder ensuite la classe en béton pour le charger.

Très simple et fonctionne très bien.

Espérons que ça aide.