Release Notes for AVR 4.1 (12.97)
Released on June 16, 2008
Important. Please Read:
You should only use AVR 4.1 if you are planning to upgrade existing AVR classic code to AVR.NET code via the Upgrade Assistant. If you are not planning on upgrading to AVR.NET, then you may continue to use AVR 4.0 classic.
AVR Classic 4.1 employs a different license key model than AVR 4.0. The Upgrade Assistant will not complete without a valid, permanent 4.1 license. If you do not have a license for AVR 4.1, please call your ASNA representative. Upgrade Assistant is installed with AVR for .NET on the same development machine as AVR 4.1. You must install AVR 8.2 or later to employ the Upgrade Assistant.
Note: Upgrade Assistant is not packaged with AVR Classic. It is packaged and installed with AVR .NET. Be certain to stay current with the latest releases of AVR .NET to employ the Upgrade Assistant's most recent fixes and features.
Call/Parm support to the iSeries and AVR 4.1 application is incompatiblewith DataGate/400 release 5.1200.1.51 and older. Please install 5.1200.1.64 (or later) on your iSeries for DataGate 5.0. Please note that DataGate versions 7.133.2.16 and 7.2.228 and later are compatible.
DataGate for SQL Server 5.0 users: AVR 4.1 installs the .NET DataGate client which is not compatible with a DSS 5.0 Server. You will need to install DSS for .NET 8.2 (or later) on your SQL Server machine. Additionally, the DSS 5.0 client is not compatible with .NET DSS for SQL Server. You will need to install the AVR 4.1 deployment package on all machines that will access the DSS for .NET Server.
Features and fixes incorporated into this build (Version 12.97)
(12.97) - No AVR 4.1 fixes.
Features and fixes incorporated into this build (Version 12.96)
(12.96) - No AVR 4.1 fixes. Case 5942 related to Acceler8DB client was fixed. Prevent drop of last message in multi-message RPC response. DataGate client drops last message of multi-message RPC response. Issue resolved by changing client to read the RPC message header and use the header's message length to read the correct number of message data bytes.
Features and fixes incorporated into this build (Version 12.95)
(12.95) Case 5852: Upgrade assistant not working as designed. When migrating a project to .NET, it fails to migrate the project.
Features and fixes incorporated into this build (Version 12.94)
(12.94) Case 5650: Revisited earlier solution, implementing our own OnInitMenuPopup and protecting MFC temps there.
(12.93) Case 5650: MFC bug workaround, protect MFC temps when processing WM_INITMENUPOPUP message.
(12.92) Case 5098: Fixed bug with DBi ctList control, which was not sorting correctly.
Features and fixes incorporated into this build (Version 12.91)
(12.91) Case 4548: Really fixed bug where a form was being shown in the taskbar even when ShowInTaskBar is set to false.
Features and fixes incorporated into this build (Version 12.90)
(12.90) Case 4548: Fixed bug where forms with ShowInTaskBar = false was showing up in the task bar anyway.
(12.89) Protect dllstub code from being accessed by different threads in multi-processor platforms.
Introducing AVR Classic to AVR .NET Upgrade Assistant
Until now, the only tool available for converting AVR Classic applications was Copy and Paste (Ctrl+C and Ctrl+V). There was no conversion available for forms design, and the programmer was laden with the reconciliation of the many differences between Component Object Model (COM) and .NET Framework.
The new AVR .NET Upgrade Assistant eases the path to .NET from AVR Classic by consistently handling many of the implementations in COM that are foreign to .NET. The keyword here is “many”. Although Upgrade Assistant cannot resolve all issues, it mitigates the mundane tasks so that you can focus on the final details.
Getting Started
Upgrade Assistant requires that all project files be saved as text. So the preparation steps for upgrading to .NET is to open each project (in reverse order of dependency), convert binary files to text, compile and test. In other words, compile and make the DLLs first, then compile and make the EXEs next.
When you are satisfied your application is ready for conversion (i.e. it runs as expected), you should begin in the same order (least dependent to most dependent):
-
Open the AVR 4.1 project in the 4.1 IDE.
- Compile and run the project. If it does not compile AND run in AVR 4.1, then it cannot be upgraded to .NET
- Be certain all project files are saved as Text
- From the IDE menu, select Project > Upgrade to .NET
- Follow the Wizard steps.
Once your projects have been converted to AVR .NET, you can begin reconciling differences between the COM and .NET models.
Converting Controls
In general, Forms (vrf), Programs (vrp) and User classes (vrc) are converted. However, User Controls (vrx) are not, but they can be consumed via Interop like any other ActiveX control.
AVR Classic Windows controls are converted to .NET Windows Controls or to new AVR .NET controls. Here is a conversion summary for AVR Classic’s built-in controls:
| COM control |
Resulting .NET data type |
| Image |
System.Windows.Forms.PictureBox |
| Label |
System.Windows.Forms.Label |
| Menu |
System.Windows.Forms.MainMenu |
| IOField (NumericLength = 0) |
ASNA.VisualRPG.Windows.Controls.IOStringField |
| IOField (NumericLength > 0) |
ASNA.VisualRPG.Windows.Controls.IODecimalField |
| Frame |
System.Windows.Forms.GroupBox |
| CommandButton |
System.Windows.Forms.Button |
| OptionButton |
System.Windows.Forms.RadioButton |
| CheckBox |
System.Windows.Forms.CheckBox |
| ComboBox |
System.Windows.Forms.ComboBox |
| ListBox |
System.Windows.Forms.ListBox |
| VScrollBar |
System.Windows.Forms.VScrollBar |
| HScrollBar |
System.Windows.Forms.HScrollbar |
| UpDown |
System.Windows.Forms.NumericUpDown |
| Progressbar |
System.Windows.Forms.ProgressBar |
| SubFile |
ASNA.VisualRPG.Windows.Controls.SubfileControl |
| StatusBar |
System.Windows.Forms.StatusBar |
| Timer |
System.Windows.Forms.Timer |
| Graph |
AxGraphsLib.AxGraph (Interop) |
| Archive |
AxAdbctls.AxArchive (Interop) |
| DBDef |
AxAdbctls.AxDBDef (Interop) |
| Libl |
AxAdbctls.AxLibl (Interop) |
| Shape |
Not converted |
| Line |
Not converted(1) |
| AVI |
Not converted(1) |
| OSFile |
Not converted |
| CommonDialog |
Not converted |
Of the 3rd party ActiveX container controls that are used in an AVR Classic application, the TabPro 3.0 tab control is converted by the Upgrade Assistant to the .NET Windows tab control (System.Windows.Forms.TabControl).
Nearly all non-container 3rd party ActiveX controls may still be employed in the converted .NET project through Interop. The .NET Framework does not support ActiveX container controls (e.g., Tab Controls, Group Boxes, StatusBars).
There is no conversion available for the Graphics Server Graph control for COM (6.0) to the .NET Graphics Server Windows Chart control. However, the COM version is implemented in the converted AVR application through Interop.
Converting Control Arrays
Although control arrays are not supported by the .NET Framework, the Upgrade Assistant implements a mechanism where objects of the original COM control array are assembled into a Hashtable where each object can be indexed.
The Upgrade Assistant’s control array implementation is clever and it works. On the other hand, it illustrates why it is a definite requirement that the developer have a thorough working knowledge of the .NET Framework in general and AVR for .NET, specifically.
Subfile Control
Most AVR .NET developers have found the Windows Forms DataGrid control to be limited in its utility compared to the AVR Classic Subfile. Indeed the DataGrid control has been subsumed by the new DataGridView control in .NET Framework 2.0.
ASNA has developed its own .NET Subfile control for AVR versions 7.2 and 8.0. AVR Classic Subfiles are converted to the new .NET Subfile with most functionality intact. Remember that the Subfile Control can only be used in AVR 7.2 and above and is not usable in other languages. This is because the AVR compiler co-operates with the Subfile to support READC, WRITE, UPDATE, DELETE and CHAIN I/O commands.
(Global) Startup Program and CALL/Parm
If you have been working with .NET, you know there are no programs, global or otherwise, and that Call/Parm does not fit the .NET object model between AVR members (Call/Parm is still available to call iSeries programs or SQL Server stored procedures).
Upgrade Assistant has done a very good job of creating the Classic environment in .NET. The global program will most likely be the first major change you will make to your converted project. At the top of the list will be the file declarations that have been shared throughout the project. Moving the declarations to the classes that use them is much more workable with .NET in the long run.
On the other hand, with the startup program, Upgrade Assistant introduces you to shared database connections. The startup program now also becomes the class for constants and shared members, a la .NET.
Summary
Once you have begun developing applications in AVR .NET, you will find the COM model for AVR Classic and VB 6.0 to be really old hat. Upgrade Assistant helps you to move your COM applications to .NET in short order and it beats copy/paste by a mile.
Build notes: AVR 4.1 (12.91) DG Engine (7.326.0) ADB 7.2 (7.302)