×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

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

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

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

(OP)
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

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

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

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

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:

CODE -->

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

CODE

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

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

(OP)
Chriss,

Quote:

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

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

(OP)
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

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

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

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

(OP)
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


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

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

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

(OP)
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

CODE -->

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 smile)

Rajesh






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

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

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

(OP)
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

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

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

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

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

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

(OP)
Chriss,

Quote:

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

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

(OP)
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

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

(OP)
Mike,

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

Rajesh

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

(OP)
Chriss

Quote:

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

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

Quote:

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

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

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

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

Quote (Mike Lewis)

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

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

Quote:

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

That would be a valid solution. It would make dealing with changes to individual functions quite easy, although it might make it difficult to keep track of them all. But worth considering as an option.

Thinking about the whole question, I'm inclined to think that if I was in Rajesh's place, I wouldn't bother with any of this. I would keep all my procedures, and everything else, in the main EXE, in the usual way. When a procedure needs to be changed, I would simply rebuild the EXE and distribute it to the users. That would seem to be no more difficult than distributing an APP or PRG. But no doubt Rajesh has considered all this.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

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

I wonder if there is another solution: Keep the code of the relevant procedures in a memo field in a DBF, and have the program execute it at run time using EXECSCRIPT(). I've not had much experience of doing that. Would it work? Are there any catches?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

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

Mike, about your latest idea. I guess you would get the same criticism as I got for a VFP COM Server that allows execution of any VFP code you pass into it. Because data can be edited, that also means it's prone to misuse. I think if the VFP runtime is there, someone who wanted to execute malicious VFP code could do so without such a security weakness. You could also compile PRGs to FXPs and provide them as binary memo or blob data. And provide means like a cryptographically signed code, if that matters.

But I wouldn't yet give up on the concept of an APP. There are at least two well-working projects that use APPs, Foxy Previewer and GDPlusX. Both are initialized with a DO App. And both also generate objects in VFPs _Screen, for different reasons. A new report engine could by documentation also only provide an app to set to the system report variables, they still chose to initialize this all by a DO FoxyPrevier.APP.

Both App solutions don't bring us forward in the usage of an APP as a function library or even a container for multiple such libraries. As they don't provide functions to use from within that APP, the usage of them is dome by using the object added to the _SCREEN in both cases. Foxypreviewr also sets the system report variables and can use them in this specific case to intercept REPORT FORM commands, as that's what causes calling the foxypreviewer.app by means of the VFP 9 report engine structure to work with APPs anyway. You can't generalize this for a function library unless you would make a set of functions a set of methods of an object you also by default generate as a _SCREEN member.

I can imagine other reasons than the update process to separate this, there could be a separate responsibility for a set of functions acting as a library or API that's binding to be used by every other VFP project in a company. And then you could provide PRGs and VCXes to be included in any VFP EXE for other developers and source code version control makes it easy to distribute all this to teams of developers, but you could also decide to centralize providing such functions with APP files instead and make it mandatory to integrate them and not the source code of them.

I get back to my idea of using the main PRG of the APP project to make any necessary initializations and then be able to use anything from within the Lbrary.APP with the only prerequisite to DO Library.APP. Doing the necessary SET PROCEDURE and SET CLASSLIB within the APPs' main.prg is technically working. After that you can use functions and classes with simple calls and with CREATEOBJECT(), as VFP knows where to find everything, just the build process is blind to such a construct.

Chriss

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

(OP)
Mike, Chriss,

Great discussions! Thanks a lot!

Let me write a small application with all these features & requirements in question to check and satisfy myself. I will come back here with my observations.

Yes, my idea of keeping separate PRGs in an APP is what Chriss thought. Each PRGs are for different purposes and the procedures in them are related to those purposes. In this case, maybe I could have thought about having separate APP for them (more control?).

For ease of call and avoiding confusions/build errors etc, as Mike said, to keep all included in the Exe would be perfect. But in our scenario, the content of APP is mostly conditional, client dependent etc etc. So, at one place if I keep a particular version, another place it could be another version. As far as a client don't have any problem with their version, the need to upgrade to the new version. It goes something like this. Still, I would like revising my logic decisions and overall application structure for better control and maintanability.

Rajesh

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

(OP)
Mike, Chriss,

You both say it wouldn't work the way I have done. But, it appears it works at my end.
So, let me check if I had done something, maybe forgotten, so that the application works fine smile).

Rajesh

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

RAjesh,

I said it works for a prg that's main in the app, but not for a prg that's not main. And as there can only be one main prg in a project, your idea of adding multiple PRGS would fail, so an app can only provide what an FXP could also provide.

Besides that, the usage of DO something IN An.App does not allow to get the return values. Unlike DO FORM, where you can have a TO clause, the DO command itself has none. So it is important to get to the usual syntax you use for calling a function returnvalue = function(x). which still puzzles VFPs build process about finding the function, though.

Chriss

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

(OP)
Chriss,

Yes, you have a point. I understand.
Let me go through all these and check various cases to conclude on an appropriate method.

Rajesh

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

Chris, you raised a good point about security, especially in connection with my idea of using EXECSCRIPT(). But I think the same consideration would apply to any of the methods we have discussed here. Just as a knowledgeable person could inject malicious code into a DBF, so could they create a malicious APP or PRG, and use it to overwrite the legitimate one.

Clearly a point that needs to be kept in mind.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

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

I think I found a solution, I just don't like it.
If you don't just add the app into the project of the EXE, but also all the PRGs and set them to excluded, you get no build error. If the app project is more complex this could easily become a maintenance problem, though it becomes obvious when you build the EXE and get compile errors again, that you forgot to add in some prg.

I am a bit reluctant here to accept that as a solution, as it should be sufficient for VFP to add the app. It should even be sufficient to have a DO of the APP in code, which makes the build process add the APP to the EXE project. That's fine, but nothing else from the app project should be necessary to be project item of the EXE project.

It makes me think on the inverse problem, that the build process finds things in excluded project items and accepts calls to code within them also if no app is also present that indeed has that function or prg. And indeed, that's the case. If you exclude a PRG but still use it in the EXE, running the EXE gives a runtime error "excluded.prg does not exist". So in the end I found a solution based on a bug to easily fool the build process about the existence of code. I'm even quite sure it's a "known bug".

This bug obviously has to be accepted as there will be no new VFP version, but it means a lot of caution to not accidentally exclude something and rely on that causing a build error, it does actually not do so. Using that bug as a solution seems like a bad idea, though.

I can imagine to write a project hook that you use in the app project which then has to know the companion EXE project and will simply add any item during the build process to the EXE process as excluded item. Then the build of the EXE causes no build errors. But that would not solve it for the situation I thought of, that an app becomes a mandatory library to be integrated into several EXE projects by different developers of a team, as they will need the full sources of the app just to include them as excluded in their EXE projects. That's crazy.

Chriss

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close