How to indicate the compiler that a procedure in an external APP is being used?

[Rajesh Karunakaran]

Hi all,

We have a procedure in an external APP file which is called from multiple codes in application. The .APP name is added to the project but tagged as Excluded. While building Project/Application, it gives error that "<our procedure name> Not Found" How do you indicate the Project/Application builder about this?

Rajesh

 

[Mike Lewis]

You need to add an EXTERNAL PROCEDURE command to your main program, specifying the name of the procedure in question. See the Help for more details.

Note that this only affects the compilation / build process. Your code must still be able to find the procedure at run time, which is usually done by adding the IN clause to the DO command.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

The EXTERNAL command is for that. But expermenting with it, if you call a prg that's in the app, adding the app itself is sufficient. If you call a proceddure within a PRG that is in the App, that is not found.

Say you have a procedures.prg in the app project which defines procedures with PROCEDURE definitions:

Procedure xyz()
   code
   Return something

Then VFP will not be able to find xyz().

Look at it from this point of view: If procedures.prg would be part of the EXE project you still would need to SET PROCEDURE TO procedures.prg before your code can call xyz(). And that's not available in the form SET PROCEDURE TO procedures.prg IN some.app, nor is it sufficient to SET PROCEDURE TO some.app, and also, unfortunately, it is not sufficient to have the app file in your exe project as a reference for the build to find xyz. You would need to add an xyz.prg in the app project that does

SET PROCEDURE TO procedures.prg ADDITIVE
RETURN xyz()

By the way, if a prg from the app is used, the build process will make that prg part of the EXE project, too. So in the end you'll use that prg embedded in the EXE. And if you do that construct with a prg containing procedures and then individual prgs that use SET PROCEDURE, the exe project will include both the individual prg and the procedure definition prg into the project of the EXE.

There are things easier to use of an app. Classes, for example, as you have the parameter for an app in NEWOBJECT(). And what you can program is DO something IN some.app WITH parameters, but that won't receive the return value, so it's only usable for procedures not returning values.

Chriss

 

[Rajesh Karunakaran]

Chriss,

If you call a proceddure within a PRG that is in the App, that is not found

Yes, this is my case.

However, let me try a few things to bypass this so that my build of application doesn't throw error.

Rajesh

 

[Rajesh Karunakaran]

Mike,

I know EXTERNAL but was not solving my problem (in fact, I'd assumed it wouldn't work that way).
And yes, even if build throws error, the application runs as you said.

Rajesh

 

[Chris Miller]

I think an elegant way is separating the procedures and functions of one such PRG into separate prgs.

If you don't want to go that far, you could add a main.prg of the app that does all necessary SET PROCEDURE and then later DO some.app, after which the individual procedures and functions become available. That works, unfortunately the build process still tells you it doesn't find these functions and procedures, although it does know you DO the app and it does know the main.prg of the app does SET PROCEDURE to PRGs including the function and procedure definitions. And if that all would be part of the EXE project it would be sufficient for the build process to understand these procedures and functions exst.

All in all, it's just another reason to not use such libraries of procedure/function definition PRGs.

Chriss

 

[Rajesh Karunakaran]

Hi All,

The procedures are in APP is because the content may change, not that frequently though.
If there are changes, I can copy the APP to the application folder so that next run will take up the changes.

Rajesh

 

[Chris Miller]

That's also possible, if the single functions are single prg files that are built into such an app. You don't lose that advantage when chaning the strucutre of the app project.
Apart from that, you can always ignore the build error as long as it all still works at runtime...
...and it does.

Chriss

 

[Rajesh Karunakaran]

Hi all,

Recap:
I have Actions.prg with multiple procedures one of them being "Procedure Action_1".
I compiled Actions.prg into an APP. I don't have a project for this but using a prg to temporarily create a project, compile to PRG into an APP and then delete the temporary project files.

I am calling Action_1 in one of the forms as in

DO Action_1 IN Actions.App

I have added Actions.App in the Applications folder of the Project.
But, when building an exe, VFP throws error that "Action_1" not found!
Recap end:

To check, I have added Actions.prg itself in the Progs folder of the project and tagged it as Excluded.
Now, VFP doesn't throw that error and builds the Exe.

However, even if the call is like "...IN Actions.APP", I wanted to check if Actions.prg is absent in application folder, does it trigger an error. I don't have it in my application folder anyway. But, to ensure, I renamed it to "__Actions.prg" (in it's actual source folder from where I added into the Project). Still my application runs the procedure from it.

