updated docs, tutorial, changelog
git-svn-id: https://svn.code.sf.net/p/nsis/code/NSIS/trunk@2281 212acab6-be3b-0410-9dea-997c60f758d6
This commit is contained in:
parent
72a48c4afc
commit
39a9897cd8
5 changed files with 62 additions and 29 deletions
|
@ -1,4 +1,4 @@
|
|||
bin\halibut.exe config.but intro.but usage.but script.but var.but labels.but jumps.but functions.but callback.but pages.but attributes.but compilerflags.but sections.but usection.but basic.but registry.but generalpurpose.but flowcontrol.but file.but uninstall.but misc.but string.but stack.but int.but reboot.but log.but sec.but ui.but langs.but plugin.but compiler.but defines.but modernui.but tutorial.but usefulfunc.but history.but credits.but license.but
|
||||
bin\halibut.exe config.but intro.but tutorial.but usage.but script.but var.but labels.but jumps.but pages.but sections.but usection.but functions.but callback.but attributes.but compilerflags.but basic.but registry.but generalpurpose.but flowcontrol.but file.but uninstall.but misc.but string.but stack.but int.but reboot.but log.but sec.but ui.but langs.but plugin.but compiler.but defines.but modernui.but usefulfunc.but history.but credits.but license.but
|
||||
@copy Contents.html index.html
|
||||
@copy index.html IndexPage.html
|
||||
@copy *.html ..\\
|
||||
|
|
|
@ -1,9 +1,17 @@
|
|||
\H{functions} Functions
|
||||
|
||||
Functions are like similar to Sections in that they contain zero or more instructions. Functions are not called by the installer directly, instead they are called from Sections using the Call instruction (Note: there are some special Callback Functions that can be called by the installer directly).
|
||||
Functions are like similar to Sections in that they contain zero or more instructions. User functions are not called by the installer directly, instead they are called from Sections using the Call instruction. Callback functions will be called by the installer when a certain event occurs.
|
||||
|
||||
\b Functions must be declared outside of Sections or other Functions.
|
||||
Functions must be declared outside of Sections or other Functions.
|
||||
|
||||
\b Function names beginning with "." (e.g. ".Whatever") are generally reserved for callback functions.
|
||||
\S1{ffunctioncommands} Function Commands
|
||||
|
||||
\b Function names beginning with "un." are functions that will be generated in the Uninstaller. Hence, normal install Sections and functions cannot call uninstall functions, and the Uninstall Section and uninstall functions cannot call normal functions.
|
||||
\S2{ffunction} Function
|
||||
|
||||
\c [function_name]
|
||||
|
||||
Begins and opens a new function. Function names beginning with "." (e.g. ".Whatever") are generally reserved for callback functions. Function names beginning with "un." are functions that will be generated in the Uninstaller. Hence, normal install Sections and functions cannot call uninstall functions, and the Uninstall Section and uninstall functions cannot call normal functions.
|
||||
|
||||
\S2{ffunctionend} FunctionEnd
|
||||
|
||||
This command closes the current open function.
|
|
@ -2,11 +2,33 @@
|
|||
|
||||
\e{v2.0b3}
|
||||
|
||||
\b Modern UI 1.63: Header bitmap support, new defines to change the description area, single macro for language selection dialog, more!
|
||||
|
||||
\b New tutorial in the documentation
|
||||
|
||||
\b define_if_last in Page command also works when a define has not been specified for all Page commands.\\<br\\>This fixes the problem with the Modern UI "Click Next" / "Click Install" texts.
|
||||
|
||||
\b Added SectionSetInstTypes and SectionGetInstTypes
|
||||
|
||||
\b Reboot commmand does not force a reboot anymore (allows the user to save work)
|
||||
|
||||
\b !if[n]def/!else fixes
|
||||
|
||||
\b LogSet fixed
|
||||
|
||||
\b Modern UI version 1.62b: Start Menu page changes: 'Do not create shortcuts' checkbox can be removed, renamed defines. Documentation updates.
|
||||
\b Cancel button available on all pages after the instfiles page but the last page unless /ENABLECANCEL was used in its Page command
|
||||
|
||||
\b License page: No more limit on RTF size
|
||||
|
||||
\b LangDLL: Option to auto-count number of languages, shell font support
|
||||
|
||||
\b Page and UninstPage can not be used inside sesctions/functions
|
||||
|
||||
\b CreateDirectory can now set errorflag
|
||||
|
||||
\b EnumRegKey/Value output_var check fixed
|
||||
|
||||
\b Updated translations
|
||||
|
||||
\e{v2.0b2}
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
\S1{sections} Sections
|
||||
\H{sections} Sections
|
||||
|
||||
Each NSIS installer contains one or more Sections. Each These sections are created, modified, and ended with the following commands.
|
||||
|
||||
|
@ -8,6 +8,8 @@ Each NSIS installer contains one or more Sections. Each These sections are creat
|
|||
|
||||
\b If a section's name is 'Uninstall', then it is a special Uninstall Section.
|
||||
|
||||
\S1{ssectioncommands} Section Commands
|
||||
|
||||
\S2{saddsize} AddSize
|
||||
|
||||
\c size_kb
|
||||
|
|
|
@ -1,9 +1,7 @@
|
|||
\A{tutorial} Tutorial
|
||||
|
||||
\C{tutorial} Tutorial: The Basics
|
||||
|
||||
\H{tutintro} Introduction
|
||||
|
||||
|
||||
If you download or buy software, most of the time it has been packed with an installer. The programer of the installer copies or updates the files, sets the registry keys, writes the configuration etc. The user goes through a kind of wizard, makes the appropriate choices and waits until the installer finishes.
|
||||
|
||||
This way all things have been setup to start the program. The user hasn't to worry about something he maybe forgot because everything necessary was done by the installer.
|
||||
|
@ -14,11 +12,9 @@ NSIS compiles all files and scripts into one executable file, so your applicatio
|
|||
|
||||
\H{tutscriptfiles} Script Files
|
||||
|
||||
To create a NSIS installer you have to write a NSIS script.
|
||||
To create a NSIS installer, you have to write a NSIS script.
|
||||
|
||||
A NSIS Script is nothing more than a simple text file.
|
||||
|
||||
You can edit it with every text editor you like but I suggest you should use an editor more advanced than notepad. The editor of your choice should be able to show line numbers (The NSIS compiler always shows on which line the error has occurred) and syntax highlighting for better coding. Either you find syntax highlighting files for the editor of your choice on their appropriate homepage or on the \W{http://nsis.sf.net/archive/}{NSIS archive}.
|
||||
You can edit scrips with every text editor but editors that show line numbers and support syntax highlighting are recommended. You can download files for syntax highlighting at the \W{http://nsis.sf.net/archive/}{NSIS Archive}.
|
||||
|
||||
In a NSIS script every line is treated as a command. If your command is too long for one line you can use the \\ at the end of the line. This way the compiler treats the new line as an addition to the previous line and don't expects a new command.
|
||||
|
||||
|
@ -27,34 +23,39 @@ In a NSIS script every line is treated as a command. If your command is too long
|
|||
|
||||
If you want to use characters like " in a string, escape them using $\\“
|
||||
|
||||
The default extension for a script is .nsi. But there is also .nsh. An .nsh file is something like a header file in C. You can put functions or macros’s in header files and include the header files in multiple installers. It also makes your scripts better to read.
|
||||
For more details about the script format, see \k{fileformat}.
|
||||
|
||||
The default extension for a script file is .nsi. Header files have the extension .nsh. You can put functions or macros’s in header files and include the header files in multiple installers. This makes updating easier and it also makes your scripts better to read.
|
||||
|
||||
\H{tutstructure} Scripting structure
|
||||
|
||||
A NSIS script contains of 3 parts. These parts are called compiler commands, installer attributes and sections/functions.
|
||||
|
||||
\S1{compilercommands} Compiler Commands
|
||||
|
||||
Compiler commands will be executed on compile time. They allow you to include header files, execute applications etc. If you want to use constants such as the version of your program it is not necessary to use a run-time variable because the version information will not change during installation.
|
||||
|
||||
!define VERSION "1.0.3" is a good example for using the define command. $\{VERSION\} will be replaced by 1.0.3 everywhere in the script.
|
||||
|
||||
You can also use macros on compile time. You can use macro’s to insert code on compile time, depending on defines and using the values of the defines. An example of a macro is UpgradeDLL (See \k{upgradedll}), which you can use to upgrade a DLL file. The macro inserts all the commands on compile time, because you need compile time commands such as GetDLLVersion.
|
||||
A NSIS script should contain Installer Attributes and Sections/Functions. You can use Compiler Commands for compile-time operations.
|
||||
|
||||
\S1{installerattributes} Installer Attributes
|
||||
|
||||
Installer Attributes determines the look and the basic behavior of your installation. With these attributes you define what pages are shown in which order, which UI resource should be used, how many installation types exists etc. All of these commands can only be set and are not changeable during runtime.
|
||||
|
||||
For more info, have a look at \k{instattribs}
|
||||
|
||||
\S1{sectionsfunctions} Sections/Functions
|
||||
|
||||
In a common installer there are several things the user can install. For example the NSIS distribution where you can install the core files, the source files etc. Each of these components is separated in a section.
|
||||
|
||||
Of course you can build your installer with only one section, but if you want to use the component page and let the user choose what to install you have to use more than one section. In sections you can execute any kind of command like extracting files, read or write registry keys, INI values etc. You can also use variables and use commands such as StrCmp to check for conditions, just like a real programming language. The complete list of commands can be found here (See \k{instr}).
|
||||
Of course you can build your installer with only one section, but if you want to use the component page and let the user choose what to install you have to use more than one section. In sections you can execute any kind of command like extracting files, read or write registry keys, INI values etc. For more information about sections: \k{sections}. You can also use variables and use commands such as StrCmp to check for conditions, just like a real programming language. The complete list of commands can be found in \k{instr}).
|
||||
|
||||
In functions you can also use any kind of command. There are two kinds of functions. Callback functions and user functions. A callback function will be called by NSIS when a certain event occurs (See \k{callbacks}). Let's say you want to call a specific command if the installer quits with errors than you have to define the callback function .onInstFailed. Callback can be used optional. There is no need to use all of them but to can use them for custom pages, error handling etc.
|
||||
|
||||
The other kinds of functions are called user functions. In the user function you can also put any kind of command but the difference is that you have to call the user function yourself. User functions are very useful if you have a set of commands that needs to be executed on several positions in the installer. This way you only need to code them once. To execute a user function use the command "Call" (See \k{call}). The function will be called and after executing the last command of the function the installer executes the next command after your call.
|
||||
|
||||
\S1{compilercommands} Compiler Commands
|
||||
|
||||
Compiler commands will be executed on compile time. They can be used for conditional compilation, allow you to include header files, execute applications etc. If you want to use constants such as the version of your program it is not necessary to use a run-time variable because the version information will not change during installation.
|
||||
|
||||
!define VERSION "1.0.3" is a good example for using the define command. $\{VERSION\} will be replaced by 1.0.3 everywhere in the script.
|
||||
|
||||
You can also use macros on compile time. You can use macro’s to insert code on compile time, depending on defines and using the values of the defines. An example of a macro is UpgradeDLL (See \k{upgradedll}), which you can use to upgrade a DLL file. The macro inserts all the commands on compile time, because you need compile time commands such as GetDLLVersion.
|
||||
|
||||
For details: \k{comptime}.
|
||||
|
||||
\H{tutcompiler} Compiler
|
||||
|
||||
|
@ -62,7 +63,7 @@ To create an installer you have to compile your script with the makensis compile
|
|||
|
||||
MakeNSISW is a user interface for the compiler. You can start MakeNSISW and open your script or, if you have installed the shell extensions, you can right-click your .nsi file and select "Compile NSI".
|
||||
|
||||
The compiler will check for errors is your script and give you warnings or an error. If an errors occurs (i.e. 2 parameters required but only 1 given) the compiler aborts and a short error message including the line number is printed out. If you have used a command that sets a label such as "Dirtext" more than once the compiler only gives a warning.
|
||||
The compiler will check for errors is your script and give you warnings or an error. If an errors occurs (i.e. 2 parameters required but only 1 given) the compiler aborts and a short error message including the line number will be displayed. For non-critical error the compiler gives a warning (i.e. two DirText commands in one script).
|
||||
|
||||
The built of the installer is entirely made in memory. That means that every file, icons and other resources are combined in memory and than written to the file. If you are building large installers, the compile process can take a few minutes.
|
||||
|
||||
|
@ -74,10 +75,10 @@ NSIS supports different compression methods: ZLib und Bzip2. ZLib is useful for
|
|||
NSIS can be extended with plug-ins. Plug-ins are DLL files written in C, C++ or another language that will automatically be extracted to a temporary folder. You can call plug-in functions in your script using the dllname::funtionname command. Perhaps you have noticed the list of plug-ins that is shown at the beginning of the compile process. You can find the plug-ins in the \W{../Plugins/}{Plugins directory}.
|
||||
|
||||
|
||||
There are several plug-ins available, but you can also write your own. InstallOptions is a popular plug-in that you can use to add custom pages to your installers. The Startmenu plug-in provides a page that allows the user to choose a Start Menu folder. There are a lot of plug-ins for different purposes. The help files and samples for the plug-ins can be found in the \W{../Contrib/}{contrib directory}. You can find addition plug-ins at the on-line \W{http://nsis.sf.net/archive/}{NSIS Archive}.
|
||||
There are several plug-ins available, but you can also write your own. \W{../Contrib/InstallOptions/Readme.html}{InstallOptions} is a popular plug-in that you can use to add custom pages to your installers, in combination with the NSIS Page commands (See \k{pages}). The \W{../Contrib/StartMenu/Readme.txt}{Startmenu plug-in} provides a page that allows the user to choose a Start Menu folder. There are a lot of plug-ins for different purposes, have a look at the \W{../Contrib/}{Contrib directory} for help files and samples. You can find addition plug-ins at the on-line \W{http://nsis.sf.net/archive/}{NSIS Archive}.
|
||||
|
||||
You can also customize the dialog resources without modifying or recompiling the source code. Use a resource editor to customize one of the \W{../contrib/UIs/}{UI files} and use the ChangeUI command to use the customized resources.
|
||||
You can also customize the dialog resources without modifying or recompiling the source code. Use a resource editor to customize one of the \W{../Contrib/UIs/}{UI files} and use the ChangeUI command (See \k{achangeui}) to use the customized resources.
|
||||
|
||||
A popular user interface for NSIS is the Modern User Interface, with an interface like the wizards of recent Windows versions. The Modern UI is not only a customized resource file, it has a lots of new interface elements. It features a white header to describe the current step, a description area on the component page, a Finish page that allows you to run the application or reboot the system and more. The Modern UI language files make it easy to create a multilingual installer, because they contain translations for every label in the installer.
|
||||
|
||||
The Modern UI has a macro system that inserts the code to handle all the new UI elements, so you only have to insert a few lines of code to use it. For more information, check the \W{../Contrib/modern ui/readme.html}{Modern UI Readme} and the Modern UI \W{../examples/modern ui/}{examples}.
|
||||
The Modern UI has a macro system that inserts the code to handle all the new UI elements, so you only have to insert a few lines of code to use it. For more information, check the \W{../Contrib/Modern UI/Readme.html}{Modern UI Readme} and the \W{../Examples/Modern UI/}{Modern UI Examples}.
|
Loading…
Add table
Add a link
Reference in a new issue