2021 Feb 11 4:38 PM
Hello, guys.
The following piece of code can be activated:
IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.
ENDIF.
But the one below cannot. It throws the message Error in logical expression.
IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ).
ENDIF.
Does anyone know why and what can be done so code can be activated?
The code is just an example.
The _posting_allowed( ) is a method which return TRUE or FALSE.
2021 Feb 12 9:05 AM
Yeah, this has got to be a bug then. Any input, horst.keller?
I did some more testing and theorizing here... Documentation links:
The relevant syntax of the IF statement in this case is
IF log_exp_if.And the COND is
COND type( WHEN log_exp_cond THEN result_cond ).I can't see that COND should not be allowed and working in a log_exp, and it is working when we use '= abap_true' as part of the log_exp_if like this:
IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.But when we remove the '= abap_true' part of the log_exp_if, we get 'Error in logical expression.
My guess is that the parsing or linting of the logical expression log_exp_if is failing when it has no comparison expression in it and there is another logical expression log_exp_cond inside it. It somehow mixes them both together...
Same result also when I wrap the COND in a VALUE operator...
This works in steampunk environment, so it's either fixed in later releases or it's only working there because reasons...
2021 Feb 11 4:59 PM
Patrick, in newer versions you can actually say something like "IF A.".....if A translates to a boolean....you can also use methods that return a boolean such as "IF me->check_is_valid( somevalue )." .
2021 Feb 11 5:00 PM
Predicative method calls are available since 7.40 SP08. (I did not know by heart - I had to look that version number up in this blog post).
I guess you're on a version earlier than that...
2021 Feb 12 8:15 AM
2021 Feb 12 9:06 AM
2021 Feb 18 12:37 PM
The problem occurs with both "IF" and "CHECK" (and Value, as you say, but there I have always been able to bypass it somehow without being annoyed enough to make a fuzz out of it...).
The following is not possible :
But this is :
So it is as you say, there seems to be some kind of mix up in the parser. So either Horst will come up with an answer here or Alejandro will log it for us with SAP and we'll go the offiical way.
2021 Feb 11 5:01 PM
I thought so too, but I didn't find anything about it in abapdocu. So, from which version it is available?
Just tried on an S4H1909 and it doesn't activate ;).
2021 Feb 12 9:05 AM
Yeah, this has got to be a bug then. Any input, horst.keller?
I did some more testing and theorizing here... Documentation links:
The relevant syntax of the IF statement in this case is
IF log_exp_if.And the COND is
COND type( WHEN log_exp_cond THEN result_cond ).I can't see that COND should not be allowed and working in a log_exp, and it is working when we use '= abap_true' as part of the log_exp_if like this:
IF _posting_allowed( i_par = COND #( WHEN 1 = 1 THEN 1 ) ) = abap_true.But when we remove the '= abap_true' part of the log_exp_if, we get 'Error in logical expression.
My guess is that the parsing or linting of the logical expression log_exp_if is failing when it has no comparison expression in it and there is another logical expression log_exp_cond inside it. It somehow mixes them both together...
Same result also when I wrap the COND in a VALUE operator...
This works in steampunk environment, so it's either fixed in later releases or it's only working there because reasons...