Hi,
I would like an imported library function to be able to determine its own
path. This is required so that it can import another library from the same
directory. Currently, if I move the two libraries to another folder, I
have to modify the first one to reflect the new location. I have been
after a neat solution for years.
Ideas please...
David Watling
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
I would like an imported library function to be able to determine its own
path. This is required so that it can import another library from the same
directory. Currently, if I move the two libraries to another folder, I
have to modify the first one to reflect the new location. I have been
after a neat solution for years.
Ideas please...
David Watling
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
We use to work with a mixture of configuration files (as suggested by Paul Fowler) and environment variables.
Configuration files to define the port number or which is the library name to be loaded. Main program is located in one directory and libraries with equipment communication and additional code is in other directory.
Environment variables are used in order to define which is the root directory of configuration files and which is the root directory of vee programs. They are loaded in main program by using "getEnv" object. For us, it works fine. In this way you can change of installation directories without problems only modifying the environment variables.
Of course other issue is if is good or not to name functions of libraries predefined by the name of the library or not. That is, lib_name.func_name or only func_name.
Doing in one or other way have advantages and disadvantages (too long to explain in this mail). We use to do it with the func_name and we try to define functions names "always" with a different name (for equipment communications is easy because you only have to declare function name with an acronym of the equipment at the end of it). But it would depend on your type of applications and requirements.
I cannot understand exactly when you say that you have to load twice the same file. In any case, you can use "delete library" object to be sure the library is good reloaded.
Regards,
> -----Mensaje original-----
> De: Brian.Hick@Zarlink.Com [mailto:Brian.Hick@Zarlink.Com]
> Enviado el: viernes, 20 de junio de 2003 16:18
> Para: VEE vrf
> Asunto: [vrf] RE: Library path
>
>
>
> Thanks Martin, I have tried this approach, but as yet cannot find an
> environment variable which gives me the source directory of
> an import - all
> I can get is the source directory of the top-level program (or of VEE
> itself). The information must be held somewhere, since if you
> try to import
> the same library from the same source twice, no action is
> taken; whereas if
> you import, the same library, with the same name, but from a different
> source, the original is deleted and the new one imported.
>
> Any suggestions on the right environment variable to try?
>
> Best regards,
>
> Brian
>
>
>
>
>
> "Martn
>
>
> Castillejos, Juan To: "VEE
> vrf" <vrf@it.lists.it.agilent.com>
>
> Carlos" cc:
>
>
> <jcmartin@indra.e Subject:
> [vrf] RE: Library path
>
> s>
>
>
>
>
>
> 18-Jun-2003 05:42
>
>
> PM
>
>
> Please respond to
>
>
> "Martn
>
>
> Castillejos, Juan
>
>
> Carlos"
>
>
>
>
>
>
>
>
>
>
>
>
>
> What about using environment variables of the operating
> system? You can
> code your programs to load libraries that exits in a specific
> directory
> that is obtained by means of a OS environment variable called
> always the
> same but with different value depending on your tests or target.
>
> Regards,
>
>
> > -----Mensaje original-----
> > De: Brian.Hick@Zarlink.Com [mailto:Brian.Hick@Zarlink.Com]
> > Enviado el: mircoles, 18 de junio de 2003 18:37
> > Para: VEE vrf
> > Asunto: [vrf] Library path
> >
> >
> > >I would like an imported library function to be able to
> > determine its own
> > >path. This is required so that it can import another
> > library from the
> > same
> > >directory. Currently, if I move the two libraries to
> > another folder, I
> > >have to modify the first one to reflect the new location. I
> > have been
> > >after a neat solution for years.
> >
> > >David Watling
> >
> > I think what Dave was asking (because I want the same!)is this:
> >
> > we have a library of functions which our users' programs are
> > importing,
> > which itself imports a daughter library. There are reasons
> > concerned with
> > execution priorities etc why the two cannot be merged. For
> > portability, we
> > want the mother library to import the daughter from the same
> > directory as
> > that from which it was itself imported, wherever that might
> > happen to be.
> >
> > It is easy to determine (we are using Vee 6.01) from where
> > VEE was loaded,
> > and from where the users' program was loaded, but we cannot
> > find a way to
> > determine from where the mother library was imported, other
> > than by putting
> > the path into a variable at the time the mother is imported,
> > and then using
> > that variable within the mother to import the daughter from the same
> > directory.
> >
> > This is OK, but we want to avoid mandatory software that our
> > user has to
> > include, and would prefer to make the whole thing
> > self-contained within the
> > mother library.
> >
> > Anybody got any suggestions?
> >
> > Thanks,
> >
> > Brian
> >
> >
> >
> > ---
> > You are currently subscribed to vrf as: jcmartin@indra.es
> > To subscribe send a blank email to
> "join-vrf@it.lists.it.agilent.com".
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email
> > "vrf@it.lists.it.agilent.com".
> > If you need help with the mailing list send a message to
> > "owner-vrf@it.lists.it.agilent.com".
> >
>
> ---
> You are currently subscribed to vrf as: Brian.Hick@Zarlink.Com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
>
>
>
>
>
> ---
> You are currently subscribed to vrf as: jcmartin@indra.es
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".