|
|
 |
X-Setup Pro SDKFile format description
X-Setup Pro 7.0 (and upwards) use a new file format to store plugins, wizards and translations. We have decided to use XML files as the new file format since this give us a great level of flexibility to easily enhance X-Setup Pro in the future with new features. Since now all “items” X-Setup Pro (XSP) uses (Plugins, Wizards and Translations) are XML based, we only need one function inside XSP to read them which is big step forward. Additionally, since you can easily transform any XML file format to another using XSLT functions, we are also able to quickly transfer any item to HTML which is great for documentation. XSP 7.0 and upward versions is only able to read the new XML-based file format, it does not support the new old XPL/XWZ file format. If you have an old XPL plugin you wish to use in a new version also, you can simply download and execute “xqdcXSPPluginConverter.exe” which can transfer the old XPL file format to the new XPPL format with the click of a button. The new *.xppl (Plugins), *.xpwz (Wizards) and *.xppl.XX or *.xpwz.XX (Translation) files all use the same basic format. Format of XPPL (Plugin) files:<?xml version="1.0" encoding="Windows-1252"?> XML start header, always required as first line <x-setup-pro-item version="1" type="plugin"> Root node for XSP items. Attribute “Version” does currently only supports the value “1”. Attribute “Type” can be “plugin”, “wizard” or “translation”. <xspitem type="editfile" version="1.02" adminreq="1" warning=”1”/> Attribute “Type” (only for plugins) determines which type the plugin is of. Supported values are:
• “edit”: Simply edit (input) fields. The attribute "Version" simply contains the version of this file, e.g. "1.03", "2.14" etc. "Warning" set to 1 will cause the item to be marked as "System Critical". "AdminReq" indicates if a user with administrative rights is required to execute the plugin. "RestoreLog" tells XSP where to save the restore log information for the given file. If set to "usr" it is saved to the user part of the restore log, in any other case to the system location. If this attribute is missing, XSP will use the attribute "AdminReq" to get this information (AdminReq = 1 = System).
<xspitem-author> Several nodes that describe the author of the file.
<xspitem-comment> A comment for the author to provide information; can also be used for internal nodes. Please note that this can not be translated!
<xspitem-data> Generic Data node, currently only used when plugin-type is “editfile”. It specifies the file filter to be used. Needs be in the form "|". For example setting "Bitmap Files|*.bmp|All Files|*.*" will result in an file open dialog with a Filter for BMP and all files. Please note that you need to specify the filter for each "..." button you wish to create.
<xspitem-osversion> The “xspitem-osversion” node lists on which Windows version the item is able to execute. If an item does not run on a Windows version, this tag can simply be left out. For example, an item that can only be executed on Windows XP and Windows 2003 should have this xspitem-osversion node: <xspitem-osversion> <winXP>1</winXP> <win2003>1</win2003> </xspitem-osversion> XSP will automatically disable the item on all Windows versions that are not listed. If there is no xspitem-osversion node, the plugin is allowed to execute on any Windows version. <xspitem-text> xspitem-text contains all text resources that can and should be translated. The node “Name” specifies the name of this item. “paths” contains the path(s) that will be shown in the XSP interface, sub-entries can be created by using "\". In this example, the item will show up in two different paths: First, below “System” inside the path “Number One” and secondly inside the path “Number Two” below “Memory”. You can specify up to five different paths. “items” describe how many user interface controls should show up. In our example (type=editfile) there will be two edit fields with “…” button beside it. The first will be named “Bitmap” and the second “HTML”. The maximum of allowed items is five. “strings” list text strings that can be retrieved by the plugin using the GetTextString(index). The reason for this node is that some plugins simply show a message to the user, for example “The registry path has been cleared!” which would be normally hard-coded inside the plugin code. This would require a translator to change the code to fully translate a plugin. Important: Do not save spaces into this text string. If you want to have a space before or after a text, use code to do this, do not save the space to the strings node. A translator can easily oversee this and thus your space is gone. Using the “strings” node, you can easily store a text string inside the xspitem-text area which can later on be translated. When the plugin then displays a message using the Code “MsgInformation(GetTextString(1))” it will retrieve the translated string so the user sees a localized message. “description” finally contains the description of the file so the user knows what this file does. <xspitem-linked-codemodules> These tags can be used to link an external file (*.XPCM) that contains source code for the current plugin. This has been done to avoid having the same source code in several plugins repeated but instead use a code module that is linked to several plugins. "<xspitem-linked-codemodules>" can contain an unlimited number of code modules that should be loaded. The code module to be loaded must be in the same folder as the plugin and it must have an *.xpcm extension. The filename used inside the <module/>" tag must not contain the extension since this will be added by X-Setup Pro automatically. Code modules are loaded when a plugin is loaded and will be appended to the current plugin source code. The file format of a code module is basically the same as a plugin, except it does only contain the xspitem-code tag: <?xml version="1.0" encoding="Windows-1252"?> <xspitem-code language="VBScript"> <
Format of XPPL (Plugin) files