Passing Arguments in a include File

Posted by Krishna Kumar on 05-Oct-2016 01:21

Hi,

We need to pass arguments/parameters in an include file. The purpose of these arguments will be to comment a block of code in the include file. So some portion of code in the include file will be commented in case the argument is passed to include file.

 

I tried writing one .i file and one .p file . 

commentcall.p

{inc/comment.i &opencomment="/*" &closecomment="/*"}

 

comment.i

 

{&opencomment}

Display "Code Has Not Been Commented" .

{&closecomment} 

 

However it's not working. It throws an error Än open comment "/*"  was found but no close string.

 

Please let me know how to fix the issue.

 

Thanks,
Krishna

 

 

 

All Replies

Posted by Krishna Kumar on 05-Oct-2016 01:23

Below is the correct code for -

commentcall.p

{inc/comment.i &opencomment="/*" &closecomment="*/"}  

Please check and advice

Posted by cSocaciu on 05-Oct-2016 01:54

I do not recommend the handling that you suggested.

Use something like this instead.

{inc/comment.i CONV = "TRUE"}  

In the commentcall.p use the sintax:

&IF DEFINED(CONV) = 0 &THEN

/* code 1 */

&ELSE

/* code 2 */

&ENDIF

Posted by goo on 05-Oct-2016 01:59

I am not sure what you want to do, but I don't think the compiler will let you do that. What you could do is to use &Scope-define or &global-define to tell the compiler not to include some code:

mytest.p

&global-scope CommentCodeA

{test.i $myVar="Test" "Hello world"}

&undefine CommentCodeA

-----------------------------------------------------------------

test.i

&IF NOT DEFINED(CommentCodeA) &THEN

 MESSAGE "{1}"

     VIEW-AS ALERT-BOX INFO BUTTONS OK.

&ENDIF

MESSAGE 'Test - {2} '

   VIEW-AS ALERT-BOX INFO BUTTONS OK.

Is this what you want to accomplish ?

//Geir Otto

Posted by Krishna Kumar on 05-Oct-2016 02:23

I tried  writing below piece of code

&IF DEFINED(CONV) = 0 &THEN

DISPLAY "inside uncommented block".

&ELSE

DISPLAY "inside commented block".

&ENDIF

However irresepective of TRUE/FALSE whatever you pass it always display "inside uncommented block".

{inc/comment.i CONV = "TRUE"}  

Posted by cSocaciu on 05-Oct-2016 02:28

Try {inc/comment.i} for the other branch.

Posted by goo on 05-Oct-2016 02:38

&scoped-define Comment true

{test.i}

&undefine Comment

--------------------

test.i

&IF {&Comment} = FALSE &THEN

 MESSAGE "{1}"

     VIEW-AS ALERT-BOX INFO BUTTONS OK.

&ENDIF

MESSAGE 'Test - {2} '

   VIEW-AS ALERT-BOX INFO BUTTONS OK.

Posted by ske on 05-Oct-2016 05:39

> However it's not working. It throws an error An open comment "/*"  was found but no close string.

This is because after a comment was started by {&opencomment}, no more include parentheses are recognized until _after_ the comment ends. So you can't end a comment with {&closecomment}.

To use this trick (for those who are curious), you need to have a fixed "*/" in the included file, and then you can use include parentheses to control in which of several places in the code you want to open that comment. If it opens before some code, that code will be commented out. If it opens right before the fixed "*/", then it will be a no-op.

Posted by ske on 05-Oct-2016 05:43

> However irresepective of TRUE/FALSE whatever you pass it always display "inside uncommented block".

DEFINED(CONV) checks whether the CONV has been defined by some previous define directive, not whether it has the value TRUE or FALSE.

Posted by Marco Aurelio on 05-Oct-2016 07:03

Hi, we have the inverse but I think it would work for you.

--> ifdef.i

{coment.i {1} " " "/*"}

--> endif.i

{coment.i {1} "/*"}.

--> coment.i

{2}

--> teste.i

{ifdef.i {1}  }

IF {1} <> "" THEN DO:

 MESSAGE " param passed " {1} VIEW-AS ALERT-BOX.

END.

ELSE DO:

{endif.i {1} } */  /*<---- this needs to be after endif,i*/

   MESSAGE " param not passed" VIEW-AS ALERT-BOX.

{ifdef.i {1}  }

END.

{endif.i {1} } */  /*<---- this needs to be after endif,i*/

--> teste.p

DEF VAR a AS CHAR INIT 'passing parameter !!!! '.

{teste.i  }

PAUSE .

{teste.i a }

hope it helps.

Marco Aurelio

Posted by Thomas Mercer-Hursh on 05-Oct-2016 09:27

Please don't do this.  It is intentionally obscuring your code, which is never a good idea.

Posted by Patrick Tingen on 06-Oct-2016 00:45

Agree with dr Hursh. This is old school include usage. VERY old school in fact. In the nineties of the previous century we used this because we had no alternative. Nowadays we have in the form of preprocessors.

But I would even suggest using no includes for program logic at all. Includes are wonderful for defining temp-tables, but not for program logic. They create coupling of programs that increases the complexity of your code. There are more modern possibilities in the language nowadays.

Posted by Peter Judge on 06-Oct-2016 05:56

This is an excellent rule of thumb.
 
Sadly there are times when you have to break the rule but first follow it.

This thread is closed