[Harrison Pratt]

I've seen this addressed somewhere in the VIP 7.x discussion, but can't find it.

When using VIP 5.2 I managed my library of useful routines by including my primary stable utility code module (Glinda.pro & glinda.pre) within one module of my project, typically in the "App.pro" and "App.pre" files for that project. These would then automatically "include" additional modules of interest when I would add certain Predefined Constants (e.g., "use_GlindaCSV") to the Compiler options.

I'd like to be able to do something similarly easy with VIP 7.x, but can't seem to find Discussion Group topics addressing this issue.

Help!

[Thomas Linder Puls]

The best way to deal with that is to define a variable in the IDE (Tools -> IDE Variables...) which points to the base directory of your tools. Let us call it "Glinda" and give it the value "E:\Glinda".

In your project you will then add "E:\Glinda" as an include directory. The IDE will change that path to "$(Glinda)".

If you have several versions of your tools you can have them in sub directories of $(Glinda) then the include path you add to the project will instead point to the specific version, e.g. $(Glinda)v2.3.

The main reason for using a variable (rather than having an absolute indlude path) is to make it flexible where the on the disk "Glinda" is placed. If you move it to another place, you only have to change the variable value in the IDE, all other references goes through that variables value.

[Thomas Linder Puls]

See also: IDE Variables.

[Harrison Pratt]

Thomas,

Thanks for your explanation on managed my "Glinda" library code. I have not been able to make it work on my system, however.

My understanding of the process is thus: (1) Create an IDE variable with it's value set to the directory of my library; (2) add an include path by pointing to the library directory and then the include path is set as a named variable.

At this point, I think should be able to see the library code in the project tree -- but I don't. I have also tried closing and reopening the project, but still don't see the library code. Is there something else I should be doing?

Perhaps there is an IDE issue on my system as I get "internal error" messages when I try to tab from the new variable name to the value; the same error occurs when I left-click on the value, too. I have attached two screen capture images. (Of course, I am not actually trying to use 4 different GlindaX variables! Those were only used for testing that error event.) After closing the error dialog I can edit the value normally.

As you may recall I am running VIP 7.5 on WinXP.

[Paul Cerkez]

remove the '.' from 7.x in your path, make it 7x

I seem to remember having problems with that in some programs when in XP, especially if there were more folders deeper in the tree.

[Harrison Pratt]

Paul,

Good suggestion, but the '.' in the directory name was not the cause of the internal error problem in this case.

After renaming the suspect directory, I removed all my personal IDE variables and any reference to them in the Include settings. I then restarted the IDE, tried to create a new IDE variable and observed the same behavior.

The behavior of that table suggest that something is missing (or incorrect) in the event handling of new entries. The same error also occurs when adding an IDE variable when NO project is loaded.

Thanks for the hint,
Harrison

P.S. The above didn't fix the personal library Include issue, either.

[Thomas Linder Puls]

Did you press "Send" on the exception dialog?

After you have defined the variable and added the include path, you will also have to add the packages to the project.

[Harrison Pratt]

Thomas,

Yes, I sent the internal error dialog info 2 or 3 times, at least twice with a comment in the "what were you doing?" field.

I think I have sorted out my problem -- I was creating a New package which was overwriting the original Glinda library files (fortunately backed up). I wasn't certain whether just including the package was sufficient -- now I know it's not.

I'll experiment more tomorrow, now that I have the user-error issues under control.

Harrison

[Thomas Linder Puls]

We will examine the bug reports, thank you.

The .pack and .ph files in your library should have paths that are relative to the include directory in your project.

Consider PFC as an example. In your projects $(ProDir) is an include directory, and all the PFC lives relative to $(ProDir). So the file $(ProDir)\pfc\application\Exe\exe.ph looks like this:

Code: Select all

#requires @"pfc\application\Exe\exe.pack"
 
% publicly used packages
#include @"pfc\core.ph"
#include @"pfc\exception\exception.ph"
#include @"pfc\windowsApi\exe_api\exe_api.ph"
 
% exported interfaces
 
% exported classes
#include @"pfc\application\Exe\mainExe.cl"

When the compiler reads #include @"pfc\core.ph", it look at the include directories from top to bottom in the list:

• . (= the project directory): if .\pfc\core.ph exists that is the one to use.
• ..\..\somepath (relative to the project directory): if ..\..\somepath\pfc\cre.ph exists that is the one to use.
• ...
• $(ProDir): $(ProDir)\pfc\core.ph does exist, so if a mfile is not found above, this is the one to use.

The IDE take your include directories into account when it creates new packages/classes/dialogs/etc, and makes the include directories correct.

It is not such a bad idea to create a new class, corresponding to the one you already have because the IDE will then create .ph and .pack files with correct include directives in. From your backup you then restore the .i .cl and .pro files (the last step is actually not necessary, if you answer correct when the IDE ask to overwrite or reuse existing files).

[Harrison Pratt]

Thomas,

Thanks for the very helpful advice about the expected directory tree structure!

Harrison