file_1.p ... ... and file_2.i &GLOBAL-DEFINE WEBCTEXT 1 DEF SHARED VAR g-ses-id AS CHAR NO-UNDO. is relative at "NEW" parameter or at &GLOBAL-DEFINE WEBCTEXT 1?! I learn in this week the language roules.
&GLOBAL-DEFINE WEBCTEXT 1
DEF SHARED VAR g-ses-id AS CHAR NO-UNDO.
is relative at "NEW" parameter or at &GLOBAL-DEFINE WEBCTEXT 1?!
I learn in this week the language roules.
Keeping us busy here...
refers to the first parameter to the include file. So it get's interpreted as "NEW".
To access WEBCTEXT you need to using .
It is NEW. This is an old structure for using a since include file with SHARED variable declarations such that the NEW can be supplied in the top level program and it can be omitted in all other references.
However, this is a construct which was popular in the 1980s. You should avoid any use of shared variables in favor of parameters. Some people make an exception for global shared, but I don't; I put those values in superprocedures or singleton objects.
Generally, I would also avoid include files. They seemed like a good idea once upon a time, but they can cause a lot of problems in making sense out of a system. In particular, they lead to the bad practice, particularly with variable definitions, of stuffing a large number of definitions into the file, all that might be used anywhere and then one can't tell which ones are actually used in a particular program without a lot of work. There is almost always a better way.
TNX for answer, a day i save and print all the answer tha you users patiently give to me, TNX for all the time spand for me.
There is almost always a better way.
Generaly or ther's a master way like the chose of the index?
"Better way" is not a single best practice, but a whole family of them. E.g., one of the common uses for include files is shared variable definitions or the slightly more modern definition of a temp-table which is going to be passed as a parameter. In the former case, one should be using parameters instead of shared variables and the naming of the variables in one .p should be independent of the naming in the other .p so there really is no need for an include file. With the temp-table definition, it is a bit more complicated, but my general recommendation is to encapsulate the temp-table in one procedure or object rather than to pass it as a parameter at all. This is a little more straightforward using OO.
If one starts with the principles of good program structure, one will rarely be led to want to use an include file. It is mostly copying what others have done that gets people into using them, I believe.