Since PrimalScript 2009 is a 32 bit application the host used is also of the 32 bit variety, residing in the System32 folder of your Windows directory.

If you are working on a 64 bit operating system and you have to use 64 bit COM objects you need to be able to run your scripts in 64 bit mode.

In order to do that you can simply change what specific version of CScript.exe is used by specifying the full path:

Go to Tools – Options – Environment – Languages and select VBScript. The default entry for the script engine just states “CScript.exe”. If you change that to C:\Windows\Sysnative\cscript.exe you get PrimalScipt to execute the 64 bit version. The “sysnative” substitute for system32 works on Vista, Windows 7 and Server 2008 operating system flavors.

If you don’t want to change the default behavior and just occasionally execute scripts in 64 bit mode, you can just leave the above mentioned setting alone and add the 64 bit engine to your Tools browser:

Right click anywhere in the tools browser and select “Customize…” and add a new tool in a group of your choice and add the settings as shown above. In order to run the current script in 64 bit mode you only have to click on the icon.

All these things work just as well for JScript if that is your language of choice, but don’t try this for PowerShell. PowerShell does not like to get its input and output streams redirected and will just hang if you try to do that. We will talk about 64 bit PowerShell in the next installment.

Technorati Tags: 64bit, JScript, powershell, PrimalScript, Server 2008, Sysnative, VBScript, Vista, windows 7

If you are dealing with mostly 64 bit server software you may want to make the embedded shell use the 64 bit version of PowerShell. The default installation of PowerShell under Windows 7 is at C:\Windows\System32\WindowsPowerShell\v1.0

And yes, that is still true for PowerShell V2.

The system32 folder is mapped to SysWOW64, which is the actual 32 bit version of the that folder. I know, the numbering scheme is a bit confusing.

Fortunately with Vista 64bit, Server 2008 64 bit and Windows 7 64 bit there is a path specification that explicitly points to the 64 bit folder.

Open PrimalScript 2009 and select Tools – Options – Environment – Command Window.

Select “Other Process” and enter the following path:
C:\Windows\Sysnative\WindowsPowerShell\v1.0\PowerShell.exe

Press OK and use View – Other Windows – Command Window to bring up the embedded shell if you don’t have it active yet.

You can now actually right click and toggle between the 32 and the 64 bit shell using either “Windows PowerShell” or PowerShell.exe

Drag and drop you scripts, partial code or snippets onto the embedded shell to run things.

How can you tell the difference? While there is no obvious variable that screams 64 or 32 bit, I found the following a good indicator:

Type ls env:programfiles

If it has a value of “C:\Program Files” you are in a 64 bit shell, if it says “C:\Program Files (x86)” you have a 32 bit PowerShell instance running.

Technorati Tags: 32 bit, 64 bit, console, powershell, PrimalScript, SAPIEN, Server 2008, Vista, windows 7

This new process eliminates the middle step of waiting for an email with a download link and therefore eliminating the problem of lost emails or emails getting trapped in spam filters.

Technorati Tags: Books, tfm

The package’s script host provides a convenient string variable named $CommandLine. This variable contains the complete argument string that is passed to the package. To illustrate how the $CommandLine variable is used, a script package named “mypackage.exe” will be executed  with the following arguments:

mypackage.exe –Parameter1 Value1 –Parameter2 Value2

The resulting string value of $CommandLine is as follows:

$CommandLine: “–Parameter1” “Value1” “–Parameter2” “Value2”

As you can see all the parameter / values are in a single line and each surrounded by quotes.

Accessing the Argument Parameters

The simplest example of command line argument use is when a parameter is passed and there is no associated value. In order to determine if the argument is present, a simple search of the string will suffice.

For example:

In this example we only care that “/?” is present; therefore, we only need to search the $CommandLine string for “/?” parameter.

if($CommandLine.Contains("""/?""")) {     Write-Host "Found Parameter" }

In other instances a value pair may be needed. The first example above illustrates the value pair.

mypackage.exe –Parameter1 Value1 –Parameter2 Value2

