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]

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

 

[Mike Lewis]

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

 

[Chris Miller]

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

 

[Rajesh Karunakaran]

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

 

[Rajesh Karunakaran]

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

Rajesh

 

[Chris Miller]

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

 

[Rajesh Karunakaran]

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

 

[Mike Lewis]

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

 

[Chris Miller]

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