This is what I observed from my experiments!
Got rid of the error!
(But I am not sure if it's going to fail in someway )

Rajesh

 

[Chris Miller]

To me that only works in terms of no build error. You can't call DO action_1 in actions.app if action_1 is a procedure within actions.prg, though. You have to have action_1.prg in the app project.



Chriss

 

[Rajesh Karunakaran]

Chriss,

Action_1 is a procedure in the Actions.prg. Actions.Prg is compiled to Actions.App and was added to project as Excluded APP.
This was there already.

The only change was to add Actions.Prg in Progs folder as Excluded.
'Excluded' is because I don't want to include it unecessarily but only to provide the source to VFP during compilation so that it can see there is actually a definition for the procedure call. This is what I think and not sure how VFP was considering it.

Anyway, I don't have the build error now and the Exe is working!

Rajesh

 

[Chris Miller]

Okay, I still don't see how

Do Action_1 In Actions.app will work, because you can only do a PRG in an App, you can't do a Procedure in a PRG in an App.
So you get no build error but "Procedure ACTION_1 is not found." at runtime. Don't you?


Chriss

 

[Mike Lewis]

Rajesh,

I might have misunderstood all this, but I don't see why you need an APP at all. You say it's becaue the procedures might change. I understand that in that case you don't want to have to rebuild the entire project. But wouldn't you get the same benefit by putting all the procedures in a PRG, and using SET PROCEDURE to point your program to it?

If you did that, you would still exclude the PRG from the build. You would compile it separately, and distribute it along with the FXP. When a procedure changes, recompile and redistribute.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Chriss,

So you get no build error but "Procedure ACTION_1 is not found." at runtime. Don't you?

No, it works!
(I even kept the Actions.Prg renamed so that the Exe can't find it)

Rajesh

 

[Rajesh Karunakaran]

Mike,

Yes, that also can be done.
But, I see that only change is FXP instead of APP. All others same, isn't it?

Also, I may include more PRGs (purposes wise) in the same APP later on.
Then I will have to provide multiple FXPs but if APP only one. Correct?

Rajesh

 

[Rajesh Karunakaran]

Mike,

By the way, why do you prefer a FXP to APP?
Is there any advantages kind of matter?

Rajesh

 

[Rajesh Karunakaran]

Chriss

So you get no build error but "Procedure ACTION_1 is not found." at runtime. Don't you?

The build doesn't show that "...Not Found" error and the first call of the Procedure from the APP did not show any problem.
Now, I will do a more deeper test by adding calls to different procedures in different places in applications.

Rajesh

 

[Mike Lewis]

Also, I may include more PRGs (purposes wise) in the same APP later on.
Then I will have to provide multiple FXPs but if APP only one. Correct?

No. You put all the procedures in the same PRG, and you use SET PROCEDURE to identify the PRG to your project. The important point is to exclude the PRG from the build. When a procedure is changed, recompile the PRG and distribute it, and its FXP.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

It doesn't work for me, but maybe because I don't have the Action_1 function in the main prg of my app. Yes, if I put it there, it works.

So try adding a second PRG with other functions/procedures and try to call them that way. The app file does not become a placeholder file for all files in it. So the syntax DO function in some.app only works if function is defined in the main prg of the app.

In the end, that means your idea to add more prgs will not work out that way and Mike has suggested the better way to add FXPs. To move the clutter away, you need to either store those FXPs into a subfolder of the application directory of the EXE or you find another way of calling an action (function/procedure) within a secondary PRG of an APP.

Chriss

 

[Chris Miller]

You put all the procedures in the same PRG

That's a possibility, but Rajesh might want to keep families of functions in separate PRGs and not merge them into one PRG/FXP. For sake of maintaining all the PRGs separately, for example. It's not impossible to maintain a large PRG and use Document View to navigate a long PRG like that. The granularity of the families is lost, though.

And for that matter, it would point back to the usual solution to have each procedure/function in a separate PRG instead.

You may do something fancy like pulling together all necessary functions and procedure into one PRG file with a project hook that does so in its beforebuild event. But how will it know which functions and procedures to bundle? By seeing what is added in the EXE project but excluded?

It may be best to return to usual solutions without an APP bundling several things, or you need another calling mechanism, I think.

Clearly, one advantage of the usual multi PRG solutions is that the build process adds them to the EXE project. It's not an advantage for a family of things you want to keep external, though. I bet someone would argue "so what? Then do build your EXE if you need changes." It's a valid point of view on this. The only advantage of a separate APP is that it can change even while an EXE is currently executed. But will it actually change what the EXE runs within the APP? If the APP has version2 of a function and the old version was already executed by the EXE during its process lifetime, would it pick up the new version or call the cached old version?
If you need to wat for the EXE to restart, then you could also update the EXE.

It may just be a bit easier to change an APP than changing an EXE, if the EXE is in the system Program Files directory and the APP could be in there or in the local appdata system directory instead of the application folder itself.

Chriss