>>>Here's the original code snippet from Genmenu.prg
>>>
>>>m.g_homedir = ALLTRIM(SUBSTR(homedir,1,AT(c_null,homedir)-1))
>>>
>>>IF (RIGHT(m.g_homedir, 1) == "\")
>>> m.g_homedir = m.g_homedir + "\"
>>>ENDIF
>>>
>>>
>>>So if g_homedir has a backslash it adds another one. ROFL.
>>>
>>>I've yet to actually determine that fixing this bug won't break something else. It definitely has an impact in FPW2.6 when SYS(2014,....) is used later in the code to determine the relative path to the .mpr file.
>>
>>Not quite sure this hurts, because VFP's (and FP's) file handling treats double backslashes as single backslashes, which is the most probable reason this went unnoticed. I think I've fixed this one myself once, but then the next version came and my fix was gone - no problem either. But then, it may be the problem didn't occur because whatever file the Locfile may be looking for, was always in my path.
>
>Hi Dragan,
>In fact I don't think there ever is a backslash, so no backslash gets added which then causes SYS(2014,,) to think the folder name is a file name and generate junk code in the .mpr. In any real production environment it doesn't fail because the .mpxs are built into the app or are in the path anyway and Locfile() never gets called.
>So no "show stopper here", it only showed up because I was building a new Foxstart.app (remember that old one?) and it couldn't find the menu code.

I think the whole thing is unnecessary - the code should use ForcePath() which simply works, backslash or not. Genmenu seems to be one of the things which were brought from 2.0 (or 1.01?), occasionally fixed a bit but generally not rehashed since.