Abap 使用ID以编程方式获取文本符号

有没有办法在运行时以编程方式获取文本符号的值

场景是，我有一个调用函数模块的简单报告。我在变量

LV_MSG

中收到类型为

CHAR1

的导出参数。这表示程序中创建的特定状态消息，例如

F

（失败）、

X

（匹配）或

E

（错误）。我目前使用

CASE

语句打开

LV_MSG

，并用消息的简短描述填充另一个变量。这些描述作为文本符号维护，我在编译时使用

text MS#

检索，其中#与

LV#u MSG

的可能返回相同，例如

text MSX

的值为“找到精确匹配”

现在，在我看来，整个

CASE

语句都是不必要的，因为我可以将ID为

'MS'+LV_MSG

（伪代码，将使用

串联

）的文本符号的值分配给我的描述变量。现在我的问题是如何在运行时根据文本符号ID的字符串表示找到文本符号。这可能吗

---

如果是这样的话，我的代码看起来会更干净，在功能模块中添加新消息时，我不必更新我的实际代码，因为我只需要添加一个新的文本符号。但是这种方法会更快吗？或者实际上会降低报告的性能吗？

我个人可能会定义一个域，并使用域的固定值来表示这些值。这样，您甚至可以绕过字符串连接。您可以使用功能模块

DD\u DOMVALUE\u TEXT\u GET

轻松访问域值的语言相关文本

要访问程序的文本元素，请使用功能模块，如

READ\u text\u elements

---

请注意，像这样的泛型编程肯定会降低程序的速度。如果值很少改变，我不明白为什么一个简单的

CASE

语句不如一些通用的文本访问

希望我能正确地理解你的意思，但还是这样吧。这是有可能的一个小技巧，所有的文本符号在报告中被定义为变量在程序中（与名称文本abc，其中abc是文本ID）。因此，您可以使用以下选项：

data: lt_all_text type standard table of textpool with default key,
      lsr_text    type ref to textpool.

"Load texts - you will only want to do this once
read textpool sy-repid into lt_all_text language sy-langu.
sort lt_all_Text by entry.

"Find a text, the field KEY is the text ID without TEXT-
read table lt_all_text with key entry = i_wanted_text
     reference into lsr_text binary search.

如果您想要地址，可以添加：

field-symbols: <l_text> type any.

data l_name type string.
data lr_address type ref to data.

concatenate 'TEXT-' lsr_text->key into l_name.
assign (l_name) to <l_text>.
if sy-subrc = 0.
  get reference of <l_text> into lr_address.
endif.

字段符号：键入任意。
数据l_名称类型字符串。
数据lr_地址类型参考数据。
将“文本-”lsr\U文本->键连接到l\U名称中。
将（l_名称）分配给。
如果sy subrc=0。
将的引用获取到lr_地址。
恩迪夫。

---

正如vwegert所指出的，这可能不是最好的解决方案，对于错误处理来说，使用消息类或异常对象可能不是最好的解决方案。这在其他情况下也很有用，不过现在您知道该如何操作了。

您提出了一个很好的观点，域方法似乎是SAP的enum等效方法，并且将是我将来使用的方法。如果我想替换

案例

，这个功能模块似乎正是我所需要的。但是正如您所说的，这种方法在可读性和性能方面都有明显的缺点。如果您打算在DDIC中创建一些东西，那么最好使用消息类。它确实是一种比域更好的消息通信方式，因为您将获得错误类型和编号，并且在SAP中到处都支持它。@DW8Reaper:在那里分门别类，但消息类不是DDIC:-）的一部分。如果必须将文本映射到任意非数值，则消息类是不合适的。OP声明数据是从功能模块接收的-在这种情况下，您通常无法控制功能模块是否使用消息类。如果我的程序是只调用功能模块一次的简单报告，则消息类确实是首选。然而，在我的例子中，对于任意大的数据集中的每个记录，我调用我的函数模块一次。（

LV_MSG

然后标识底层操作的搜索深度。）该值将转换为文本并添加到内部表中，以便在批处理脚本中输出（该报告适用于高级用户），因此消息在这种情况下实际上不可用。感谢您提供此代码。正如你所说，这不是这种情况下的正确方法，但我认为这将是很好的参考，在未来。实际上，您使用的方法与vwegert提到的

READ_TEXT_元素

FM不同，后者似乎使用

LOAD REPORT

。