-
- VIP Member
- Posts: 452
- Joined: 5 Nov 2000 0:01
Managing previously created "external" Packages in a project
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!
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
- VIP Member
- Posts: 1424
- Joined: 28 Feb 2000 0:01
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.
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.
- Attachments
-
- Tools Project tree
- glinda_tree.png (13.83 KiB) Viewed 19366 times
-
- Tools Project Settings
- glinda_settings.png (33.62 KiB) Viewed 19366 times
-
- IDE Variable
- glinda_variable.png (17.98 KiB) Viewed 19366 times
Regards Thomas Linder Puls
PDC
PDC
- Thomas Linder Puls
- VIP Member
- Posts: 1424
- Joined: 28 Feb 2000 0:01
-
- VIP Member
- Posts: 452
- Joined: 5 Nov 2000 0:01
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.
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.
- Attachments
-
- Internal error on attempt to initially access variable value.
- IDE Clip 1.jpg (60.98 KiB) Viewed 19305 times
-
- IDE Variable dialog after closing error dialog.
- IDE Clip 2.jpg (24.22 KiB) Viewed 19305 times
-
- VIP Member
- Posts: 106
- Joined: 6 Mar 2000 0:01
a simple suggest (may not work)
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.
I seem to remember having problems with that in some programs when in XP, especially if there were more folders deeper in the tree.
AI Rules!
P.
P.
-
- VIP Member
- Posts: 452
- Joined: 5 Nov 2000 0:01
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.
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
- VIP Member
- Posts: 1424
- Joined: 28 Feb 2000 0:01
-
- VIP Member
- Posts: 452
- Joined: 5 Nov 2000 0:01
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
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
- VIP Member
- Posts: 1424
- Joined: 28 Feb 2000 0:01
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:
When the compiler reads #include @"pfc\core.ph", it look at the include directories from top to bottom in the list:
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).
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"
- . (= 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.
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).
Regards Thomas Linder Puls
PDC
PDC
-
- VIP Member
- Posts: 452
- Joined: 5 Nov 2000 0:01