Page 1 of 1
Purpose of Startup.pps, valid usage scenarios
Posted: Wed Jul 31, 2019 3:47 am
by ALIENQuake
Hi,
It's not clear for me what's is the purpose of Startup.pps?
Which of below scenarios are valid usage scenarios to be executed from this file:
- prevent launching of the app if application directory is blacklisted
- checking if new app version is available
- updating application before main form is displayed
- downloading extra tools
- handling launching the app with commaindline (case of file association)
Re: Purpose of Startup.pps, valid usage scenarios
Posted: Wed Jul 31, 2019 9:51 am
by jvierra
Sapien documentation defines "startup.pss" this way:
An empty project contains a single file called Startup.pss. It is used to create a script application. This script executes when the project is executed and is a great place do any preparatory work before calling other scripts in the project.
This executes as the first code before any other code in a project. What you use it for depends only on the overall design of your project.
Re: Purpose of Startup.pps, valid usage scenarios
Posted: Wed Jul 31, 2019 10:14 am
by jvierra
To expand on the above (since I couldn't find a Sapien blog on this) the following is how the code gets assembled when a project is executed or built.
This is the startup.pss code that is generated:
Code: Select all
#region Source: Startup.pss
#----------------------------------------------
#region Import Assemblies
#----------------------------------------------
#endregion Import Assemblies
#Define a Param block to use custom parameters in the project
#Param ($CustomParameter)
function Main {
<#
.SYNOPSIS
The Main function starts the project application.
.PARAMETER Commandline
$Commandline contains the complete argument string passed to the script packager executable.
.NOTES
Use this function to initialize your script and to call GUI forms.
.NOTES
To get the console output in the Packager (Forms Engine) use:
$ConsoleOutput (Type: System.Collections.ArrayList)
#>
Param ([String]$Commandline)
#--------------------------------------------------------------------------
#TODO: Add initialization script here (Load modules and check requirements)
#--------------------------------------------------------------------------
if ((Show-MainForm_psf) -eq 'OK') {
}
$script:ExitCode = 0 #Set the exit code for the Packager
}
#endregion Source: Startup.pss
Note that it becomes a function called "Main". This is the first executable line of the generated script:
Code: Select all
#Start the application
Main ($CommandLine)
Prior to that the "globals.ps1" file is inserted at the "global" scope so the code in "globals.ps1" is executed before "startup.ps1" and all code defined in the script run or exist at a global scope. Normally "globals.ps1" is used to define global variables and functions. Variables and functions defined in "startup.ps1" will not become global unless they are defined as global.
"startup.pss" also calls the startup script for the project which would be the main form in a forms project. In a script project it calls any initial script or sequence of scripts you choose to define in the file.
Re: Purpose of Startup.pps, valid usage scenarios
Posted: Thu Aug 01, 2019 2:12 am
by ALIENQuake
jvierra wrote: ↑Wed Jul 31, 2019 10:14 am
Prior to that the "globals.ps1" file is inserted at the "global" scope so the code in "globals.ps1" is executed before "startup.ps1" and all code defined in the script run or exist at a global scope.
Are you sure? The default "Build Order" for new From Project is:
Startup.pps - 0
Global.ps1 - 1
MainForm.psf - 2
Very simple debbuging via
Code: Select all
[System.Windows.Forms.MessageBox]::Show("startup - before main - $ScriptDirectory")
shows that $ScriptDirectory is empty.
I had to change default "Build Order" preference in order to get the 'global.ps1 first'.
Re: Purpose of Startup.pps, valid usage scenarios
Posted: Thu Aug 01, 2019 6:08 am
by jvierra
That will not change the final component. "Globals" will always be built at the root. Dumping the PS1 will show that to always be true no matter which one you set to be processed first. All scripts and globals will b e inserted into the script and, lastly, "main" will be called. This behavior cannot be changed.
"$ScriptDirectory" will only be set after main is called.