Developing .Net User Controls for Syspro - Intro

Syspro gives you the ability to house a .Net User Control inside the Syspro application, in a custom pane. (A custom pane can be housed in nearly any Window in the Syspro application, or in the Syspro main menu.) The custom-written control can then interact with your Syspro user interface, the Syspro database, and the Syspro Business Objects - so it's a very nice way to write custom solutions.

However, there are a few traps for the uninitiated:

1. You need to start with a WinForm user control because Syspro can’t run WPF user controls directly; not hard to resolve; you just add a WPF user control inside your WinForm user control.
   
2. You need to add Assembly Resolver code so that your DLL’s are loaded from ManagedAssemblies rather than BASE. See this post on the Syspro Forum for details.
   
3. You need to override the loading of configuration files as the .Net default of BASE\IMPACT.exe.config is obviously inappropriate.
   This code is good: http://stackoverflow.com/questions/6150644/change-default-app-config-at-runtime
   
4. There are some traps with calling Business Objects from .Net via Syspro's VBScript interface.
   In short, you need to:
   
   A. Avoid going over the 70-character limit, so passing XML files via temporary files is one solution.
   
   B. Avoid using spaces, new lines, or other characters, that are of significance to VBScript, in the strings you pass from .Net to Syspro's VBScript. The way to solve this is to encode all those characters as control characters before passing them to VBScript, then decode them inside the VBScript.
   
   C. You may need to pass more than two parameters to Syspro from .Net, but you only have two variables you can use. One way to solve this is to combine several parameters into one string, separating them with control characters.

Recommended Naming Convention for custom tables and fields

If you add custom tables or fields directly to the Syspro database, it is highly recommended that you use a naming scheme like these examples:

• CUSTOM_YourTableName
• USR_YourTableName
• CUSTOM_YourFieldName

The guidelines for the naming convention are:

1. The first word is in ALL-CAPS and should be the same word used for all customisations; CUSTOM or USR are the recommended words to use. CUSTOM is recommended over CUS because CUS is abbreviated and ambiguous with "Customer".
   
2. The actual meaningful table or fieldname should be in CamelCase without underscores.
3. The two words, CUSTOM and YourTableName, should be separated by an underscore.

The reason why the first word, CUSTOM, should be in ALL-CAPS is so that:

1. It makes all custom-added tables (and/or fields) stand out visibly from the standard Syspro ones.
2. It groups all the custom-added tables and fields together.

Guidelines for adding custom tables and fields to Syspro

It is very easy to add custom information to Syspro.

There are a few ways you can go about it.

1. Use a User-Definable field

There are some spare fields in Syspro; they usually go by the name of "user-definable field", but there are not many of them. Here are some of them:

• SorMaster.User1
• SorDetail.MUserDef

The advantage of using these fields is that they can usually be passed or retrieved as standard parameters in the relevant Syspro Business Objects.

2. Use standard fields

There are several fields to which you can add a LOT of information in Syspro:

• Notes - Many tables have free-form notes in which you can write a large amount of text.
• Files - You can attach files to may Syspro tables - multimedia files, pictures, diagrams, etc.

3. Create a Custom Field

You can add custom fields, via the Syspro GUI, to just about any Syspro table and screen. The advantage of doing things this ways is that these custom fields are editable by the Syspro user, without any extra code needing to be written.

In Syspro 6.1 and earlier, these custom fields are stored in the AdmFormData table.

In Syspro 7, these custom fields are added to the actual table (e.g. InvMaster).

These fields can be written and retrieved using these business objects:

• COMSFM - create/update custom fields
• COMQFM - query custom fields

Using the AdmFormData does come with a bit of friction – having to write the extra calls to save or retrieve the custom fields using the Business Object or messy joins in SQL, plus having to obtain the correct key fields.

However, this would normally be the recommended way of extending the data stored in Syspro.

4. Update the database schema

You CAN update Syspro's database schema, provided you adhere to the following rules: 

1. You can ADD tables and indexes to Syspro. This is the safest way to go.
2. You can ADD fields to existing tables, but adding separate tables is recommended over this option as it keeps everything entirely separate.
3. You must not delete any standard schema objects: tables, fields, indexes, relations, etc.

If you update the database schema, it is highly recommended that you follow the Recommended Naming Convention for custom tables and fields.