Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

my project lost my form

Status
Not open for further replies.

Judi201

Technical User
Jul 2, 2005
315
US
Hi!

Never had this one before. My form 'frmSelect' has been in the project manager for a while working correctly. Now when testing a form that calls frmSelect I get an error that tells me it can't find frmSelect. It is trying to find it in a different sub-directory (under 'progs' instead of 'forms').

Would someone please advise on how to 'find' my form.

I have confirmed that the form IS where it should be.
I have recompiled the project showing errors and I get the same error there.
Nothing has (that I am aware of) changed in the location of any files.
When I click on the frmSelect in the Project Manager, it shows the correct path.

Any idea why my project can't 'see' it

Thanks for any ideas.

Judi
 
Try adding the extension to the DO call. e.g. DO frmSelect.scx

Brian
 
Brian,

Thanks for the reply, but that didn't fix it. The only way I have been able to call it is to give the complete path.

Judi
 
Judi,

Whatever your default directory is (...\PROGS) when you issue DO FORM, frmSelect isn't in it.

You either need to change your default directory with SET DEFAULT TO ...\FORMS before calling this form, which will probably affect other commands in your procedure, or you will need to issue DO FORM ...\FORMS\frmSelect, which you say does work.

Allan
 
Allan,

Code:
when you issue DO FORM, frmSelect isn't in it.
Thanks for the response. To clarify:
issuing DO FORM ...\FORMS\frmSelect does work.
I do have SET DEFAULT TO... set on startup and this has been working with this form for weeks. It is called by several forms and all have worked until today. Now none of them can find it. And the error message says that is is looking for
...\progs\frmSelect.

If you are telling me that it is where I am calling it from that is making the difference, I don't understand that because all of the forms are in the same directory and have been all the time.

The ONLY thing that I can think of is that I ran a little code snippet (testing) from ...\prgs\ but I did not call the form from there.

As I said earlier, everything was fine and then it wasn't with nothing involving changing dirs in between. I just don't get it. :(

Thanks for any suggestions.
 
You can specify multiple paths for your program to search for files with the 'SET PATH TO' command. (check out the help). Maybe somthing has changed your prior settings.

Brian
 
Brian,

I have the following in startup for development.

Code:
SET DEFAULT TO C:\MyProjects\Casting
SET PATH TO FORMS,DATA,REPORTS,GRAPHICS,HELP,INCLUDE,LIBS,MENUS,PROGS
This has not changed.

Thanks for any thoughts.

Judi
 

Judi,

I'm not sure if I can add anything to the help that Brian's given you.

That said, keep in mind that this has got nothing to do with the project. The presence or absence of a form (or any other file) from the project has got nothing to do with whether VFP can find it in your development environment.

It seems to me the most likely explanation is that either the DEFAULT or the PATH has got changed somehow.

Assuming the form's path isn't hard-code in the DO FORM: When you see the error message, click Suspend, go into the debugger, go to the Watch window, and enter SYS(2003) and SET("PATH"). If the resulting values aren't what you expect, that would explain the behaviour.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Mike,

The presence or absence of a form (or any other file) from the project has got nothing to do with whether VFP can find it in your development environment.

I do understand that being in the project would not keep the path from being changed, however, I seem to remember that before when something could not be 'found' on compile of the app,(a class, maybe) I could go back and add it and recompile and things would be ok. I guess what was throwing me was that this time it WAS where it needed to be and fox was not finding it where it had earlier.

I came in this morning, started fox up, checked this site and went to try your suggestion and things worked fine. So, even tho the problem seems to be gone, I have no idea why or what to do if it reoccurs.

You have given me one more way to troubleshoot and I am saving it for reference should I need it again.

And yes, I had exited fox and restarted it several times before posting. That is the first thing I always do.

Anyway, thanks to all for your suggestions.

Judi
 
Mike,

I'm so glad you made that comment because the situation is still buzzing in the back of my mind even as I try to move forward!

I am wondering what I miss if I go to Class Browser - Apps - show code and use EDIT-FIND to search for the term PATH or DEFAULT. I did this and only found the one place where it was set on startup.

The ONLY place that I found anything dealing with directories was in the form I am working on now that makes a directory (if it doesn't exist) and then copies the archive to that dir. I just don't see how that could cause a problem.

Is there any other place for me to check?

Thanks so much for your help.

Judi
 

Judi,

Another possibility would be to create breakpoint on SYS(2003) and SET("PATH"). Then run the application. With luck, you'll get a notification when the default directory or search path changes.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Thanks Mike,

I am saving these ideas for even though things have gone smoothly today I fear these unexplained gliches. They usually get you at the least expected moment. :)

Appreciate your input.

Judi
 
Mike,

Code:
I don't think the CB will show that VFP hard codes the entire path to stuff.

My 'lack of learning' is showing here. I don't understand exactly what you mean by VFP hard coding the entire path. I guess I thought that VFP just searched my DEFAULT and PATH statement for the object it needed, but VFP was certainly looking for my form in ...\progs\frmSelect. I know I never wrote code to put it on that track!

When you run that utility, it shows you paths that you have not set to specific objects?? With my lack of understanding, that is scary.

I would appreciate any help with understanding how that does work.

Judi
 
Yes, I had that problem a lot when I first started trying to work with classes. Had to start over several times! :) I have never had the FORM to be 'lost', tho. I can somewhat understand that becaue of the back reference to parent class, etc. I would have understood if fox was complaining about a class reference but this form is just a base class form.

So, if I saved the form after a change in the ...\progs\.., that would explain it even if I moved the form back??

If so, that would be a possible scenario as I have been known do that!

Maybe the fog lifts. Thanks.

Judi
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top