In this case, the information will need to be parsed from the command line string which requires a more complex approach then a simple search. To help facilitate this, a function called Parse-Commandline was created which will parse the $CommandLine string values from the quotes and place them into a StringCollection.

Using the following command line will yield these results:

Results:

$Parameter[0] = –Parameter $Parameter[1] = Value1 $Parameter[2] = –Parameter2 $Parameter[3] = Value2

The parameters can be compared by simply checking each element of the collection. It can be taken even further by creating a function called Convert-ArgumentsToDictionary which will convert the value pairs into a Dictionary (Hashtable).  Convert-ArgumentsToDictionary takes two parameters: The first is the parsed StringCollection and the second is a character that denotes a parameter. In the argument string above, the ‘-‘ character denotes a parameter.

function Convert-ArgumentsToDictionary {     Param([System.Collections.Specialized.StringCollection] $Params, [char] $ParamIndicator)     $Dictionary = New-Object System.Collections.Specialized.StringDictionary     for($index = 0; $index -lt $Params.Count; $index++)     {         [string]$param = $Params[$index]         #Clear the values         $key = ""         $value = ""         if($param.StartsWith($ParamIndicator))         {             #Remove the indicator             $key = $param.Remove(0,1)             if($index  + 1 -lt $Params.Count)             {                 #Check if the next Argument is a parameter                 [string]$param = $Params[$index + 1]                 if($param.StartsWith($ParamIndicator) -ne $true )                 {                     #If it isn’t a parameter then set it as the value                     $value = $param                     $index++                 }             }             $Dictionary[$key] = $value         }#else skip     }     return $Dictionary }

Once the parsed arguments are converted to a Dictionary, simply check for the parameter name and it will return the value.

The following script utilizes the functions described above:

#Verify that the $CommandLine variable exists if($CommandLine -ne $null -and $CommandLine -ne "") {     $Arguments = Parse-Commandline $CommandLine     #Convert the Arguments. Use – as the Argument Indicator     $Dictionary= Convert-ArgumentsToHashtable $Arguments ‘-’     #Output the original command line string     "Command Line: {0}`r`n" -f $CommandLine | Write-Output     #Output the Dictionary in a formatted table     $Dictionary | Format-Table @{label="Key";Expression={$_.Key}},@{label="Value";Expression={$_.Value}} | Out-String | Write-Output } else {     #Not running in a packager or no command line arguments passed     Write-Output "There are no command line arguments to parse." }

The script verifies the $CommandLine variable is not null because it only exists in the package’s Script Host. Then the function are used to parse the $CommandLine variable and convert it to a Dictionary. Once the Dictionary is generated, the contents are formatted and displayed.

The results are as follows:

***Run Powershell*** Command Line: "-Parameter1" "Value1" "-Parameter2" "Value2" Key                                     Value                                  —                                     —–                                  Parameter2                              Value2                                 Parameter1                              Value1                                 ***Exiting Powershell***

You should now have a better understanding on how do use command line arguments with your packaged scripts. Feel free to use and customize these functions to make accessing  the command line arguments quick and easy.

Technorati Tags: commandline, Packager, PrimalForms, PrimalScript 2009

The purpose of OnApplicationLoad is to initialize any dependencies necessary for your form script to run, such as PSSnapins. In the case where the necessary dependencies are unavailable, you can return $false and the form will not display.

To understand why you can’t access the form controls within the OnApplicationLoad function, you need to understand when and where the OnApplicationLoad is called.

The following diagram demonstrates the process flow of the generated script:

As you can see the OnApplicationLoad is called before the GenerateForm function is called. If the OnApplicationLoad returns $true, the script will call the GenerateForm function, which contains the form code including your custom event scripts; therefore the controls are only exist in the scope of this function. Once the form is closed, the OnApplicationExit function is called. The OnApplicationExit function can be used to remove any dependencies you may have included. Like the OnApplicationLoad, the form controls are out of scope when the OnApplicationExit is called.

Since the form controls are not accessible by the OnApplicationLoad function where can you dynamically initialize the controls? The answer lies in the Form’s Load event. The Load event will fire the right before the form is displayed, but after the controls are defined, making the event an ideal location for initialization.

To add a Load event handler simply double click on the Form in the Designer or use the Properties Panel’s Events Tab and type in the event hander name next to the Load entry.

Now that you have a Load Event Handler you can use Read-Host or other methods to initialize your controls.

PrimalForms 2009 includes various sample forms and one of particular interest to this subject is SystemInformation.pff. If you refer to the SystemInformation.pff sample, you will notice that in the OnApplicationLoad is used to prompt the user for the path to a text file that contains a list of computer names. The path is stored in a script scope variable: $script:list. If the file is not found, the OnApplicationLoad returns $false and the form is never displayed.

In the form’s Load event ($PopulateList), the script calls uses the $list variable (initialized in OnApplicationLoad) to load a list of computer names into a ComboBox control. Since the $list variable was declared in the script scope, the Load event is able to access it.

To recap, the OnApplicationLoad function is used to pre-initialize your script, but it can not access the form controls. Instead it is recommended to use the Load event of the form to directly initialize the controls.

Technorati Tags: function, Howto, powershell, PrimalForm, Winforms

With PowerShell Cmdlets it is not quite that easy. Say you have to use a snapin that is only available on 64 bit but your development machine (and PrimalScript) are 32 bit. Maybe your snapin only installs on a server OS but not on your new Windows 7 laptop? Since snapins are assemblies and not just data files they may not be able to be loaded outside of their intended environment. So neither PrimalScript nor your local PowerShell may have any way of extracting type information.

But as you may have guessed, we created a way to get PrimalSense for snapins that you don’t even have installed.

We will use Quest’s AD snapin to illustrate the process:

1. On the computer where the snapin is installed and registered, run add-pssnapin to load it:
add-pssnapin Quest.ActiveRoles.admanagement

2. Export the CmdLets in that file into a text file.
get-command -syntax -pssnapin Quest.ActiveRoles.admanagement >PSH.external

3. Copy that text file to your computer and load it into PrimalScript and remove all empty lines.

4. Right click in the file, select Properties… and change the encoding from Unicode to ANSI.

5. Copy the file to the languages folder where PrimalScript is installed (e.g. C:\Program Files\SAPIEN Technologies, Inc\PrimalScript 2009\languages) or merge it with a file of that name that may already exist.

Restart PrimalScript and the Cmdlets should be color coded and you should get PrimalSense as well.

You will need PrimalScript 2009 build 621 (5.0.621) at the very least.

We know that this is a very manual process and can be automated more, but we know it is necessary to put it out as soon as possible. We will work to streamline this and make it easier as soon as we can.

We will have a snapin/module exporter and an import function in PrimalScript right after Christmas.

Technorati Tags: cmdlet, powershell, PrimalScript, PrimalSense, snapin

It is fairly simple to connect PrimalSQL to your MySQL 5.1 database. Follow the outlined steps below and you will be connected in no time!

1) Presumably you have a MySQL 5.1 database installed either locally or on a server somewhere. If you want to test this on a new installation, you can download MwSQL 5.1 from http://www.mysql.com. Select the OS that you will be installing under and download the MSI. Its a fairly straight forward install which walks you through creation of an account, etc. Be sure to download the ODBC connector and install that as well. Optionally, you may want to download and install the MySQL Gui tools, but, hey, what we really want to do is use PrimalSQL, right?

2) Once you have MySQL installed, create an ODBC connection using the Data Sources Control Panel applet. Once you have ODBC Data Source Administrator window open, create a User DSN or system DSN by adding a new data source. Select “MySQL ODBC 5.1 Driver as the driver and press Finish.

