VFP9SP2
Frustrated!!! All of the sudden my 2003 project code wants to rebel. I'm trying to debug some things and when I try to step into the code--code which has worked since 2003, mind you--it now says "Source not available" DESPITE THE FACT that I'm in the Project's home folder, where the EXE resides (I did a Build EXE & Run after), and the PROGS subfolder is in my path.
Here's my first call to create the Custom biz obj: https://www.screencast.com/t/5UsbNGGXBGr
Then here's the next screenshot, showing that nasty message and confirming my curdir() and SET('Path'): https://www.screencast.com/t/E1UOoe9h
You can see in the first that I've even changed the pathing of the object call to what it really is. I never do that; I always used relative pathing like this: NEWOBJECT("Class",".\progs_bizobj.prg")
I searched the ProFox archives and saw this thread: https://leafe.com/archives/full_thread/468343 ...but Kurt's issue was resolved by relocating the EXE to the proper path. Mine is in the same spot it has been for 14 years! As Sytze (RIP) suggested, I deleted all of the FXP and did a COMPILE c:\dev\fabmate11\progs*.prg to recreate all of them. Using Richard's tip, I verified that yes indeed, my project does have Debug Info included/checked in the Project manager.
Also reviewed this thread, started by Richard: https://leafe.com/archives/full_thread/392144. I renamed the EXE and ran the new one....nope, same bad behavior.
So I've ruled out pathing, out-of-sync FXPs, and the Hale-Bopp comet.
I'm thinking my next step is to recreate the project file from scratch and rebuild.
Any other ideas?
tia, --Mike
Here's a couple more things to check: NTFS permissions Hidden attributes
Also, you can use this in the debugger Watch window: FULLPATH(".")
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Thursday, July 27, 2017 11:21 AM To: profoxtech@leafe.com Subject: "Source not available" -- seems to happen in the history of the list!
VFP9SP2
Frustrated!!! All of the sudden my 2003 project code wants to rebel. I'm trying to debug some things and when I try to step into the code--code which has worked since 2003, mind you--it now says "Source not available" DESPITE THE FACT that I'm in the Project's home folder, where the EXE resides (I did a Build EXE & Run after), and the PROGS subfolder is in my path.
Here's my first call to create the Custom biz obj: https://www.screencast.com/t/5UsbNGGXBGr
Then here's the next screenshot, showing that nasty message and confirming my curdir() and SET('Path'): https://www.screencast.com/t/E1UOoe9h
You can see in the first that I've even changed the pathing of the object call to what it really is. I never do that; I always used relative pathing like this: NEWOBJECT("Class",".\progs_bizobj.prg")
I searched the ProFox archives and saw this thread: https://leafe.com/archives/full_thread/468343 ...but Kurt's issue was resolved by relocating the EXE to the proper path. Mine is in the same spot it has been for 14 years! As Sytze (RIP) suggested, I deleted all of the FXP and did a COMPILE c:\dev\fabmate11\progs*.prg to recreate all of them. Using Richard's tip, I verified that yes indeed, my project does have Debug Info included/checked in the Project manager.
Also reviewed this thread, started by Richard: https://leafe.com/archives/full_thread/392144. I renamed the EXE and ran the new one....nope, same bad behavior.
So I've ruled out pathing, out-of-sync FXPs, and the Hale-Bopp comet.
I'm thinking my next step is to recreate the project file from scratch and rebuild.
Any other ideas?
tia, --Mike
[excessive quoting removed by server]
I get similar issues sometimes. It's always paths or old FXP files without debug info in them.
Are the PRG files built into the EXE via the project ?
Do you have 'set classlib to progs_bizobj.prg additive' somewhere at the setup of your application? I find it's best to be explicit rather than relying on search paths to find it.
Have you tried building an APP instead of an EXE and running that in VFP?
Sorry - where I said
'set classlib to progs_bizobj.prg additive'
I meant
'set procedure to progs_bizobj.prg additive'
On 2017-07-27 11:38, Alan Bourke wrote:
I get similar issues sometimes. It's always paths or old FXP files without debug info in them.
What's weird is I've deleted the FXPs and recompiled though. DebugInfo is checked in the Project setup too.
Are the PRG files built into the EXE via the project ?
Yes, these PRGs are included in the EXE.
Do you have 'set classlib to progs_bizobj.prg additive' somewhere at the setup of your application? I find it's best to be explicit rather than relying on search paths to find it.
I didn't use SET PROCEDURE before since I was explicit in the 2nd parm of the NewObject(class,location) call saying where to get it.
Have you tried building an APP instead of an EXE and running that in VFP?
Just tried...no different.
On Thu, Jul 27, 2017 at 11:20 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
VFP9SP2
Frustrated!!! All of the sudden my 2003 project code wants to rebel.
Well, it is fourteen. Teenagers!
What's SET('Development')?
Confirm your CurDir() is where you think you are.
Turn off VFP and try it again cold. Compiling often leaves things in memory.
On Thu, Jul 27, 2017 at 1:10 PM, Ted Roche tedroche@gmail.com wrote:
On Thu, Jul 27, 2017 at 11:20 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
VFP9SP2
Frustrated!!! All of the sudden my 2003 project code wants to rebel.
Well, it is fourteen. Teenagers!
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
On 2017-07-27 13:15, Ted Roche wrote:
What's SET('Development')?
Confirm your CurDir() is where you think you are.
Turn off VFP and try it again cold. Compiling often leaves things in memory.
SET DEVELOPMENT is ON. CurDir() confirms it's in the app/project folder. I've restarted VFP repeatedly. Even restarted the entire machine!
Added SET PROCEDURE to .\progs_bizobj.prg, .\progs_dataobj.prg in Main program right after startup and confirmation of current proper folder...no change.
Did a SET STEP ON before the object created. I added a SET PROCEDURE TO c:\dev\fabmate11\progs_bizobj.prg ahead of it and changed the NewObject to Createobject. Here's a screenshot of that: https://www.screencast.com/t/YOTQF4D5Xsw STILL same bad behavior.
At times like these I have added a SET STEP ON in the code module that is showing up as "Source not found" rather than before it.
Frank.
Frank Cazabon
On 27/07/2017 02:49 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2017-07-27 13:15, Ted Roche wrote:
What's SET('Development')?
Confirm your CurDir() is where you think you are.
Turn off VFP and try it again cold. Compiling often leaves things in memory.
SET DEVELOPMENT is ON. CurDir() confirms it's in the app/project folder. I've restarted VFP repeatedly. Even restarted the entire machine!
Added SET PROCEDURE to .\progs_bizobj.prg, .\progs_dataobj.prg in Main program right after startup and confirmation of current proper folder...no change.
Did a SET STEP ON before the object created. I added a SET PROCEDURE TO c:\dev\fabmate11\progs_bizobj.prg ahead of it and changed the NewObject to Createobject. Here's a screenshot of that: https://www.screencast.com/t/YOTQF4D5Xsw STILL same bad behavior.
[excessive quoting removed by server]
I found a workaround. I had a copy of the PJX/PJT from a year ago from a source code backup. Works now. Bottom line -- I think something wonky with the Project file. Wonder if that weird quirk could lead to this wonky "ghosting" behavior they're seeing? It's not consistent either. Oh well. Onward.
Ugh.
If the problem was on the PJX, then you could regenerate it from the pj2 text file, so you have a new PJX without any "noise".
The same applies to classlibs and forms, which sometimes have little corruptions that do not throw errors, but sometimes produce strange behaviours.
Well, all this just if you use FoxBin2Prg to generate the text files, which are useful not only for Version Control, but for backup purposes.
2017-07-27 21:06 GMT+02:00 mbsoftwaresolutions@mbsoftwaresolutions.com:
I found a workaround. I had a copy of the PJX/PJT from a year ago from a source code backup. Works now. Bottom line -- I think something wonky with the Project file. Wonder if that weird quirk could lead to this wonky "ghosting" behavior they're seeing? It's not consistent either. Oh well. Onward.
Ugh.
[excessive quoting removed by server]
It's at times like this I fire up Process Explorer from Sysinternals, find the EXE (or VFP9.EXE if you're running from within the IDE), highlight it and see exactly what damn files it has handles on.
On 2017-07-28 04:44, Alan Bourke wrote:
It's at times like this I fire up Process Explorer from Sysinternals, find the EXE (or VFP9.EXE if you're running from within the IDE), highlight it and see exactly what damn files it has handles on.
But would that show handles on those files that are included in the EXE? I mean would there be some sort of distinguishing signature?
On Thu, Jul 27, 2017 at 2:49 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I'm a little confused where the project comes into this. Are you starting out running an APP/EXE and then stand-alone PRG/FXPs?
A project file has an internal search path, different from the PATH path, where it found all of the components when it built the project. (Where you answered when it popped up the Locate dialog.) If you rebuilt the EXE on a machine that had a E: F: or G: drive, it gets stuck in that project path, and nearly never comes out. Remember ancient problems with D: drive CD-ROMs causing problems when apps were distributed? I think these paths hang around and foul up the ability to find the source and result in the "Source Out Of Date" error even when that's not remotely the problem.
-
Alan Bourke -
Fernando D. Bozzo -
Frank Cazabon -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Ted Roche -
Tracy Pearson