Because the Visual RPG language is integrated with the Visual Studio interface and .NET framework, it has acquired by default, many new and improved language features — such as inheritance, interfaces, and overloading — that make it a powerful object-oriented programming language. As a Visual RPG developer, you can now create multithreaded, scalable applications using explicit multithreading.
The RPG Cycle is now supported for migrated ILE Monarch applications. The program cycle is a series of ordered steps that the main procedure goes through for each record read. The information that you code on RPG IV specifications in your source program need not explicitly specify when records should be read or written. The RPG compiler can supply the logical order for these operations when your source program is compiled. Depending on the specifications you code, your program may or may not use each step in the cycle. Primary and secondary files indicate input is controlled by the program cycle. A full procedural file indicates that input is controlled by program-specified calculation operations (for example, READ and CHAIN).
See RPG Cycle Overview for more information.
Code Analysis settings are now supported for the Project. Code analysis analyzes managed code assemblies and reports information about the assemblies; such as violations of the programming and design rules as set by Visual RPG and the Microsoft Framework design guidelines.
The code analysis tool represents the checks it performs during an analysis as Warning messages. Warnings detect and identify relevant programming and design issues and, when possible, supply information about how to fix the problem.
To enable Code Analysis, you can select Enable Code Analysis on the Project's Property Pages.
Additional options for including or excluding rules and treating rules as warnings or errors can also be accessed from property pages. When the tool is enabled during the build process, it reports warnings in the Error List.
See Code Analysis for more information.
Consuming generic types are now supported. Generic types allow a member's 'type' to only be checked at run-time.
See Generic Types Overview for more information.
Added methods *DetailCalc, *TotalCalc, *StartCycle, and *FetchOverflow to support the RPG Cycle.
Added indicators Level Breaks (*inL1 - *inL9), Matching Fields (*inMR), Overflow Indicators (*inOA, *inOG, *inOV) to support the RPG Cycle.
Added Figurative Constant *ALLU.
XLATE - added *String to list of valid types.
UPDATE Fields keyword was changed to Flds, and the max number of fields was increased from 255 to 32,767.
Dynamic references are used together with CALLD. They are the set of libraries (dll’s) the runtime searches for the class invoked in a CALLD. These libraries must be available at runtime, but not necessarily at compile time. During compilation of CALLD, if the PGM keyword is a constant, the compiler searches the available dynamic references to obtain the signature of the *Entry method of the class, and match it against the parameters of the CALLD. If they're not found, the parameters are assumed to be of the same type as the DclParm argument passed by reference, and with Option(*nopass). Dynamic references can only be added to valid Monarch projects (i.e. Console app and class library). They are added by right-clicking the Project or the Dynamic References folder in the project and selecting Add Dynamic Reference. There are two ways to specify them: either using the assembly name (composed of simple name, culture, version, and public key token) or using a path if the dll exists.
You can now set properties in the Visual RPG Project Designer for projects.
See Managing Projects for more information.
This release supports full-text Search support, which can be accessed through Help - Search. It is the most convenient way to locate information in the Help regarding ASNA Product topics. Search allows you to locate all topics that contain a particular word or phrase, (which is not dependent upon whether an Index term you are looking for has been included in the help or not). You can also customize your search using wildcard expressions, nested expressions, logical operators, and filters (as indicated below).
To make the Search specific to only ASNA Products, you can set the Language filter to Visual RPG, and set the Technology filter to ASNA Products. Once you have set these options, those settings will remain any time you select Search, unless you change them.
Note: Please note that you can always select more than 1 option within the Language and Technology filters.
See Using Help Search for more information.
Dynamic references are used together with CALLD. They are the set of libraries (dll’s) the runtime searches for the class invoked in a CALLD. These libraries must be available at runtime, but not necessarily at compile time. During compilation of CALLD, if the PGM keyword is a constant, the compiler searches the available dynamic references to obtain the signature of the *Entry method of the class, and match it against the parameters of the CALLD. If they're not found, the parameters are assumed to be of the same type as the DclParm argument passed by reference, and with Option(*nopass). Dynamic references can only be added to valid Monarch projects (i.e. Console app and class library). They are added by right-clicking the Project or the Dynamic References folder in the project and selecting Add Dynamic Reference. There are two ways to specify them: either using the assembly name (composed of simple name, culture, version, and public key token) or using a path if the dll exists.
The DataGate Server now supports QTEMP, and has the ability to create duplicate objects for physical files.
Visual RPG now supports Visual Studio's MSBuild. MSBuild allows you to specify options to precompile a Web site from the command line using the MSBuild tool. MSBuild produces the same output as the Publish Web Site command on the Build menu, and allows you to save the Web site to a disk location.
For more details, see MSBuild in Help - Contents.
The property browser has an event mode, which you can enter by clicking on the lightening bolt image. In this mode, you can navigate to an event handler by double-clicking on the event name, disassociate an event handler function from a control event by clearing some text (such as the Botton1_Click event), then reassign the event handler to any function with a compatible signature. To leave the event mode, click on the icon to the left of the lightning bolt.
AVR supports the Monarch migration of RPG ILE procedures and subprocedures from System i. The procedure, (which is the main entry point into a program), is migrated as a BEGPROC *Entry Access (*Public) routine. If the original program has a *Entry PList (RPG 400), or the RPG ILE main procedure contains parameters, they are migrated as DclSrParm's in the BegProc without a type specification, as the fields in the PList refer to global fields in the System i source code. Subprocedure parameters are also migrated as DclSrParm's, but with full type specification.
The DclSrParm command was enhanced with the OPTIONS keyword to support certain options on procedure parameters. OPTIONS is only valid in BegProc parameters, and it may contain *OMIT and/or *NOPASS. Please see DclSrParm for further information.
Refer to the built-in function %PARMS if you want to know how many parameters were received; or to the %Omitted function to know whether a *OMIT parameter contains a value. Note that the %Parms and %Omitted functions are only valid inside a BEGPROC procedure. Also, %Omitted is only valid on parameters that have the *Omit option.
You can invoke, or call a Procedure by either using the CALLB command, or a free-form expression, as shown briefly below. Please see CALLB for more information on both examples.
To trap Monarch numeric exceptions, a BEGSR (*PSSR) subroutine can be nested with a BEGPROC routine. When used inside a nested BEGPROC routine, only 2 parameters are used; Name and ExName. Name is required and identifies the name of the procedure. It can be either a valid AVR identifier or the special value *PSSR. If *PSSR is used, then you must also use the ExName parameter, which declares the field name that contains the exception trapped by the BEGSR (*PSSR) subroutine.
Partial Classes are now supported, making it possible to split the definition of a class over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled.
Using partial classes allows you to indicates that other parts of the class be defined within the namespace. All the parts must use the proper keyword. All of the parts must be available at compile time to form the final type. All the parts must have the same accessibility, such as public, private, and so on.
All of the parts that specify a base class must agree, but parts that omit a base class still inherit the base type. Parts can specify different base interfaces, and the final type implements all of the interfaces listed by all of the partial declarations. Any class or interface members declared in a partial definition are available to all of the other parts. The final type is the combination of all the parts at compile time.
Partial classes are defined by setting the BEGCLASS Partial parameter to *YES. See BEGCLASS for more information.
Data structure declarations needed a support of extracting their field definitions into a class and using that class as the basis of its field definitions. Users can write their classes in any language they wish and when that class/type is used as the basis of the field definitions of a DS, all the public fields and properties of that class/type become the fields of the data structure.
When declaring
a data structure (DCLDS) as a TYPE on another DS, all the DCLDSes now
generate classes. Note that a big change is now DCLDS are Reference Types and not Value types.
Internally they generate either a DSName_DS class for a single occurrance DS or
DSName_MODS for a multi-occurrance data
structure.
There are certain OPCODES that data structures need to be recognized as such and not just a class name and hence a “data structure” implements ASNA.VisualRPG.Runtime.IDS interface. The interface contains the following methods and properties.
1.
Load method - Needed for the DSLoad opcode.
2.
Dump method - Needed for the DSDump opcode.
3.
Clear method - Needed for the Clear opcode.
4.
ObjectToParm method - Needed for passing this DS as a INPUT
parm on the Remote Call.
5.
ParmToObject method - Needed for passing this DS as an
OUTPUT parm on the Remote Call.
6.
Length property - Returns the length of the
DS.
If the data structure is a Multiple occurrance, DS implements ASNA.VisualRPG.Runtime.IMODS that has the following properties and methods.
1.
Occurrance - Gets and sets the current occurrance.
2.
ClearAll - Calls clear for all occurrances of the DS.
3.
DumpAll - Dumps all
occurrances of the DS using ToString().
4. LoadAll - Loads all occurrances of the DS from a source string.
DataGate Printer Files are now supported. Printer files are declared using DclPrintFile with two new keywords added (OverFlowInd and IndDs), which specifies if the print file has reached the Overflow area and defines an Indicator Data Structure, respectively. See PrintFile for a listing of the properties and fields for printer files.
Also see Printing on Windows 2003 -ASP.NET Web Applications for solutions to challenges that are a result of Microsoft enhancing security.
In addition, the .NET Framework Class Library enumerations System.Drawing.Printing.Duplex, System.Drawing.Printing.PaperKind, System.Drawing.Printing.PaperSourceKind, and System.Drawing.Printing.PrinterResolutionKind are now used for the Duplex, PaperSize, PaperSource, and Quality properties respectively.
DataGate PrintDuplex, PaperSize, PaperSource, and PrintQuality enumerations are no longer supported.
SubfileControl have been added in the ASNA.VisualRPG.Windows.Controls namespace. A subfile is declared using DclSubfile and subfile fields are declared using DclSubfileFld. See SubfileControl members for a list of the properties, events, and methods. Additional classes were also added to support the passing of parameters for subfile events. These include: GridArgs, RecordDeleteArgs, and RecordNewArgs.
Delegates
Inheritance
Namespaces
Overriding Properties and
Methods
Shared Members