Changing Class library path to relative

[gkratnam]

The frmcapacity class is being used my multiple applications and it has been working fine with the current absolute path setup.

Class: frmcapacity
ClassLibrary path: X:\vfpcondor\rwtracker\pmlibrary\vfpcasses.vcx

The code is written like this.

Set Default To (LPRGDIR)
Set Classlib To (LPRGDIR) + "pmlibrary\vfpcasses.vcx"
-------
ofrm = Createobject("frmcapacity")

But we are moving some of the applications to another server which does not have the same drive mapping.

The new setup will be:
Class: frmcapacity
ClassLibrary path: E:\vfpcondor\rwtracker\pmlibrary\vfpcasses.vcx

How can we change the path to relative? Or is there any other way to make this work. Please assist.

Thanks!

 

[Chris Miller]

Not sure what you want to achieve.

A relative path means relative to some reference. As you already define a base path LPRGDIR as a variable (I assume) or a field, the rest of the path is obviously relative to LPRGDIR.

When you SET DEFAULT TO (LPRGDIR) and want to let other paths not depend on this LPRGDIR variable or field, then you just will introduce possible problems when some library makes a temporary change of the default path. It's not unusual for data access classes to CD into the backend directory.

Lets assume this aspect never becomes a problem, then the only other problem I see right away is when you want relative paths to other drives. There is no such thing in Windows, relative paths always must be on the same drive letter or sharename.

I still wonder what problem you think you're facing at all. Is it that ONLY that classlibrary moves from X: to E: mapping? When all the rest of the project is on X:, too, then the move to E: will just mean once opening the PJX project and acknowledge the question for a new home directory with Yes/OK.

Chriss

 

[Mike Lewis]

This shouldn't be a problem.

In the development environment, the first time you open the project after moving to the new server, you will be prompted to set the project's home path to the new path. After that, all the paths to the class libraries will reflect the new path.

When running from an EXE, the class libraries will be bound into the EXE and the paths will be ignored.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Yes, Mike, as I said

When all the rest of the project is on X:, too, then the move to E: will just mean once opening the PJX project and acknowledge the question for a new home directory with Yes/OK.

The absolute path shown in the properties windoww also is a red herring. For example, am SCX based on a form class will have a relative path in its Classloc memo field, as long as a relative path is possible, ie the scx is on the same drive as the vcx.

So moving a project has to do nothing with each scx or vcx to fix the new home directory. That's solely adjusting a value on the project level.

Chriss

 

[gkratnam]

Thanks All for all the guidance. Opening the project in the new server did solve part of the problem, the drive mapping is switched from to X to E, but there is more to it.
Let me try to explain this better, sorry I was not clear at the beginning.

Class: frmcapacity – This is a screen(Capacity) which has bunch of controls that “Saved As Class” in trackerform.vcx class library. The controls in the screen(Capacity) are from another class library (vfpclasses.vcx).

1) Why is the ClassLibrary shows the vfpclasses.vcx here instead of trackerform.vcx?

2) It seems we need to move the classes that are being used in the screen (Capacity which is saved as frmcapacity) to the new drive as well. These libraries(eg: vfpclasses.vcx) are used by other applications which we don’t want to move to the new server.


After moving the project to the new server, when running this message comes up.

We prefer to do development and builds in the current server and just deploy it in the new server. Could we do that without opening the project and it’s related libraries in the new server?

Thanks!

 

[Chris Miller]

I can answer the first question When you use Saveas Class of one or more selected controls or the whole form, this is not inheritance of the form. Any modifications you do in the form will not also appear in the saved class or classes.

But lets assume a situation with real inheritance starting with a Baseform class inheriting from the native VFP form class and a Formcapacity class inheriting from Baseform, then creating a form based on Formcapcity will also show Formcapacity as the class and the VCX its part of, not the Baseform and its VCX nor just form. This inheritance chain is resolved by Formcapacity knowing it was derived from Baseform.

When the vfpclasses.vcx is in a parent folder of the project as it was on X: and you have neither moved it to E: because other projects on X: still need it there nor you copied it to X: into the same relative location to the scx, then, yes, that's the error you should expect. Since you now don't have an X: mapping or that maps to a different share now because of some server consolidation, you could either copy it there as well and have this (and likely many other) vcx libraries stored on both X: and E:, with the long term risk of changes not synced to both locations of the common class libraries.

Or you do the same consolidation and choose a new path all developer clients have mapped and use the Locate button of that message once to fix the classloc.

And as Mike already said, once this all is compiled in an EXE, the users neither need the X: nor E: mapping to get at the libraries, a VCX isn't a DLL dynamically linked to an EXE you build in VFP, it's included in the EXE when you build it and paths won't matter from that point on.

You'd have to exclude files from the build so an EXE would actually need access to the VCX files to use the libraries as they are right now. This could be used to make changes without needing to rebuild an EXE, but it's not recommendable nevertheless.


Chriss

 

[gkratnam]

I was able to resolve the issues by using all of your inputs. Created dedicated classes and introduced some new modules. Then included the library in the executable.

The library was not part of the executable originally to avoid unnecessary load since it has other classes that don't needed by this app.

Thank you!

 

[Chris Miller]

gkratnam, great to hear.

Do you compile libraries shared by several applications to APPs? It sounds as if so.

The apps can aggregate or separate classes and libraries however you want and the only path that will matter to an exe using an app is the path to the app. The chain of inheritance paths to other libraries vanishes like it vanishes in an EXE, too. To use an app you can both DO some.prg in some.app or use a class with NewObject('class','some.vcx','some.app') and obviously the easiest path to have to the app or apps is by putting them side to side to the EXE just like DLLs and FLLs and let them be updated to clients just like the EXE itself.



Chriss

 

[gkratnam]

Thanks for all the suggestions and good tips Chriss!

I will apply them to other modules that we need to move.

Thanks!