Invoking same procedure from differnt files.

[smart.Object]

Hello everyone... me again .

I have a procedure which does exactly the same thing, but needs to be invoked from different programs (lets call them x and y (y runs only from within x)). I would like to create either a .include or .p (I don't know what exactly is the difference) file that would be called by those programs.

What I did was just cut out the procedure from x and stuck it into a separate .i files, replacing the whole procedure with a call to this file. It runs fine from x, but doesn't even access it from y. Is there some kind of access permissions I have to set for the whole .i file? Or I cannot simply invoke a .i file from two programs?

Then I tried creating a .p file, defining all the variables and trying to pass it the reference number needed to perform the procedure. But I am not sure if I defined shared variables and shared buffers correctly b/c it doesn't want to run from either program.

here is the first segment of the .p code:

{incl\globals.i}
{incl\sysvar.i}.

/* shared varaibles */
DEF shared var hold-order-no as char no-undo.
def shared var hold-oper-no as int.
def shared var hold-dept-no like dept.dept-no.
DEF shared VAR FtString as char.
def shared var hold-seq-no as int.
DEF shared VAR MyDecimal AS DEC init 25.34.


/* system variables */
def var next-line as int init 1.
def var Vrise72 as dec.
def var vtempang as dec.
def var vtempch as dec.
def var vtempa as dec.
def var vtempb as dec.
def var angleradians as dec.
def var vdecresult as dec.
def var sinvrise72 as dec.
def var cosvrise72 as dec.
def var sinvchord72 as dec.
def var cosvchord72 as dec.
def var vsinradinch like est-prop.vradinch.
def var vcosradinch like est-prop.vradinch.
 def var varctyp as char.

/* buffers */
def shared buffer x-est-routing for est-routing.
def shared buffer x-est-bom for est-bom.

is this even legal to declare buffers like that?
Also I changed the type of variables inside the x to "new shared"... is this correct..

Thanks in advance for any input.
GB

 

[4GLNewbie]

Uhm i dont know the problem with your code ( it depends on how it is used on the other files ), but why don't you use PARAMETERS?

You create a .p file with your code and then call it with RUN statement from the others programs giving the correct INPUT params to the procedure?

Something like: RUN myprocedure ( INPUT [paramin1], [other input parameters], OUTPUT [paramout1], [other output parameters] ).

I hope i have been clear.

 

[sphipp]

Generally, if you use shared variables then you have to define them as NEW somewhere and then define them again in your program.

It is easier to put them in an include file and pass a parameter to it to allow it to be NEW or not.

So, if you have a file myvars.i

DEF {1} shared var hold-order-no as char no-undo.
def {1} shared var hold-oper-no as int.
def {1} shared var hold-dept-no like dept.dept-no.
DEF {1} shared VAR FtString as char.
def {1} shared var hold-seq-no as int.
DEF {1} shared VAR MyDecimal AS DEC init 25.34.

you would use it in the calling program {myvars.i "new"} and in the called program {myvars.i} . That helps to ensure that the variables are defined the same way and makes it easier to use shared variables in your code.

The difference between a program and an include file is that an include file is designed to make up part of a program. An include file is a snippet of code that can be used in multiple programs. Include files are used to share code between routines and are often used to store variable definitions and common code, but Super Procedures tend to make a lot of their functionality obselete.

You are probably making it too complicated by using shared buffers. Either use input parameters/shared variables or find the records in your code.

As to y not seeing the program, that might be to do with where the program is. If it is in the PROPATH then x and y should see it. If not then you have to give it a relative or absolute pathname for Progress to find the file.

 

[tamhas]

Yes, but if you are creating new code here, don't use shared variables. Don't even think about it unless you are making small mods in existing code and it is a big problem to change. Parameters have been the right way to pass values for a long time now, so better to do it correctly and not set yourself up for issues in the future.

If you use parameters, then you can test your code with a small test harness that passes in selected parameters and displays the result. You can then be confident this will work in the midst of more complex code.

I would also avoid include files for most purposes. Much better to encapsulate code in .p or .cls files.

 

[4GLNewbie]

As it explains Tamhas, using parameters it is also a good way to test your code without modifing other programs ( if you are working something that already existed )..

I suggest you try to use that way to develop your code, it will be easy to maintain in the future also because you will hardly modify something in other programs that will influence this specific program flow..

This is what i understood in the few months since i have begun to use progress..

Regards.