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!

VFP7 on Win7 Pro 64

Status
Not open for further replies.

davisonpro

Programmer
Oct 11, 2010
34
US
I can't seem to get the VFP7 development environment to function correctly under Win7 Pro 64bit.

My program changes don't "take" - I've used both the VFP editor and tried an external editor. I've tried compiling the changed PRG and building the whole project (which also doesn't seem to want to work very well). I'm making very simple changes - text boxes and some minor logic changes. Even commenting out some code.

It runs the app OK but it only seems to want to run the old version of the code or it will just hang.

I'm a bit new to both VFP7 and to Win7. The app compiles fine on an XP machine and the compiled app runs perfectly on Win7. I just can't seem to be able to develop code on my Win7 box.

I'm probably doing something bonehead stupid but I've been trying to figure it out for about 2 weeks so, I'm asking.

BTW: I've searched this forum and Googled for hours. What am I missing?
I have the option to switch to VFP9 if I must but that would be another huge deployment project - over 1,500 users in the field.
Right now, I'd like to just get some minor code changes out there.
Thanks!
Al
 
Well since I do not run VFP7 under windows 7 I can not give you an answer, but what about setting up a virtual XP on your win-7 for this project? Yes a bit of a kludge, but it might work.

BTW: Have you tried to create a simple hello world type application from scratch? I wonder if window 7 is preventing writing, some sort of security etc? Also have you deleted all *.bak and *.fxp files to force VFP to recompile?

Hope someone else will give you the 'correct' answer.



Lion Crest Software Services
Anthony L. Testi
President
 
Check that SET DEVELOPMENT is ON. It normally would be, but if for any reason it is set OFF, that would explain what you are seeing.

The only other thing that comes to mind is a problem with the computer's clock, but it's hard to see how that could happen without affecting a lot more than VFP.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
Where do you store your project? Do you make use of wizard created forms? If part of your project is within HOME() the fast solution is to start VFP by right clicking on the VFP icon and choosing "Run as Administrator". That's needed even if you run as administrator already, as even then you run an exe with normal rights only and you can only write to the Program FIles directory with elevated rights.

The other solution is to install VFP7 outside of Program Files.

Bye, Olaf.
 
Thanks for the replies!

I'm not sure I've tried what Olaf is suggesting - I think I did but I'll go back through that.

Mike - I'm beginning to wonder if the problem is that the Win7 sessions don't recognize/respond to the SET DEVELOPMENT flag. At least my current setup may not be. I am using SET DEVE ON but maybe this installation/environment is just ignoring it.

I'll go back through all of these suggestions later today and report back if any of them - or a combination of them - does the trick.

It's a drag having to use my old computer to work when I've got this "hot rod" sitting on my desk.

Thanks!
 
DavisonPro,

I can't believe that it's Windows 7 itself that's causing the problem. If VFP was unable to compile under Windows 7 (or wasn't respecting SET DEVELOPMENT), surely we would have known about it by now.

I feel sure it might be something specific to your environment. Perhaps the FXP file (or other files that you are trying to compile) is read-only. Perhaps they're in a sub-directory of Program Files (which Windows doesn't like writing to).

Have you tried reducing the problem to the very simplest scenario: a single PRG file (a Hello World program, for example), that you create and run on the Windows 7 machine? Can you see anything at all out of the ordinary?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
If ffc classes are the problem, SET DEVELOP ON may only help halfways, compile with "recompile all files" setting should override any problems of UAC in Windows 7 and file virtualisation. Even with SET DEVELOPMENT on VFP might check the file date of the wrong files and not recompile changed files, but "recompile all files" does what it says.

Most important is to right click on vfp start folder entry and "run as administrator". To make double sure do so with the vfp7.exe within the program files/ms visual foxpro 7/ folder.

Bye, Olaf.
 
I am making some progress with this using the suggestions you all have offered.

It is a clunky thing - I set all the permissions as suggested; I now delete all the compiled files before rebuilding (compile all files isn't really compiling all the files as it should unless I delete all the previously compiled files).

I've got an issue with _table.vct/x - it keeps reporting that it's not a table. I get a lot of errors trying to rebuild menus but the menus are getting rebuilt and they all work.

I can do all the "Hello World" stuff just fine - that's why I thought everything was OK but the project I'm really working on is pretty big - well over 1,000 components.

I'll continue working on this...I have to because it's how I feed myself.

Now, I've got a decision point:
1) buy a new development PC that runs XP and VFP7
.or.
2) buy VFP9 and take a chance that it will run fine on Win7 Pro and start the conversion process.

Parms: I've got a couple of months time to fool around with this because I've got another programmer working on this project who is not having issues.
I'm kinda broke - can't really afford to spend more than $1,000 right now without having some "real life" issues.

What would you do?
 
Now, I've got a decision point:
1) buy a new development PC that runs XP and VFP7
.or.
2) buy VFP9 and take a chance that it will run fine on Win7 Pro and start the conversion process.

I suggest you do NOT do either of those things until you know more about what is causing the problem. Otherwise, you risk spending money or time and still having the problem at the end of the day.

(In the case of upgrading to VFP 9.0, that's a good thing to do anyway, but you will need to invest some time in re-testing your application. You shouldn't do that while you are battling against the Windows 7 problem.)

Maybe you need to find someone who has VFP 7 running under Windows 7, and ask them if they have any problems with compilation. If they don't (which is almost certainly going to be the case), then you will know that the problem is solvable in your present environment.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
Thank you, Mike!