This will pop up the MySQL Connector/ODBC Data Source Configuration window. Fill in a name for your DSN, description, server location (in this case localhost). The port defaults to 3306. You also need to fill in your MySQL credentials. Optionally, you can select the default database as well from the dropdown. Test the connection. If all is well, press OK to create the data source.

3) Open PrimalSQL. Click the Connection button on the ribbon and select New.

4) In the Provider Pane of the Data Link Properties window, select Microsoft OLE DB Provider for ODBC Drivers and press Next.

5) On the Connection pane, select the MySQL DSN that you created in step 2 under Use Data Source Name. Enter your credentials and select an initial catalog. Test the connection. If all goes well, press OK.

6) A new Connection will show up in the PrimalSQL Database Browser panel. Rename it to something that makes sense to you.

7) Double click the connection to connect it. Right click on the connection and select Set As Active Connection.

You should be able to see your Stored procedures, views and tables listed under the connection. PrimalSQL will allow you to query your tables using the Visual Query Builder or by writing SQL code. At this time, PrimalSQL does not support the editing of Stored Procedures in MySQL.

PrimalSQL is available as a free 45 day trial at http://www.primaltools.com. Check it out and let us know what you think.

Technorati Tags: PrimalSQL, sql

$handler_button3_Click={
# Check that a logfile was specified. If not close the form.
if ( $textbox2.text -eq "" )
{
Write-host "No Logfile, closing"
$form1.close()
} # A logfile was specified
Write-Host "I have the logfile"
}

