Main function moved from Startup.pss to Globals.ps1

Ask questions about creating Graphical User Interfaces (GUI) in PowerShell and using WinForms controls.
Forum rules
Do not post any licensing information in this forum.

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

Main function moved from Startup.pss to Globals.ps1

Post by ALIENQuake »

Hi,

I didn't like the usage of Startup.pss so this is my attempt to move it to Globals.ps1
Can somebody check this and tell me if there won't be any problems with such an approach?
Does scope of

Code: Select all

$script:ExitCode = 0
is correct?

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
}
Startup.pss:

Code: Select all

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

function Main {
    Start-Main -Commandline $Commandline
}
MainMovedToGlobals.zip
(33.32 KiB) Downloaded 5 times

jvierra
Posts: 14676
Joined: Tue May 22, 2007 9:57 am
Answers: 6
Has voted: 1 time
Been upvoted: 5 times
Contact:

Re: Main function moved from Startup.pss to Globals.ps1

Post by jvierra »

Why? The code won't assemble the same way. In coding and technology it is usually not a good idea to just change things for no reason or because they look prettier.

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

Re: Main function moved from Startup.pss to Globals.ps1

Post by ALIENQuake »

The motivation for such change is to improve how my code is handling things, not how it looks.

The code of my app is launching differently depending on $Commandline having any value or not.
The switch is inside the 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') { }
    }
Form1 requires certain functions from Global.ps1. So I need to copy those functions from Global.ps1 into startup.pps because otherwise, they aren't available.

That's why I'm asking about possible changes. How the code will assemble?

jvierra
Posts: 14676
Joined: Tue May 22, 2007 9:57 am
Answers: 6
Has voted: 1 time
Been upvoted: 5 times
Contact:

Re: Main function moved from Startup.pss to Globals.ps1

Post by jvierra »

Where the code is in the project has little to do with things. The code handles things correctly for both a PowerShell script and builds correctly for all packaging methods. Making your changes will not change that. The code you are wanting to use will work correctly the way the files are currently structured. There is no need to make changes

Consider the long term effect. If Sapien needs to make changes to the packager or the script assembly routine it may break your code. The "startup.pss" file is set up to be sure the code is loaded by PowerShell correctly in the right order. Usually we would not violate this intended process to avoid future conflict.

I won't say you can't do this. I am only suggesting that best practices in coding would indicate that it would not be a best practice for Sapien or any other vendor tool. My intent was only to advise you of that.

If you need a more targeted answer then post in customer support to get the official Sapien answer.

I recommend that, in the future, posting tool-specific questions to the Customer Support forum for the tool would be the best approach. This forum is more suited to PowerShell specific questions associated with forms design and coding.

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

Re: Main function moved from Startup.pss to Globals.ps1

Post by ALIENQuake »

You are correct, one of the reasons why I posted here is to share the template so others might find it useful. I will open a more specific topic at the support section.

jvierra
Posts: 14676
Joined: Tue May 22, 2007 9:57 am
Answers: 6
Has voted: 1 time
Been upvoted: 5 times
Contact:

Re: Main function moved from Startup.pss to Globals.ps1

Post by jvierra »

What template? There is no template here it is just files with code structured so the Sapien code assembler can load the files in the correct order. You can alter that as needed but I am just saying that there is no reason to do that. The code assembler does that for you. Startup.pss is inserted first into the code stream and that is why "main" is there. In Globals it is loaded after the startup. That makes your method run against the design. If anything changes in how the code is built then it may break what you have done.

I often alter startup.pss but I do it knowing that is is first and global so things will work correctly for the bootstrap function. This iws a very old code assembly method and follows how Visual Studio and other tools do this. That means there is a global assumption that this will happen in a certain way. Breaking that may create issues. Always in code design care must be taken to not get fancy when fancy adds n0othing to teh design or function that is explicitly needed and when it is then we have to ask if we are actually selecting the correct solution or creating a consistent and correct design.

There may also be other issues across all packaging and build methods that i am not aware of which is why I suggest posting tool related issues in customer support. The Sapien engineers can give the most current and accurate answers as they know the internals of the tool and this forum does not. This forum is a user support forum and most current users are not programmers or engineers but are operators or admins that are using PowerShell with Sapien products or without Sapien products. We try to focus on PowerShell specific issues and not on tool usage issues.

Anyway - good luck with whatever you decide. I can only suggest. After the number of years I have in systems and software development I am usually pretty close to the right answer but, like all of us, I don't know everything. Always start with the tool vendor for any tool when asking tool related questions. This will always shorten your path to a resolution.

Post Reply