Converting PJX > PJ2 > PJX Removes .SetMain("xxx.prg")

[ccantrell72]

Reproduced with the following

Downloaded ZIP of https://github.com/DougHennig/StonefieldDatabaseToolkit. Unzipped

Windows Explorer - Right Click - Send To - PJX to PJ2 File
Opened in Text Editor - Set Main there.

Right Click - Send To - PJ2 to PJX
Right Click - Send to - PJX to PJ2

Set Main removed - verified in Project viewer the main PRG is no longer set.

FYI - never opened any files with FP. Just converting 2 to bin and bin to 2.

[ccantrell72]

Here is the output of AI review.

Bug Analysis: Converting PJX > PJ2 > PJX Removes .SetMain() (#115)

Reproduction

Pure round-trip with no manual editing:

1. PJX -> PJ2 (binary to text)
2. PJ2 -> PJX (text to binary)
3. PJX -> PJ2 (binary to text again)
4. Result: .SetMain() is gone from the PJ2. MAINPROG not set in Project Viewer.

Occurs when the PJX's HomeDir (from the original developer's machine) is on a different drive than where the user runs foxbin2prg.

---

Root Cause: Format Mismatch Between .ADD() and .SetMain()

The Two Different Formats

.ADD() entries (line 18498) use bare filenames — no path processing:

.ADD('<<loReg.NAME>>')

Produces: .ADD('source\sdt.prg')

.SetMain() (line 18626) goes through GetPathFromHome which calls SYS(2014):

.SetMain(<<THIS.GetPathFromHome(m.loProject._MainProg, m.lcStr, "lcCurdir + '", "'", m.toFoxBin2Prg)>>)

What GetPathFromHome Does (line 18891)

lcReturn = SYS(2014, m.tcFilePath, m.tcProjPath)
Do Case
    Case m.toFoxBin2Prg.n_CheckFileInPath=2 AND !EMPTY(JUSTDRIVE(m.lcReturn))
        lcReturn = '"' + m.tcFilePath + '"'        && double-quoted format
    Otherwise
        lcReturn = m.tcPrefix + m.tcFilePath + m.tcSufix   && lcCurdir + 'file' format
Endcase