As you can see, the user is testing to make sure that the the name of the log file was entered into the textbox. If the value is empty, the script will close the form. This is where the behavior deviates from what the user expects. When the user presses the button with the textbox empty, the script generates the following output:

PowerShell continues to execute the last line despite the fact that the script closed the form in the following line. The user’s perception was that the script block will stop executing after the form was closed, but that is not the case. The reason is that PowerShell is not dependent on the form to execute the script, thus it continues to process the rest of script. To PowerShell the $form1.Close() line is just another command to execute. Since PowerShell does not stop the script when the form is closed, the script block needs to be modified in order prevent the execution of the rest of the script. Below I present two alternatives to prevent this from happening:

Add  “return” command after closing the form:

$handler_button3_Click={
# Check that a logfile was specified. If not close the form.
if ( $textbox2.text -eq "" )
{
Write-host "No Logfile, closing"
$form1.close()
return #exit the script block
} # A logfile was specified
Write-Host "I have the logfile"
}

An alternative would be to add in an “else” statement:

$handler_button3_Click={
# Check that a logfile was specified. If not close the form.
if ( $textbox2.text -eq "" )
{
Write-host "No Logfile, closing"
$form1.close()
} # A logfile was specified
else #add else statement
{
Write-Host "I have the logfile"
}
}

The corrected script block generates the expected output:

As demonstrated, forms in PowerShell may not behave as expected. Users must keep in mind that PowerShell will continue to execute the remaining lines in a script even after closing the form in a previous line; therefore, users must accommodate accordingly.

Technorati Tags: forms, powershell, PrimalForms, Winforms

Help Documentation:

(Fig 1: Click on the Help button or press F1 key to access the help documentation.)

PrimalForms allows users to access help on any panel or window simply by pressing the F1 key. Depending on the active window, help will take the user to the corresponding Help topic. For example, if a user would like more information on the Assemblies Panel, the user simply have to click on the Assemblies Panel and press the F1 key. The Help document will then open and display the “Assemblies Panel” topic. This help applies to all windows in the application.

In addition to application help topics, the Help Documentation features a “Getting Started” Section which is designed to instruct new users on how to create their very first form. The guide also covers some basic controls and how to incorporate them in your forms.

Help and the Script Editor:

The F1 key plays an additional role in the Script Editor. The F1 key can provide the user with information on cmdlets and variable types, depending on the position of the caret in the editor. For example, if the user clicks on a cmdlet name in the script and presses the F1 key, the help documentation for the cmdlet will be displayed in the Help Panel and highlighted in the PowerShell Panel. Cmdlet help information is also automatically displayed when the user types the space character after the cmdlet name.

(Fig 2: Cmdlet Help)

TIP: Just like the script editor, the Help Panel features a split view display to allow users to view two separate sections of the cmdlet help at the same time.

(Fig 3: Help Panel Split View)

Additional help information is displayed when a user hovers the cursor over a cmdlet or variable.

(Fig 3: Cmdlet parameters are displayed)

(Fig 4: Variable types are displayed)

.NET Object Browser:

Not only does the F1 display the cmdlet help, but users can use the F1 key to find the type information for variables, properties, and methods in the .Net Object Browser.

