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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Blocked by mystery error message

Status
Not open for further replies.

bfwriter

Technical User
Jul 22, 2006
35
US
Hello friends,

I've got a dilemma with an "outlaw" error message that's preventing me from building an APP file for a form application that also runs several sub-forms. The miscreant error message (attached) blames a supposedly invalid file that doesn't exist (and never could have existed)... because 1) it's referenced as on my F:\ drive which is my external hard drive backup, and contains neither the named directories nor the subject file; and 2) I've searched my entire two working drives C: and D:, and not been able to find the offender; and 3) no such path exists on my computer.

The master form (an SCX file) runs fine, with all its subcomponents. It just won't permit me to build an application file, stopping at the error message, and quitting at that point.

Other efforts that haven't helped:

1- I've located two files among the VFP file directories with the same filename, "clock.bmp", and have inactivated them (by temporarily renaming). No help.
2- I've directed the Builder to recompile all files. No help.
3- I've searched the form's code in the Class Browser for the name of the errant "clock.bmp" file, No help.
4- I've inactivated the only instance in the main form of use of the DATETIME() function, supposing that the clock.bmp may have been called in it. No help.

Any ideas, anyone?

Bill
Rochester, MI
[URL unfurl="true"]https://res.cloudinary.com/engineering-com/image/upload/v1570138212/tips/2019-10-03_vfp-error_p4lbkm.pdf[/url]

 
Bill,

Look for any reference to clock.bmp in "Tools / Code References".
 
Bill

What VFP version do you have?
See if this will help:
- recompile all forms scx files separately (manually or in the code), like compile form ...
- then create a new project file with a new name and try to rebuild the project.

Yuri
 
