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

Transfer VFP9 project from 32 bit laptop to 64 bit desktop 2

Status
Not open for further replies.

fourletr

Technical User
Dec 1, 2003
29
CA
I have a comprehensive application ( Church Management) developed on a 32 bit platform. I now want to transfer it to my 64 bit Win 7 machine. However just copying the files over the network loses most of the graphics and vcxs. Is there a utility for exporting a complete project from a 32 bit machine to a 64 bit machine. The problem seems to be that on a 64 bit machine VFP installs all its "bits and pieces" in programfiles(x86) and no just plain old programfiles. (THANK YOU MICROSOFT!!!

Richard Myers (aka - fourletr)
Burlington - Ontario
Canada
 
This is only coincidentally related to 32bit vs. 64bit.

It sounds like you've used image files from the VFP directory in your project in a different directory.

That's easy enough to fix. When the project manager asks for one of the files, go and find it in its new location and VFP will find all of the of the other files in that location just fine.

A better long-term solution is to move a copy of all files needed for your project into a file/folder hierarchy under your project so that when you move the tree the entire tree stays in place. That would be sound/practical file management. You don't want to rely on outside sources for something you use in your application.

 
>It sounds like you've used image files from the VFP directory

Indeed, and normally that would make use of HOME(). If you use FFC, there are quite a lot references making use of HOME() to reference files in the VFP directory. Then it wouldn't matter where VFP is installed, as HOME() would always point to it. Also within classes and objects of the VFP Directory paths are stored relative and that also wouldn't matter.

It's not the way picture references work, though. Within a scx or vcx class the picture property does not make use of expressions like HOME(), you have relative paths stored in there. So that wouldn't be a problem, either. But using the grpahics in your own objects within files you have in your project folder, you neither have relative paths nor HOME() expressions, but absolute paths in your picture properties.

That's another reason why using foxpro classes and graphics is to be avoided to keep all your project self contained. Even if you copy them inside your root project folder you would get awkward references from there to HOME() folder parent classes etc and that's also no healthy project state.

Dan is right, just specifying a graphic in it's new location, then save. That mends this case. Other classes/objects will also find the new location, too, but only during the current VFP session, if VFP finds some file in a new location it has memorized by your earlier adjustment, that'll mean you get no dialog asking for redirection, but then there is no change to the vcx/scx and so it still has a wrong reference inside that's just auto-corrected for the current session. VFP doesn't memorize path changes forever. Next time you start vfp and open up some other vcx first that hasn't been changed, that'll prompt for finding a graphic or parent libraries, etc. If you want to tidy up the whole project, you should use some utility like hackscx to adjust all paths.

And no, I wouldn't blame MS. The FFC classes are so old, they are out of support and test. Also you have a choice where to install VFP, you could simply reinstall it in the old /program files/ folder, just create it. You'll have problems with a VFP installation into protected system folders anyway. Many prgs and other stuff within HOME() is just compiled or indexed or generated at first use (eg first time using Code References generates some DBFs) and all that isn't written in /program files(x86) but in your user profile because of redirection of write operations.

Bye, Olaf.
 
Richard - it's not clear to me whether you're the developer of this application (which is what Dan and Olaf assumed), or a user of the application.

If you're a user, you need to find the original installation media and reinstall the application to make sure everything lands where it should. Then, you'll need to copy your current data files onto the new machine, overwriting the data files created by the install program.

Tamar
 
Hi Tamar:
Yes I am the developer (now retired) but in need of some additional income (aren't we all) I decided to resurrect this app and transferred it to a 64 bit computer for see if I can bring it up to speed.

However thanks to Dan and Olaf's input I've more or less cracked it simply by installing VFP 9.0 into Program Files instead of the (86) folder. Seems to work OK. With the benefit of hindsight I wold have copied all the various ancillary vcxs and graphics into my main folder but it's too long ago now. This app was originally written (by me) in Foxpro 2.1 win and used for many years by a number of local churches, they've all moved on now but I thought it worth "dusting off" and seeing if anyone is interested.

Thank you for your interest, always been a fan of yours especially using that wonderful error program you wrote for DOS and Windows versions of Fox.

Best regards

Richard Myers

Richard Myers (aka - fourletr)
Burlington - Ontario
Canada
 
Thanks for the kudos, but I never published an error handler. Maybe you're thinking of Pat Adams?

Tamar
 
Oooops, sorry, you are of course quite correct it was Pat Adams' error handler I used to use. Your name is so familiar because of your excellent contributions the Whil Hentzen's Hacker's Guides. My 82 year old brain is not quite as reliable as it used to be !<BG>
Regards,

Richard Myers (aka - fourletr)
Burlington - Ontario
Canada
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top