PCK
block describes a package in the current
or an external archive.
This can only be specified in the
HEAD
block.
At least one package must be specified
to make WarpIN do anything meaningful.
See the "Installation Scripts"
page for an overview where this tag should be placed.
The <PCK> ... </PCK>
block has the following
syntax:
<PCK INDEX=x PACKAGEID="vendor\application\package\major\minor" TITLE="title" TARGET="path" [BASE] [FIXED] [SELECT] [NODESELECT] [REQUIRES="vendor\application\package\major\minor"] [CONFIGSYS="statement[|modifiers...]"] [REGISTERCLASS="classname|dllpath"] [REPLACECLASS="oldclassname|newclassname"] [CREATEOBJECT="[REPLACE] classname|title|location[|config]]"] [EXECUTE="execfile params"] [PROFILE="profile[\application[\key]]"] >package description displayed to the user</PCK>In between the
<PCK>
and </PCK>
tags,
you must specify the package description as it will be displayed to the user
in the "Information" window on the WarpIN container page. This description will
also be stored in the global database so that it is available during de-installation too.
The opening <PCK>
tag can have the following attributes:
INDEX=x
Note that this index only has to be unique for the current archive. It is not
stored in the global database and only used during the installation process.
PACKAGEID="vendor\application\package\major\minor"
The ID string must consist of exactly five substrings, separated by backslash ("\") characters. Avoid ASCII characters above 127 to make sure these strings work on all computers with all codepages. You may however use spaces in the substrings. The substrings are:
vendor
: your company or personal name. This is
displayed to the user.
application
: the name of the application to which
this package belongs. Since only packages, not archives, are stored in the
global database, this groups applications together. This is displayed to
the user only during de-installation.
package
: package ID. This
is only stored in the global database to identify the package.
The user sees what is specified with the TITLE
attribute instead (below).
major
: the major version number of the package.
minor
: the minor version number of the package.
SuperSoft\Super Word Processor\SpellingDict\1\0
TITLE="title"
PACKAGEID
attribute.
This is also stored in the global database and re-displayed during
de-installation. However, this is purely informational and not used to
identify the package.
TARGET="path"
"C:\TEST"
)
which WarpIN will initially propose to the user as the installation path
for the package. Normally, the user can then change this target path,
unless you also specify the FIXED
attribute (below).
This attribute supports macro resolution.
WarpIN will translate macros into actual directory names before
displaying the paths to the user. If an error occurs, e.g. because a variable
could not be found in the environment, WarpIN will complain and prompt for a
value when the container page is entered.
BASE
Example:
<PCK INDEX=1 ... TARGET="C:\TEST" BASE>Package 1</PCK> <PCK INDEX=2 ... TARGET="C:\TEST\SUBDIR">Package 2</PCK> <PCK INDEX=3 ... TARGET="D:\OTHER">Package 3</PCK>If the user changes the path of the base package (index 1) to
"D:\TEST2"
,
the path of package 2 will automatically be changed to "D:\TEST2\SUBDIR"
.
However, package 3 will not be changed since it does not contain the
"C:\TEST"
substring.
FIXED
TARGET
attribute cannot be changed by the user.
Otherwise the user may change this on WarpIN's container page.
This is useful for files which must be written to the OS/2 system directories.
SELECT
NODESELECT
REQUIRES="vendor\application\package\major\minor"
PACKAGEID
attribute.
This is useful if a package in your product is an add-on to some other software which is
distributed in WarpIN archive format also. This requires you to know the ID string
of that package.
Note that in this context, the version substring
("major\minor"
) is understood as the minimum
version of that package which is required for your package to work.
When this attribute is specified, WarpIN will query the user computer's
global database
for the specified package. If that package is not installed or too old, WarpIN will give the user a
warning message.
CONFIGSYS="statement[|modifiers...]"
"statement"
and optional "modifiers"
.
If this is specified for any package which has been selected for installation, WarpIN will display a corresponding checkbox on the "System Configuration" page (see the PAGE tag for more on that).
This supports macro resolution.
See "CONFIG.SYS changes" for about this attribute.
Examples:
<PCK INDEX=2 ... CONFIGSYS="SET PATH=$(1)\BIN | ADDRIGHT" CONFIGSYS="BASEDEV=CRASHSYS.ADD /DOCRASH | UNIQUE" >
REGISTERCLASS="classname|dllpath"
"classname"
with the WPS,
which must reside in the "dllpath"
DLL.
There can be several such attributes per package, all of which will be
processed in the order specified in the script.
If this is specified for any package which has been selected for installation, WarpIN will display a corresponding checkbox on the "System Configuration" page (see the PAGE tag for more on that).
"dllpath"
must be the full path name of the DLL containing the
class. If this DLL resides on the LIBPATH
, no path is required though.
It is not recommended however to place WPS DLL's on the LIBPATH
, because
this makes de-installation more difficult.
The "dllpath"
substring supports
macro resolution.
Example: <PCK INDEX=2 ... REGISTERCLASS="XFolder|$(1)\bin\xfldr.dll">
REPLACECLASS="oldclassname|newclassname"
"oldclassname"
with
"newclassname"
. "newclassname"
must have
been registered using the REGISTERCLASS
attribute before replacing.
(All REGISTERCLASS
attributes are processed before the
REPLACECLASS
attributes by WarpIN.)
There can be several such attributes per package.
CREATEOBJECT="[REPLACE] classname|title|location[|config]"
"|"
characters.
There can be several such attributes per package.
Parameters:
REPLACE
classname
REGISTERCLASS
attributes are processed before the
CREATEOBJECT
attributes by WarpIN.
title
location
The "location"
substring supports
macro resolution.
config
The "config"
substring supports
macro resolution.
Note: You should give all your objects object ID's (like
"OBJECTID=<APP_OBJECT>"
), because otherwise WarpIN will not
be able to delete your WPS objects upon de-installation.
Example: This will create a "SuperWord" folder on the Desktop and a program object for the "suprword.exe" executable in that new folder, using the target path specified with this package.
<PCK INDEX=1 ... CREATEOBJECT="WPFolder|SuperWord Installation|<WP_DESKTOP>|OBJECTID=<SUPERWORDFOLDER>" CREATEOBJECT="WPProgram|SuperWord|<SUPERWORDFOLDER>|EXENAME=$(1)\bin\suprword.exe;OBJECTID=<SUPERWORD>" >
EXECUTE="execfile params"
"execfile"
will
be started in a separate session using
"CMD.EXE /C execfile params"
so that you can also
start a REXX script.
Both "execfile"
and "params"
support
macro resolution.
[PROFILE="profile[\application[\key]]"]
We strongly recommend specifying this attribute if your application stores
any data in the system profiles. You can specify more than one PROFILE
attribute per package.
"profile"
specifies the INI file which should be cleaned
up upon de-installation. This can be "USER"
or "SYSTEM"
for the user or system profiles (usually OS2.INI
and
OS2SYS.INI
) or an explicit full path specification of an INI file.
This supports macro resolution.
"application"
specifies the application to be cleaned
up in the profile. If this is not specified, the whole profile is deleted.
"key"
specifies the key to be cleaned in
"application"
of "profile"
. If this is not specified, the whole application
is deleted.