Moving files (for example .vcx)

[mpgalvin]

I've written a VFP7 app which has my own class in it. This class consists of controls and forms which are used extensively throughout the app.

I now want to move the .vcx file to a different directory, so that I use it in multiple apps without having to make changes to multiple copies of the same file. Make sense?

I figure after moving it, I should USE the scx, and pjx tables manually and change the folder from the old one to new one. Is this possible? Does anyone have a quick and dirty find and replace function I can use? If this is not the best way, what is? Bear in mind that most of the my forms are classes, so opening them causes errors galore.

 

[ramani]

HI

It is better now than late !

I suggest the following directory structure.

1. The project Directory
2. Within Project Directory... following directoris..
Common, Class, Forms, Repts, Progs, Picts, Data
3. Within Common Directory..
Class, Forms, Repts, Progs, Picts, Tables

All the relevant "to this project"..... follows the directories in the project directory (I dont have to explain in detail), while the Common for all projects follow the directories within Common Directory. Here the question as to why the common directory is inside the project directory and not kept outside the project, which can be more easy to migrate is 'questionable'. But changing of common code, playing havoc on the projcts already completed, showing the glitch on some bad day, is what I am avoiding. By keeping the common directory within the project, if we want, we can just use a copy command and set that all. So not a big matter.

So when we start a project, all the common files get into the new projct directory with copy command and the skeleton is ready... That is how I get the start. (This acts more like my own frame work).

Now coming to your spcific question in this thread.....
If you decide to change the directories now... make that now and do reorganise... When you recompile, the project manager will try to locate missing files, and all you have to do is LOCATE as it guides you. The whole relocations will get thru'. Also remember not to have same names for files though in different dirctories. Because the auto locating by project manager can read matters differently and land you in trouble. Also never use any path in any of your hard code. That is a pitfall.

Regarding any utility for such actions, I am still not infavour (may be I have not landed in such requirements!).

Hope the idea helps

ramani :-9
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[mpgalvin]

Ramani, as always you're the man. I was kinda hoping to avoid the VFP "locate" thing, though, and just change the paths myself. That way, I don't have to go into each and every form, click "Locate", find the new directory, save, etc.

Isn't there a better way? (And yes, better late than never, but sometimes, I prefer 'never' )

 

[ramani]

HI
When the locate function appears, that is memorised by VFP. So for the repeated usage of that file, VFP wont ask you to locate again. In some cases, I dont know when (as I dont get into this situation often), the located directory is looked into for other files.. before asking you to locate. SO this shall not be a big problem and also far far easier than doing it yourself.
ramani :-9
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[csr]

This is not really addressing your problem but I am just curious about something.

The idea of having a "central" set of classes used in several applications is something that (in my mind) is a nice idea but doesn't really work.

First of all, when I finish an application, I have no reason to care if the routines I used in that one are the same as routines I used in the next one. So when I change routines in the future I do not care to have this affect past applications. In fact, if I am not very careful about this I will screw up my past applications by making changes to classes that are part of a "centralized" set of classes.

I just copy the VCX files into my new application and make changes as I see fit for the new app without regard for historical ones. Seems to work fine.

Any other comments about this topic ?
Don
dond@csrinc.com

 

[RoadRunnerOz]

I agree with Don. All my programs are based on a common framework BUT every time I start a new project I simply copy my last project to a new directory. I then recompile the new application AFTER renaming the old application directory ( this way the new project does NOT pick up files from the old directory, ever get caught with this one? ). Any classes I change for the new application only affect it. If an improvement is worthwhile I "may" copy it to an old application when it need upgrading. The downside is that I have 50 copies of each class that may only have slight differences. The upside is that I know that revisiting a 2 year old application & recompiling will ALWAYS work. I never have to chase down a simple change that my last application needed. I also zip all project files using backuppjx.prg, just in case.
Michael Ouellette
mouellette@compuserve.com

 

[csr]

Sounds like Mike and I attended the same "school". It is interesting to hear how different developers deal with things.

My method is ....

I have a separate subdirectory in which I keep ....

main.prg (Startup program)
main.mpr,mpx,mnt,mnx (Main menu files)
classes.vcx,vct (Classes library)
sysstruc.dbf (Datafile structures)
systags.dbf (Datafile tags)

When I start a new application. I copy these files into a new subdirectory and build it. Zippo .... mainmenu,file maintenance routines, handled automatically. Now I begin to build forms for this application.

If I make any generic changes to those startup files I update them in that separate subdirectory.

I also can go back to any application years later and rebuild with 100% assurance it will rebuild properly (well, 99% anyway .... you never can say 100 .. I have learned.)

Good to hear someone else has the same mindset as my own.
I sometimes think I am the only one not using fancy methods.
Don
dond@csrinc.com