I've already pushed it out today, working around here. I put the actual path in to where it is on my dev machine (e:\dev\client\forms) and then it works. Here's the kicker: run from Production (not inside VFP) at the client site--even with that hardcoded path WHICH DOESN'T EXIST AT THE CLIENT--it works.
I've had similar "ghosts" with VCX-based forms as well. In fact, this USED to be a VCX-based form once-upon-a-time...that's why you see that commented out SET CLASSLIB command prior to the DO FORM call.
Have you guys ever experienced such weirdness?
On 12/6/2020 12:00 PM, Tracy Pearson wrote:
Can you check what SET("CLASSLIB") is set to, and SET("LIBRARY")? What is the stack, are things still running in the complied app?
Tracy
On December 6, 2020 11:30:28 AM EST, "MB Software Solutions, LLC" mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Hi Ajit,
Still fails: https://www.screencast.com/t/WXrKy7vCXu
So strange. This inherited project has always had "spectres" of a sort; things that made absolutely no sense (like this kind of "file not found" stuff).
On 12/6/2020 12:10 AM, Ajit Abraham wrote:
Mike, Try renaming the form to something else (like abc.scx) and then call the renamed form. Also, just verify in the project properties that this file is indeed included. (I know that you will see a icon in front of the file if it is excluded - but still..)
Ajit
On 06/12/2020 06:31, MB Software Solutions, LLC wrote:
VFP9SP2 - Win 7 Pro
43 second demo showing the problem: https://www.screencast.com/t/ZjyWYqFI
The SCX form is included in the EXE. I'm running the EXE. DO FORM <formname> errors saying that the form is not found. Makes no sense to me. Now the app (a legacy app that I inherited which is very dirty) changes the path but still....if the SCX form is included in the EXE, why in the world would it not be found on DO FORM frmMyForm???????
tia, --Mike
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]