SYS(2014, 'source\sdt.prg', 'D:\dev\project\') resolves the relative filename against the current working directory. If the current dir is on C: and HomeDir is on D:, the result is a cross-drive absolute path with a drive letter. JUSTDRIVE() is not empty, so the double-quoted format is used.

The Hardcoded n_CheckFileInPath (line 18413)

toFoxBin2Prg.n_CheckFileInPath=2

This is hardcoded to 2 before any path processing, overriding any user configuration. It forces cross-drive detection for every conversion.

---

The Failure Trace

Step 1: PJX -> PJ2

PJX HomeDir = D:\dev\project (original developer's machine).
User runs foxbin2prg from C:\Downloads\project\ (different drive).

GetPathFromHome calls SYS(2014, 'source\sdt.prg', 'D:\dev\project\'):

• VFP resolves relative path against current dir: C:\Downloads\project\source\sdt.prg
• Relative from D:\dev\project\ to C:\...\: cross-drive, can't make relative
• Returns absolute path with C: drive letter
• JUSTDRIVE() is not empty -> double-quoted format

PJ2 output:

.ADD('source\sdt.prg')                    <- bare filename (always)
.SetMain("source\sdt.prg")               <- double-quoted (NO lcCurdir prefix!)

Step 2: PJ2 -> PJX

Parsing .SetMain("source\sdt.prg") (line 13857-13860):

• STREXTRACT extracts: "source\sdt.prg"
• setParsedInfoLine evaluates: _MainProg = "source\sdt.prg" = 'source\sdt.prg'
• Note: lcCurDir (HomeDir) is NOT part of the value — it's just the bare relative path

Writing PJX (line 13168):

lcMainProg = Lower(Sys(2014, toProject._MainProg, Addbs(toProject._HomeDir)))
           = Lower(Sys(2014, 'source\sdt.prg', 'D:\dev\project\'))

• Same cross-drive SYS(2014) issue: resolves against current dir (C:)
• lcMainProg = 'c:\downloads\project\source\sdt.prg' (absolute path!)

Comparison (line 13236):

, (loFile._Name == lcMainProg) ;

• loFile._Name = 'source\sdt.prg' (relative, from .ADD parsing)
• lcMainProg = 'c:\downloads\project\source\sdt.prg' (absolute!)
• MISMATCH -> MAINPROG = .F. for ALL records

Step 3: PJX -> PJ2

• Locate For MAINPROG -> not found (never set in step 2)
• If Not Empty(loProject._MainProg) -> FALSE
• No .SetMain() line generated
• SetMain is lost

---

Why It Works on the Original Developer's Machine

On the original machine, current dir and HomeDir are on the same drive:

• SYS(2014, 'source\sdt.prg', 'D:\dev\project\') -> relative path, no drive letter
• GetPathFromHome uses the lcCurdir + 'filename' format (OTHERWISE case)
• PJ2 has: .SetMain(lcCurdir + 'source\sdt.prg')
• Parsing evaluates: _MainProg = HomeDir\ + 'source\sdt.prg' (full absolute path on D:)
• SYS(2014) at line 13168 can compute correct relative path (same drive)
• Comparison succeeds

---

Suggested Fix

Option A: Skip SYS(2014) for relative paths (line 13168)

If _MainProg has no drive letter, it's already relative — use it directly:

If Empty(JustDrive(toProject._MainProg))
    lcMainProg = Lower(toProject._MainProg)
Else
    lcMainProg = Lower(Sys(2014, toProject._MainProg, Addbs(toProject._HomeDir)))
Endif

Option B: Don't use GetPathFromHome for SetMain (line 18626)

Use the same bare-filename format as .ADD():

If Not Empty(loProject._MainProg)
    TEXT TO C_FB2PRG_CODE ADDITIVE TEXTMERGE NOSHOW FLAGS 1+2 PRETEXT 1+2
    <<>>    .SetMain(lcCurdir + '<<loProject._MainProg>>')
    ENDTEXT
Endif

This matches the original commented-out code at line 18624.

Option C: Remove the hardcoded n_CheckFileInPath (line 18413)

The hardcoded toFoxBin2Prg.n_CheckFileInPath=2 overrides user configuration. If removed, the default value of 0 (Ignore) would be used, and GetPathFromHome would always use the lcCurdir + 'filename' format.

---

Files to Change

Only one file: foxbin2prg.prg

Line	Issue	Fix
18413	n_CheckFileInPath hardcoded to 2, overriding config	Remove or respect user config
18626	.SetMain() uses GetPathFromHome (produces incompatible format)	Use bare filename like .ADD() does
13168	SYS(2014) with relative path + cross-drive HomeDir = wrong result	Check for relative path first
13236	== comparison silently fails, no warning	Add validation after the loop

[lscheffler]

@ccantrell72

Oops. This one came never to my knowledge. I get no notification on discussions. It should have been an issue. I will create an issue pointing here.

Guess who has done some alterations now. I try to understand the problem and add the fixes later on.

[lkmatsumura]

I had this problem too when importing projects, but it was with my refactoring codebase.

But if set to not write Homedir in the pj2 , setmain works normally

HomeDir: 0 && Home Directory in PJX

And I confirm the problem occured in only in pj2 files without the lcCurdir in the .SetMain() line.
But since without Homedir info it worked, i don't investigate deeper

[lscheffler]

@ccantrell72. What happens if you create the pjx from the pj2 from the repo? At least with my comp "source\sdt.prg" is Mainprog. The HomePath is still wrong - until I open the pjx with the IDE. That fixes this.

The way you used FoxBin2Prg (see Reproduction above) - not opening the PJX first with VFP IDE - transforms a PJX with information that will not fit to it's storage location. This is not really a bug, it's just the second step of an algorithm in front of the first.
(Aside somebody sets project home dir this way intentionally. But this will be a catastrophe of it's own on a pjx in a public repository.)

FoxBin2Prg is bound to believe that the PJX is where the PJX belongs. FoxBin2Prg does the most possible to CD next to the PJX to have recent path there. It assumes PJX HomeDir equals the Path of the PJX, at least on the Bin2Text process. TextBin runs flawless with strange HomeDir, as it should.

---

I think, your Option B might be a solution - possibly I have misunderstood this while adding the support of additional drives. I do not fully understand the implications of this, but I think I go back to the old code and deal with issues if they raise.

Option C: #128 This is something left over from a test, I remove this.

[lscheffler]

Update:
I think I keep the code with GetPathFromHome. The problem is greater, it's only we do not raise it in this example. FoxBin2Prg simply does not support HomeDir not equal the storage path of the pjx on Bin2Text operation. I think about a test for this problem and simply deny transformation in this case.

[lscheffler]

@ccantrell72 , @DougHennig, @lkmatsumura

I need some input.

---

I tested around with project's HomeDir Property.

The help on HomeDir is:

The home directory for a project is the relative path for all the files in the project.

Creating a test scenario I played around with this, like setting HomeDir some folders away and on a location on different drive. I can not confirm that the storage of files in the PJX (Name field) is in any way relative to HomeDir. It's just all the time relative to the path of the PJX file.

Has anybody some insight what HomeDir is doing? Or used it at all?

I created an issue VFPX/HelpFile#51, so we can alter the help here ...

---

So, basically, the whole idea of GetPathFromHome, and the like, setting some stuff relative to HomeDir looks like the wrong approach. It must be relative to the pjx.

[DougHennig]

I have HomeDir = 0 in my config file because I cannot think of what circumstances you would want to save and restore it. Because it is unlikely two developers would have the project in the same drive and folder, the PJ2 file would always be different if it included HomeDir.

I believe you are correct that HomeDir is the folder the PJX is located in. I think it is used as the relative path for files in the PJX but cannot confirm that.

[lscheffler]

You need to recheck. See https://github.com/DougHennig/StonefieldDatabaseToolkit/blob/master/SDT/sdt.pj2. This is created with HomeDir: 1 :) (it was the test case for this issue, so I had a look into it.)
Anyway, it does not matter. If stored or not, as soon as you open the pjx recreated you are asked about "New HomeDir", and I guess most will answer wit "Yes". This is all it is doing. Nothing changed.

---

I can alter HomeDir to what ever place, I can not see what it is changing. Existing files are not touched and added files are still relative to the pjx. It's all the time relative to the pjx, SET DEFA has no influence as well.

There is a bit of different behaviour then normal if one sets HomeDir via the interface and moves the pjx. It, does not ask for "New HomeDir". But I see not what it does in terms of relative paths.

I feel that I can do the whole processing of the pjx based on the path of the pjx, I only fear there might be some use of HomeDir I do not see. It's frustrating.

[DougHennig]

Sorry, I meant I have HomeDir = 0 now. Back when I created sdt.pj2, I must not have.

Maybe Option B is the solution?

[lscheffler]

I spend the last two days looking into this and try to understand what and when.

The code as of version 1.21.05 was doing stuff related to CheckFileInPath somehow based on the current directory and HomeDir. This is done via SYS(2014), and this will fail, as shown above, when HomeDir is not on the same drive (or UNC path, for this) as the current directory. This is true for HomeDir, Icon, any file exluded or with a comment, and .h and .fpw files, because they must be moved to the text section. And for CheckFileInPath: 1, the test function.

Option C is a must, but then it becomes tricky. I think, the only way to work as it looks VFP does, ignoring HomeDir would be to force the process to the process based on pjx directory like SYS(2014, cFile, cPath_of_pjx) instead of SYS(2014, cFile, HomeDir).

Assuming HomeDir is just a sort of Lava Code nobody is using, the change is easy. Basically one line

*						lcStr = ADDBS( Chrtran( loProject._HomeDir, ['], [] ))
						lcStr = toFoxBin2Prg.c_InputFile

It works, whatever I put in HomeDir and do with the pjx. I'm only afraid I do not really understand HomeDir or if there is some use of this.

:(

[lscheffler]

@ccantrell72 @DougHennig
I pushed the latest version to my fork https://github.com/lscheffler/foxbin2prg.

You might test FoxBin2prg.prg with #119 I now run this on pjx directory, not HomeDir.

There are some new options to CheckFileInPath, see https://github.com/lscheffler/foxbin2prg/blob/fork_mod/docs/FoxBin2Prg_Settings.md#configuration-file.
There is a description of the problems with files and paths in pjx and CheckFileInPath, see https://github.com/lscheffler/foxbin2prg/blob/fork_mod/docs/FoxBin2Prg_Internals.md#storing-paths-for-pjx, please check if you understand this.

[DougHennig]

I think you described the issue very well.