AppBuilder uib_is_running

Hello Tom,

A possible way is to check for one of the environment variables that are defined for the OpenEdge session when running within OpenEdge Architect.

For example, the ECLIPSE_WORK environment variable is defined for the OpenEdge session associated with a project and for launch configurations.

The ABL_LAUNCH_MODE is set for launch configurations where a new OpenEdge session is started. It is set to "run" or "debug" depending on the mode.

Depending on whether the code is only used in r-code compiled in Architect or not, a way to improve performance would be to set an ABL variable once and then query the variable. Also, even though these variables are not expected to change, having the test in just once place protects against changes.

Hi Edsel,

Is there a way to evaluate an environmet variable in a pre-processor expression?

Tom

Isn't that a case of expecting a compile time action to know a run time condition?

Yes, that's exactly right.

Which is why I expect that the suggestion can't work.

In the AppBuilder, an actual line of code was added to define a preprocessor that could be evaluated.

Hello Tom,

I have another suggestion.

Sorry that my previous suggestion was oriented to detect the OpenEdge session at runtime and not at compile time which was your original question.

(For some reason I considered that you wanted a "like" solution which was using r-code.)

As you have probably found out, the OS-GETENV environment variable cannot be used from a processor statement. (I think that this could be logged as an enhancement.)

As you have mentioned, the AppBuilder actually writes a line of code.

Example:

&Scoped-define UIB_is_Running C:\OpenEdge\WRK102a\p98709_Untitled.ab

The AppBuilder runs a temporary file. In Architect, the Run uses the actual file and the .r would be used if it exists. (By default OpenEdge Architect compiles source code into r-code. R-code is used in components such as the Debugger and the Class Browser.)

A key point here is that the preprocessor only applies to the instance of the program that is called (the temporary program) and the program would behave in a different way when it is called from another program.

Here is another suggestion which tries to address the issue: how to specify parameters or have a different behavior for a program when run from within Architect.

Use one launch configuration to use the proxy program as the startup program and use $ or as the session startup parameter.

The Launching options would need to be changed to always launch the previously launched application.

The proxy program then can check $ or and call an existing or generated program, perhaps, a table can be used to determine the program to run or the type of program to run, based on whether it is class or .w file.

I hope that this helps.

Thanks,

Unfortunately, none of these suggestions have the simplicity and ease of use of the AppBuilder. I do have a suggestion that would require (I think) a minor enhancement to Architect.

Allow an optional run-time argument to be passed to the procedure being run. Run-Time arguments can be evaluated in a preprocessor (I just oried).

Here's a brief code sample

/* foo.p */

&IF "" = "foo" &THEN

DEF VAR xxx AS INT.

&ELSE

DEF INPUT PARAMETER xxx AS INT.

&ENDIF

If I run this as

run foo.p "foo".

it runs properly, if anything but "foo", it complains about mismatched parameters.

If it were an option in the launch config, or elsewhere, to "Pass Architect_Is_Running as an argument", then the problem would be solved. This would also, of course, force the run of the .p or .w, not the r-code.

Thoughts?

Tom

Hello Tom,

Using runtime arguments is good suggestion. It forces a compile of the program. (It is also possible that the application is not actually using .)

Please log an enhancement for this.

I guess that a possible approach would be to change the wrapper program that Architect already uses _debuglauncher.p and pass the desired value as a runtime argument.

Note: This could also be done with the wrapper program previously mentioned but changes would be needed to the launch configuration.

It appears that debuglauncher.p calls adecomm/runcode.p.

Do you know where I can find the source for _runcode.p?

Thanks,

Tom

Never mind.

I found it in the src version of adecomm.pl.

Made a few quick mods, compiled and deployed, works great.

Since _runcode.p is used by both the AppBuilder and Architect, the change works equally well on both.

Tom

Hi Tom,

I've been having the same issues as you it would seem.

I've been snooping around in the adecomm.pl file.

I've managed to extract it with the extractpl.bat file but inside it only contains .r files.

Is there any chance that you could provide a guide to how you were able to resolve this?

Thanks for your help.

Oliver

The .pl files you want are in \src

These contain actual source code.

I did find problems when modifying _runcode.p. The dictionary and data admin tools seem to use it as well and didn't like passed arguments.

Here's snippet of how I changed it. This means that to have compatibility in both architect and the AppBuilder your pre-processor needs to look something like

&IF "" = "Architect_Is_Running" OR defined(uib_is_running) <> 0 &THEN

/* Changes to _runcode.p*/

isArchitect = OS-GETENV("ABL_LAUNCH_MODE") EQ "run".

IF v_RunPersist = FALSE THEN DO:

IF isArchitect THEN

RUN VALUE( p_RunFile ) "Architect_Is_Running".

ELSE

RUN VALUE( p_RunFile ).

END.

ELSE

DO:

/* Run the user's file persistent. */

IF isArchitect THEN

RUN VALUE( p_RunFile ) PERSISTENT SET p_hProc "Architect_Is_Running".

ELSE

RUN VALUE( p_RunFile ) PERSISTENT SET p_hProc.

Thanks,

I've done that and now my newness to Progress and OpenEdge is shining through as I don't know how to turn the adecomm folder back into a procedure library.

Sorry for the bother but if someone could explain this to me it would be grand.

Thanks again

Oliver

There is no need. When you run the extract, it only extracts the code from the .pl and leaves the original file intact. I wouldn't delete the adecomm folder though, as there are files in there that are not in the .pl file.

But do I not need to put my amended _runcode.p file back into the library?

No, in fact it is best NOT to put it in the library. Rather put it in a directory that is in the PROPATH before the adecomm.pl so it gets picked up before the version in the .pl.

Ah!

Thank you

That makes sense!