The error message says that the offending file is in \VFP\Samples\Controls. In fact, the file does exist (and is a valid BMP), but it is in \VFP\Samples\Classes. So it looks like something is funny with your VFP directory tree. (I'm assuming you have installed VFP direclty under the root of F:, rather than in Program Files.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Is it possible you have a reference to clock.bmp in your forms collection - that seems to me to be what your error message is saying

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Griff's made a good point. The message refers to a form file. In other words, for some reason VFP is looking for a form with a BMP extension.

The error is no. 1686. The Help for this error refers to a "screen" file. I don't know if a screen file is the same as form file in this context, or whether this refers to the old Foxpro generated screens (SPR and SPX files).

Does that help at all?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
I popped a jpg into the forms collection on a VFP9 project and when it compiled it threw an error:

d:\dev\myproject\myjpg.jpg is not a table


VFP6 just says 'not a table' and give no other clues.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Bill,

Here's something you could try. Go to and download and run the small PRG file named WhichOne.PRG (written by Ted Roche). Essentially, this will compile each file in your project in turn, and then tell you which component(s) generated error message(s). That should let you get to the root of the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Many many thanks to you fellas who've looked at this problem for me. There are several good suggestions, and it will take me some time to go through them all. Some quick feedback for now:

ATLOPES: At your suggestion I checked out he Tools>Code References. No joy there. Offender not found. But I'm glad to have learned about this utility, which I never used before. Thanks

YURI: Your idea has occurred to me too; but there are about 18 forms in this project, and the task is daunting. So I'll hold off on that route until I try some other less arduous means.

MIKE: My VFP files are installed in the C:\programs\... directory, not the F: drive. The F: drive (backup external hard drive) has no VFP operators on it. And a complete search of the F: drive turned up no *.bmp files. (That's what makes the error so perplexing... even "impossible"). As to your second post, I'm enticed by your suggestion about "WhichOne.PRG (written by Ted Roche)."

GRIFF: That's what I've thought too. But so far a lot of searching hasn't found one. (P.S. I love your signoff quip about binary. My brother has a tee shirt with the same.)

Plan for now: I'm going to first try Mike's suggestion with the "WhichOne.prg" to find the culprit. If that fails to find it, then I'll go on to Yuri's. This won't be quick and easy; and I'll be a couple of days on this before I get back to you with feedback.

Mucho thanks again.

Bill
 
Code references won't find this.

Close your project and then use the command window to open it as a table and browse the contents

Code:
close all
use c:\myprojects\myproject.pjx
browse

Then do a search for Name="clock.bmp"

Code:
locate for upper(name)="CLOCK.BMP"
browse



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Problem solved!
Realizing that the PJX had acquired (carelessly) a small attic-full of obsolete forms that hadn't been removed from the project, I decided to reverse the process, and to rebuild the project starting from the main form only, then to add each component one-by-one, recompiling as I went, to find the offender. To my delight, upon adding and compiling the first (main) form, the project manager sought and added all the required forms, programs, code, a custom library, etc., bypassing the unused garbage. And upon recompiling the APP, it did so cleanly, without a hitch. So the problem is cleared, though without the satisfaction of actually finding the culprit. Once again, the time honored but disreputable "walkaround" does good service.
So, a hearty thanks to all of you who volunteered suggestions.
I relearned a good lesson from this (taught to me 65 years ago by a fastidious printer boss), about sweeping the floor each night after finishing for the day.

Bill
Rochester, MI
USA
 
What's strange in your case is a BMP that's referred to as a form. I tried to drag a BMP into the forms list of the project manager, but that doesn't work, the drop of a BMP puts it into the other files section of the project.

Yes, the compiler adds referenced files, if it finds them. The typical way to get a new PJX is beginning with the main PRG, but you can have a set of files that are a completely separate island and still belong to the project. You could have graphic files you only address indirectly via their name as files included by the build process don't need to be addressed by full path.

There's, in general, some danger to it, as VFP can search along SET PATH and find files with the same name but wrong content, either completely different images, forms, class libs or older versions. Of course, you can make it a rule to not have such double files for yourself, but Windows in principle doesn't disallow. Then there are relative paths and indeed that can be problematic too.

So, take this as an emergency solution of a project rebuild, not as your regular spring cleanup routine. Project files and their contents are very stable in my experience, and I do things abroad the usual things developers do.

If you still have the old PJX, to USE and BROWSE it as Griff suggested should find the form and then you could delete that record, I would suspect the project manager would also show clock as a form in the forms section. Because you can in fact take a form (do this with a new empty form just for testing) in the project manager and rename it. In renaming you cannot only change the form name, you can also change the extension. VFP's project manager doesn't care for it, it knows (trusts) what it has in PJX is a form and displays it in the forms with form icon once it's there. Such a renamed form still works and compiles, too. What you can't rename is the SCT (or VCT) extensios of the accompanying files. And, of course, adding such trickily renamed forms to another project doesn't work, as the project managers doesn't indpect the file content and sess it has VFP table structure SCXs have, it judges a bmp as image file. So such tricky things that you don't benefit from are also a reproducable way to get a project rebuild failing.

What's less in the awareness is that the build of a project can also fail, if you don't first CD into the right path (aka SET DEFAULT). I have such a project in maintenance. An error like a BMP being an invalid form, that's not healable by a SET DEFAULT, no, but things like undefined constants could be due to includes in includes, specifically when an #INCLUDE in a PRG is not specifying a path and #INCLUDES in this #INCLUDE,too. You can see how that also puzzled the previous developer, as tow header files exist in two places already, and I am yet not willing to untangle this...

Lesson or recommendation: Keep regular backups of your PJX in reach, eg aside of your regular backup routine which often is a bit too tedious to use for restoring perhaps a whole drive/partition just to get back to a single file. The file History Vista introduced isn't a bad feature in that aspect, it just fails to easily get a pair of PJX/PJT.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Olaf said:
What's strange in your case is a BMP that's referred to as a form. I tried to drag a BMP into the forms list of the project manager, but that doesn't work, the drop of a BMP puts it into the other files section of the project.

True. But try adding a form, than renaming it (via the project) to a BMP. VFP doesn't stop you from doing that. But of course it's not very likely that would happen by accident.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Mike,

yes, that doesn't happen by accident and it also doesn't cause a compilation/build error. I just mention it to illustrate what I treid to reproduce a BMP file in the project in the documents/forms section.

I don't see the VFP9 ide allowing such a wrong record to appear in a PJX table, so I guess that problematic record of the PJX originated from before conversion to a VFP9 project. I guess you could also fabricate a form record referring to a BMP or JPG file, but that again would be intentional and not by accident.

Overall still a mystery. But one of the kind the OP doesn't care enough as his problem is solved.

It's okay, as I'm pretty sure the VFP9 project manager does not enable you to get into this weird situation unless Griff can say how he managed to add a JPG to forms.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top