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

Problems installing app in win7 64 bit 1

Status
Not open for further replies.

Oldnerd

Programmer
Jul 29, 2004
3
US
Ok i'm doing something wrong. I have an app that I created on a win7 64 bit machine that runs fine. I build a setup.exe using inno and it seems to work on my computer, installing my app to different folders.

But when I try to install on other computers that do NOT have VFP 9.0 on them I consistantly get runtime errors.

The first says "The resource file is not valid. Overwrite it with a new empty one? If I say yes, then I get another runtime that says" Program Error Property SHOW is not found"

I'm using an inno generated script that has the runtime file list as shown on VFP Wiki.

What am I doing wrong??


TIA
Bill
 
The resource file" here refers to foxuser.dbf. If you don't deploy a foxuser.dbf a foxpro exe will try to create one, and since users aren't allowed to write to a program directory inside /Program Files/ this fails.

Don't know if the other error you get about SHOW simply is a follow up, it doesn't sound so.

Nevertheless, in regard to foxuser.dbf the solution is simple:
You can do without it, and to tell foxpro you don't need it you write a text file config.fpw with the single line RESOURCE=OFF in it. Then add that to your foxpro project in the other files section. Set it to be compiled into the exe via context menu item "Include".

Then recompile and your final exe will not try to create a foxuser.dbf

Bye, Olaf.
 
Followup:

Looking at your mediafire screenshots you don't introduce error handling. Your errors are the default system error message, and that does not include a lineno. If you introduce error handling as the first line of your main file, you'd see what line causes the error message about SHOW.

Bye, Olaf.
 
If you introduce error handling as the first line of your main file, you'd see what line causes the error message
Not necesserily, colleague Olaf: "old good" ON ERROR, issued in a PRG module, has no effect on forms and classes (at least that's how I remember it from VFP7 days).
What I ended up (and have, ever since, been) doing was to use the TRY-CATCH TO loErr-ENDTRY in PRGs (loErr being an object of the Exception class), and call some error handling function from the Error() event procedure in the objects.
HTH.

Regards,

Ilya
 
ON ERROR is global error handling, in contrast only objects have an Error method. That has precednece, but if you don't use it, ON ERROR is handling the error of objects, too. BEsides you can escalate error handling from an Error Method to the general ON ERROR handler.

Also in this context we search(ed) for an error occurring in the main.prg of an EXE. At least no other main file of a project makes any sense.

If you include LineNo() your error handling routine will know at which line the error occured, no matter where that was, if in a prg or in an object. SYS(16) or PROGRAM() tells you the prg or class/method, for which the lineno applies. BEsides the error handling routine can get all these infos even without having them passed in via ASTACKINFO().

Bye, Olaf.
 
But of course, Olaf!
All you say is correct... except ON ERROR, even if it's DO ErrHndlr WITH MESSAGE(), PROGRAM(), LINENO() etc., when it's EXE (not PRG, SCX, VCX), VFP fails to provide the correct procedure name (it was getting me the name of EXE) and LINENO() (it was always the same line: READ EVENTS).
So - yes, one has to use ASTACKINFO() to get the correct procedure name, line contents and line number. (I remember similar discussion on the Foxite forum some long while ago.)
Other than that - you're correct.


Regards,

Ilya
 
Depends on how you compile. With debug info you can use Lineno(), and Program() or Sys(16,nLevel) I use Lineno() all the time, but also have changed code to ASTACKINFO(), as it gives all info at once.

Bye, Olaf.
 
Even with Debug Info included into the compiled EXE, it gave me READ EVENTS line number and the EXE name in VFP6/7. I skipped VFP8, and switched to using TRY-CATCH-ENDTRY and Error() event procedure with ASTACKINFO() in VFP9.

However, if PROGRAM() and LINENO() still work for you, collegue, I see no reason to abandon them. "Don't repair what's ain't broken", as the saying goes! ;-)

Regards,

Ilya
 
One thing is, if you always get pointed to the READ EVENTS line, what do you use to trigger an error? If using the simplest approach, the ERROR command, then you should receive the line of that ERROR command of course. Also see there is a difference of Lineno() and Lineno(1), one of them giving an absolute and one a relative line number.

Never mind, it doesn't matter much and has no additional value to this thread anyway.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top