TIP: Pressing the F1 key on variables selected in the script editor, automatically selects the corresponding type in the .NET Object Browser, thus saving the users from having to manually search the browser. For example, pressing the F1 key on the $form variable, results in the selection of System.Windows.Forms.Form object in the .NET Object Browser.

The .NET Object Browse is used to display all the objects contained in the .NET assemblies. The objects are grouped by assembly and namespace. It allows users to view all the properties and methods of particular objects / controls, including their static members.

Accessing Static Members:

Static members are properties or methods that are shared by an object type and are not instantiated with the object. In other words, it does not depends on an object (variable) to be created, in order to access these members. In PowerShell, accessing a static member is differentiated from accessing a variable member.

Accessing a typical variable property:

Accessing a static property:

As you can see, users must specify the class name in brackets and use the “::” operator to access a static member. Users familiar with C#, will notice that PowerShell deviates from what they would expect to see in C#.

TIP: Static methods and properties are differentiated by their blue tone in the .NET Object Browser

TIP: Double click on a static member in the .NET Object Browser will save you having to type out the static member call

(Fig 5: Click on static prop -> inserted text)

TIP: Double clicking on cmdlet names in the PowerShell panel will insert the command

MSDN Help:

TIP: If a user is unsure about a property or method, they can right click on the questionable object in the .NET Object Browser and select the “MSDN Help” menu option. This option will take the user to the Online MSDN Help Documentation, which provides type descriptions and samples.

(Fig 6: MSDN Help context menu option)

TIP: Users can also access the MSDN Help directly from the Toolbox Panel while working in the Designer tab.

(Fig 7: MSDN Help context menu in Toolbox Panel)

PrimalSense:

Majority of the help is integrated directly into PrimalForms’ PrimalSense. For example, PrimalSense will list properties and methods of objects after users type the ‘.’ operator. Further more the PrimalSense will list all available variables, including all the form objects when typing the ‘$’ character.

TIP: Use the Assembly Panel to expand PrimalSense’s type support. Added assemblies will automatically be added to the .NET Object Browser.

In addition, PrimalSense helps facilitate scripting by listing available cmdlets that match the verb the user is typing.

(Fig 8: PrimalSense for cmdlet commands)

PrimalSense also assists users by displaying the parameters of a cmdlet. Furthermore, snapins added in the script are automatically integrated into PrimalForms’ PrimalSense and the PowerShell Panel.

(Fig 9: PrimalSense for cmdlet parameters)

Hopefully with this blog, users have a better understanding of how to use PrimalForms 2009’s  integrated help to assist in their scripting.

Technorati Tags: forms, Help, powershell, PrimalForms, Winforms

PrimalMerge has the ability to compare complete folders of files and then allows you to synchronize those folders with each other. Let’s take a look at how this is done.

Start off by first opening the two folders that you want to compare. Do this by selecting the Application button and choosing “Open Directory…” from the menu. This option brings up the “Select directories to compare” dialog box. Within this box you can either type in the directory paths that you want to compare or click on the “…” button next to each path to select by browsing folders. Press the “OK” button when your choices have been made.

PrimalMerge will open a window with 5 columns, showing the list of files from the folders selected. The first column displays the file name with an icon. A red icon indicates that the same file name exists in both folders, but that the file contents are different. This is also indicated in the “Comparison Result” column.

A blue icon indicates that the same file exists in both folders and that they are identical. A half icon indicates that the file exists only in one of the two folders. These states are also displayed in the “Comparison Result” column.  You can use the “Left Date” (first folder) and “Right Date” (second folder) columns to compare which file is newer.

Here is where the magic takes place. Looking carefully at the sample above, you can see that some of the files in the “Right Date” column are newer and marked by an asterisk. Select all of the files in the list. Right click and select “Copy…Right to Left”. Viola! The newer files from the second folder replace the files in the first folder.

This is just a small example of some of the versatility in PrimalMerge. Download a 45 day free trial at http://www.primaltools.com/products/info.asp?p=PrimalMerge.

Technorati Tags: PrimalMerge 2009, scripting