The Startup.pps inconveniences and workaround

This forum can be browsed by the general public. Posting is limited to current SAPIEN license holders with active maintenance and does not offer a response time guarantee.
Forum rules
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.

Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
User avatar
ALIENQuake
Posts: 80
Joined: Sun Mar 03, 2013 12:45 pm
Has voted: 3 times

The Startup.pps inconveniences and workaround

Post by ALIENQuake »

Hi,

The process of developing my code tends to get more and more inconvenient due to how Startup.pps and Main function are handled.
The code of my app is launching differently depending on $Commandline having any value or not. The code inside the Startup.pps main function:

Code: Select all

if ($Commandline) {
        if ((Show-Form1_psf) -eq 'OK') {
            if ((Show-Form2_psf) -eq 'OK') { }
        }
    }
    else {
        if ((Show-Form2_psf) -eq 'OK') { }
}
The problem that I constantly face:

Form1 and Form2 use the same functions taken from Global.ps1. I need to copy those functions from Global.ps1 into Startup.pps because otherwise, they aren't available. So every time when I modify the function inside Global.ps1 there is a chance that I forget to update it inside Startup.pps. It already causes some hard to discover bugs.

So I decided to create and use a workaround:
Startup.pss:

Code: Select all

#Define a Param block to use custom parameters in the project
#Param ($CustomParameter)

function Main {
    Start-Main -Commandline $Commandline
}

Globals.ps1:

Code: Select all

function Start-Main {
	<#
    .SYNOPSIS
        The Start-Main function is called via Main function from Startup.pss.
    
    .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-AppUpdateReleaseAsset_psf) -eq 'OK') { }
    
    #Set the exit code for the Packager
    $script:ExitCode = 0
}
Questions:

1. Does this workaround is valid? Does the scope of '$script:ExitCode' is correct after moving to Globals.ps1? I see no reason why it wouldn't work but If you see anything which requires correction then please advise.

2. Why the Startup.pps exist at all? Can't you just move 'Main' function into Global.ps1 and handle $Commandline there?

User avatar
brittneyr
Site Admin
Posts: 637
Joined: Thu Jun 01, 2017 7:20 am
Answers: 8
Been upvoted: 6 times

Re: The Startup.pps inconveniences and workaround

Post by brittneyr »

Startup.pss exist as it serves as the main entry point when starting the final built script. When all of your scripts are being combined into one, Startup.pss is the first one added. It sounds like this is what is causing you issues as the functions you have declared in Globals.ps1 will not be added to final script until after Startup.pss meaning Startup.pss will not know these functions exist as they were not declared beforehand. I would recommend switching Globals.ps1 Build Order before Startup.pss and see if the fixes your issue.

It should be fine to use your process, however this was not the intended use of Globals.ps1 and this may break in the future if changes are made to projects.
Brittney Ryn
SAPIEN Technologies, Inc.

User avatar
ALIENQuake
Posts: 80
Joined: Sun Mar 03, 2013 12:45 pm
Has voted: 3 times

Re: The Startup.pps inconveniences and workaround

Post by ALIENQuake »

Strange. For newly created project files, I don't have this issue. But for my current app project files, I do. Could it be the fact that the project live since 2017 and was upgraded to the 2018, 2019, and 2020 version of SAPIEN PowerShell?

User avatar
brittneyr
Site Admin
Posts: 637
Joined: Thu Jun 01, 2017 7:20 am
Answers: 8
Been upvoted: 6 times

Re: The Startup.pps inconveniences and workaround

Post by brittneyr »

That is very unlikely as your project settings would not change from updating to the latest version of PowerShell Studio. The cause is most likely a mixture of build settings and how the code is structured. Again, I would recommend updating the build settings as I suggested above.
Brittney Ryn
SAPIEN Technologies, Inc.