Managing previously created "external" Packages in a project

Discussions related to Visual Prolog
Harrison Pratt
VIP Member
Posts: 283
Joined: 5 Nov 2000 0:01

Managing previously created "external" Packages in a project

Unread post by Harrison Pratt » 23 Oct 2014 21:56

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!

User avatar
Thomas Linder Puls
VIP Member
Posts: 1622
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls » 24 Oct 2014 8:38

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.
Attachments
glinda_tree.png
Tools Project tree
glinda_tree.png (13.83 KiB) Viewed 2719 times
glinda_settings.png
Tools Project Settings
glinda_settings.png (33.62 KiB) Viewed 2719 times
glinda_variable.png
IDE Variable
glinda_variable.png (17.98 KiB) Viewed 2719 times
Regards Thomas Linder Puls
PDC

User avatar
Thomas Linder Puls
VIP Member
Posts: 1622
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls » 24 Oct 2014 9:08

See also: IDE Variables.
Regards Thomas Linder Puls
PDC

Harrison Pratt
VIP Member
Posts: 283
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt » 28 Oct 2014 14:57

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.
Attachments
IDE Clip 1.jpg
Internal error on attempt to initially access variable value.
IDE Clip 1.jpg (60.98 KiB) Viewed 2658 times
IDE Clip 2.jpg
IDE Variable dialog after closing error dialog.
IDE Clip 2.jpg (24.22 KiB) Viewed 2658 times

Paul Cerkez
VIP Member
Posts: 202
Joined: 6 Mar 2000 0:01

a simple suggest (may not work)

Unread post by Paul Cerkez » 28 Oct 2014 18:03

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.
AI Rules!
P.

Harrison Pratt
VIP Member
Posts: 283
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt » 28 Oct 2014 19:07

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.

User avatar
Thomas Linder Puls
VIP Member
Posts: 1622
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls » 28 Oct 2014 22:02

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.
Regards Thomas Linder Puls
PDC

Harrison Pratt
VIP Member
Posts: 283
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt » 29 Oct 2014 3:44

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. :oops:

Harrison

User avatar
Thomas Linder Puls
VIP Member
Posts: 1622
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls » 29 Oct 2014 9:49

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).
Regards Thomas Linder Puls
PDC

Harrison Pratt
VIP Member
Posts: 283
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt » 29 Oct 2014 21:39

Thomas,

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

Harrison

Post Reply