Project Compiler suddenly stopped including newer files 3

[Joe Crescenzi]

Hi Everybody,

I've been developing xBase programs since dBase II in the early 80s and all of a sudden I'm having the craziest problem, the project manager is skipping files on my most critical project and I have no idea why.

The strange this is that this is the same program I've been continuously developing since 1985, and I've compiled newer versions of it at least once a week without a single problem.

Now, when I compile the program, all the newer PRG procedures, and SCX forms are NOT in the EXE file... and are NOT in the Project File.

I'm wondering if anyone else has seen this problem before.

I assumed the project file was corrupt, so I created a new one and just added the main PRG file, expecting it to rebuild the whole project, but it didn't. In fact based on opening the project file directly as a table, the newer project file literally skipped nearly 600 files that otherwise were in the original, and it's basically saying in the error file that the files were not found. All the files are in the same directory as the project file.

I even tried compiling it on an entirely different computer, so it's not a corrupted version of VFP.

I'm starting to wonder if the compiler somehow hit some sort of limit to the number of files in either the directory or the project file itself?

There are over 4400 files in the directory, including about 1400 PRG files, 400 SCX files and a ton of report and other files.

My workaround so far was to add some of the missing files by hand to the project file, but I worry that I won't know which files are missing without either waiting for a customer to say "there's an error saying procedure xys is not found".

I'm thinking of writing a script to look at all the PRG and SCX filenames that are in the director, but not in the project file so I can know which ones to add, but that's not not the best option because there are other prgs and scx files that aren't actually called, so I'd need to start maintaining my own list of files that can be excluded.

This problem really has me confused. I've been developing code for 40 years ands it's like somebody suddenly telling me up is now down, or blue is now red. There's just no reason for the project to think files are missing when they're right in the same directory.

Any thoughts?

 

[Joe Crescenzi]

I've allowed the Project Manager to add virtually every file in my project for decades because I've always kept 100% of my files in one folder and as you know, I never need to rebuild the project from scratch, but it's good to know it will work if the project file ever becomes corrupt or if I build a derived version for some reason.

I've reached a point where everything works regardless of the development machine I use. None of my code is ever stored on drive C:, which is another story, but it allows me to write code from anywhere and compile on any computer, including on-site at a client's office.

I almost always compile on a copy of code on C:, but that's a copy to a fresh folder 100% of the time. If the distribution is a "keeper", I'll archive that folder and it will be wiped before the next build.

 

[Mike Lewis]

I have nothing to add to this thread - except to say that it is impressive that a single thread should attract over one hundred replies.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Haha, unfortunately you can't sort threads by most posts.

There was a lot we both went through and mJindrova deserves more stars for clearing up the core issue I never would have thought of. I know the simple source code protection is to remove PRGs and delete source code memos in SCXes, VCXEs etc., is there more protection? It's possible to use Refox to protect against refox decompilation and encrypt source code, but then you also need a decryp initialization.

I should perhaps try with the XFRX demo. It was new to me an app within a project can crash the build process, that's for sure.

Indeed trying with xfrx225-9, adding the xfrx.app from the unzipped download into a project doesn't cause a build to crash, also not with a SET PROCEDURE TO it. Either that mechanism of protection was changed or there was something else.

Chriss

 

[mJindrova]

Chris,

Try add to your code next line:

loSession = XFRX('XFRX#INIT')

mJindrova

 

[Chris Miller]

Well, I did

Set procedure to C:\...Downloads\xfrx225-9\xfrx.app
loSession = XFRX('XFRX#INIT')

Build still does not crash, sorry

Chriss

 

[Joe Crescenzi]

Indeed trying with xfrx225-9, adding the xfrx.app from the unzipped download into a project doesn't cause a build to crash, also not with a SET PROCEDURE TO it. Either that mechanism of protection was changed or there was something else.

That sums it up entirely. In my case it was SET PROCEDURE TO XFRX. I didn't specify prg or app, but they were both present.

In the end, it's hard to imagine how any single PRG, FXP, or APP can throw a monkey wrench into the compiler.

When all the dust settled, I went back to re-read the XFRX documentation and realized that mJindrova is actually managing the documentary website, so perhaps Martina will update some of the documentation with some warnings about making sure you don't call it directly when using the compiled vs source version and what the effect will be.

Another factor is that the source version does not ship with a compiled App, so there are essentially 4 ways it could be implemented.

1. As a trail App.
2. As a paid pre-built App or FXP.
3. As paid source code integrated directly into your code.
4. As paid source code, where you compile the parts and use it as #2.

Knowing what I know now, I would've loved to just download the source and compiled versions separately, then implemented it using the instructions for a paid, pre-built app. That seems the safest and easiest thing. Since they don't compile the source version, it would be best to keep the source separate and have clear instructions of how to build the functional equivalent of #2, so all the instructions from that point would be uniform.

I think I'll ask Martin, the developer, to review this thread and consider distributing the compiled version along with the source in the future.

 

[Chris Miller]

Well, changing it to xfrx without .app still doesn't change it, there also is no xfrx.prg present in xfrx225-9, the only prgs including those in subfolders are locclass.PRG, source.prg, xfrx[highlight #FCE94F]proxy[/highlight].PRG,runreport.PRG, and custDet.prg.

Don't know about you, but I'm fine with the app not causing that problem anymore.

Chriss

 

[mJindrova]

1. As a trail App.
It's a demo version (xfrx.app) - all outputs.

2. As a paid pre-built App or FXP.
It's a xfrx.fxp prebuilded for VFP 6+7, VFP 8 and VFP 9 (three packages) and each customer - all outputs or pdf only.

3. As paid source code integrated directly into your code.
It's a xfrx.prg.
a) You can compile for VFP 5, VFP 6, VFP 7, VFP 8, VFP 9, VFP A 32bit and VFP A 64bit.

4. As paid source code, where you compile the parts and use it as #2.
a) Package creator don't know what variant customer need - 3a).
b) XFRX can be include in destination exe/app or exclude as fxp or app.
c) Customer can build separatly xfrx.app with XFRXPreview inside xfrx.app

I prefer XFRX outside destination exe/app, because it's simpler change it.

mJindrova