Help

atuldalvi

atuldalvi

Member
Can any one tell me which type of coding is this ?

{utility/genrunas.i &ProgName = ""menu/getmenu.p""
&APPLICATION = ""SOE""
&progParams = "(INPUT tt-config.initprog,
OUTPUT TABLE tt-menu)"}
 
this is an include file which uses preprocessors. If you look into the include file you will find what values are entered by means of the preprocessor.
If all else fails, preprocess the source to see what is happening ;-)

cASPER.
 
That is what is known as "bad coding".
Click to expand...

You should see our application then, 12 years ago this seemed pretty fancy :D

Casper
(almost ready in getting rid of these preprocessor-include-mambo-jambo)
 
Hi Everyone,

I have a related question to this:

I saw many ways when passing parameters to include file.

Code: 
{include.i 
      &msg = indicate} /*no variable defined for this*/
or
{include.i 
      &msg = "indicate"}
or
{include.i 
      &msg = 'indicate'}
or
{include.i 
      &msg = ""indicate""}

I used first example in my shop but later when i try this in local environment then it throws error. Somewhere in the documentation i read that sending parameters to INCLUDE file is depends on structure of include file but i unable to understand this structure.

Thanks & Regards!
Rajat.
 
You should have the value in quotes unless it is a variable. Double quotes will pass quotes through to the include, which you probably shouldn't be doing. Better yet, don't use includes. There are those who like them for providing language extensions but a whole lot of us who think they should just be avoided. One of the most common persistent uses in modern code is for a temp-table definition that needs to appear in both a calling and called compile unit, but I would argue that all access to the temp-table should be made in a single unit, i.e., the OO principle of encapsulation.
 
Includes with options like this hark back to the good old days of v8 IIRC when a lot of features we enjoy today weren't available. IMO they should only be used for legacy code today. As tamhas says, you should look at alternative, more easily maintainable options today. I've had to maintain code with includes and compile time options and it is an absolute nightmare!
 
There is a nother misunderstanding: You are not passing or sending parameters to an include file. Include files and their parameters get resolved at compile time. In effect, using this technique, the compiler will produce different results for different parameters. So what you get is a compiler error not a runtime error.

As pointed out by Cringer includes files is a technique that is almost as old as the ABL ( or 4GL as it was called a the time ) is. Over time coding techniques have evolved and so has the language. It is about 15 years or more when peristent procedures and dynamic object where introduced to the language. It is even some 5 years when Progress added OO features to the language. From that perspective you should abandon include files wherever you can. There might be some exceptions to the rule ( as always ) where you have a standard include that is used all over the place in your application. But logic that was put in include files should be better encapsulated in either methods of classes or at least internal procedures or functions of persistent procedures.

Heavy Regards, RealHeavyDude.
 
You must log in or register to reply here.
Back
Top