Actually, what you suggested is the reason I posted here - trying to find someone with a "substantial" VFP7 project under Win7 to see if it's just me or if it's a known problem that is solvable.

You are correct that I've got to move to VFP9 at some point and I'm wondering if I'm at that point now.

I "inherited" all of this when I bought this company. The company is doing well but the products are not too great. My customer base is somewhat patient because the products work "most of the time" but I will begin to lose them if I don't show some improvements pretty soon. VFP9 will be a logical step towards the needed improvements but I've got to continue maintaining and updating the products - on a quarterly basis.

I thank you all for your help! Someday, I hope I can help others but I'm on the "need side" of the equation right now.
 
UPDATE: I just ordered VFP9 - gotta go there sooner or later so, I feel better now that I've decided on sooner.

I'm sure I'll have questions about that, too.
 
I just ordered VFP9

Probably just as well to bite the bullet (despite what I said earlier about solving the compilation problem first).

But don't necessarily expect the whole app to work perfectly the first time you run it under 9.0 (always assuming this gets you past the compilation problem). Chances are you won't have any major issues, but you'll need to do some thorough testing.

The most likely compatibility issues are those relating to SQL SELECT commands. If any of these crop up, check the Help for SET ENGINEBEHAVIOR.

Let us know how things work out.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
Thanks, again Mike!

I'm laughing because this system that I've inherited has no SQL statements in it at all. It's all legacy code that was begun under FoxPro for DOS and had the bare minimum of migration work done to it for the past 18 years.

I'm not complaining too much - I knew this when I bought it. The good news is the loyal user base built up over 18 years - that produces the revenues.

The bad news is that the code is a highly predictable mess!

So, I've got a job ahead of me. This is just the beginning.
 
...find someone who has VFP 7 running under Windows 7, and ask them if they have any problems with compilation.

A coworker and I are both running W7 with both VFP7 (for a bit of legacy support until conversion) and VFP9. Neither of us have had any insurmountable compile issues.
It's important to familiarize yourself with the W7 file structure behavior with the virtual directories, and permissions. But if you're careful as to where you point your temp and final files, you should be able to work it just fine.

For the record, and I shudder as I mention it, we are still running some Fox 2.x on XP and W7 around here.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
The question is: Are you using FFC classes from the VFP Home() directory in your large project? What, if you install VFP7 in eg C:\Users\Public\ instead of C:\Program Files\

What can hurt you in Vista and Win7 is file virtualisation of files in \Program Files\ and some more.

See C:\Users\<<YourWindowAccount>>\AppData\Local\VirtualStore\Program Files\ to see what files are being virtualised. That is write operations to these files are not writing to the original position but to a copy of the file in this \VirtualStore\ directory.

In case of VCX/VCT and other double file objects foxpro needs this can case the problems you see, eg reporting "is not a table" as these file pairs are broken through half virtualisation only.

This is why I suggested you to right click on VFP7 and choose the item "run as adminstrator" from the context menu. If you do so, you can write to \Program Files\, but it might be too late as you already have broken the installation.

What really should help you is reinstall VFP7 outside of \Program Files\ where you don't have that kind of file virtualisation.

Last not least, the idea behind this is to not hinder incompatible programs from working, therefore the redirect of writes. Once this is done reads are also redirected, but in case of one file changing through compilation while the other does not, this obviously causes trouble, even though the mechanism of the VirtualStore is thought to be "transparent", that is any program does not notice it's writing and reading there instead of in \Program Files\. It does not work perfect.

Bye, Olaf.
 
Thanks Olaf! Your one suggestion that I haven't had time to try is the installation of VFP7 outside of the Program Files folder. Just haven't had time but that's something I'll probably do tonight.

I think this is also what DSumm is aluding to - or something like that. (thank you also for your help, DSumm)

It will be another day or 2 before I get back to really trying all of this. I'm really the secondary programmer on this project - my real job is running the company. However, I was a full-time programmer for about 20 years (about 10 of those in xBase systems) so, I have some "chops" even if they are rusty.

Thanks!
Al
 
I forgot to mention in my last post that what Olaf suggested is exactly what I did when I got my W7 machine. I installed VFP7 and VFP9 both outside the "Program Files" directory. In fact, I installed them both in C:\vfp7 and C:\vfp9 respectively.

Also, let me mention that 90% of the apps we develop around here are located and executed on a server. They require no local data.
And usually, there are no shared PCs. A computer is normally assigned to a single user, so data synchronization due to folder virtualization is a non-issue.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
I am pleased to report back to all of you that upon implementing your suggestions, all seems well at this point.

Now, I haven't had the time to get very deep into development work at this point but my builds are working and the few code changes I've done seem to be applying (though I have had to delete *.fxp a couple of times but I can live with that).

Uninstalling VFP7 from Program Files (x86) and reinstalling into c:\vfp7 cured a lot of ills. The remainders seems to have been using the suggestions about setting full permissions and run as admin on the vfp7.exe AND the DLLs (not sure what the permission thing was about on the DLLs but it did help, I think).

When I get my copy of VFP9, I'll definitely install it under C:\VFP9 and check all those permission/security items.

You all have been a great resource to me and I hope I can return the favor(s) at some point.

Thanks!
Al
P.S. Dave Summers - love your page! Even though I'm in Georgia and have never ice-fished, I fish a lot and enjoy looking at ice-fishing pictures. And your jokes!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top