Up to Discussions in VAGen Migration to EGL Hub

This Question is Possibly Answered

1 "correct" answer available (4 pts) 2 "helpful" answers available (2 pts)
1 Replies Last post: Jun 18, 2009 7:10 AM by Jeri  
Click to view APAWLIK's profile  
APAWLIK
39 posts since
Dec 1, 2008

Jun 16, 2009 7:50 AM

VAG PrintForm - Migration problem


Hi,

The following code comes from VAG:

package abc;

*
FormGroup ABCM {

*

PrintFloatingAreas = [

@PrintFloatingArea { deviceType=DeviceTypeKind.singleByte, pageSize=255,132, topMargin=0,

bottomMargin=0, leftMargin=0, rightMargin=0

}

]

}

*
Form ABCMCLO type printForm

*

{ formSize = 1,132, addSpaceForSOSI = *yes*}

// Start of Variable fields

// Start of Constant fields

*
end

*


　

*
Form ABCMD1 type printForm

*

{ formSize = 19,133, addSpaceForSOSI = *yes*}

...

Within VAG everything works fine. After migration Rational Business Developer brings up an error that formsize has an invalid value.

Any ideas?

Click to view Jeri's profile  
Jeri
154 posts since
May 1, 2008
1. Jun 18, 2009 7:10 AM Up Image in response to: APAWLIK
Re: VAG PrintForm - Migration problem

Without seeing your VAGen source code, I am just guessing..... Best guess is that

  • your VAGen map group specified a print device of 3667, PRINT-B, or PRINTER, which are single-byte printers. All 3 devices translate to an EGL device size of 255x132. This also explains the EGL property deviceType=DeviceTypeKind.singleByte.
  • your VAGen map ABCMD1 specified a print device of 5550P, which is a double-byte printer. This device translates to an EGL device size of 255x153 -- so the number of columns (133) fits for that size of device. The use of device 5550P is further indicated by the EGL property addSpaceForSOSI = yes.
  • your VAGen map group and map ABCMCLO specified a print device of 3667, PRINT-B, or PRINTER, which are single-byte printers. Again all 3 devices translate to an EGL device size of 255x132. What is odd is the inclusion of EGL property addSpaceForSOSI = yes for this form. This comes from the VAGen "SO/SI Take position" property -- which I thought is only enabled in VAGen if the form specifies a DBCS device. Best guess is that at some point this form was for a DBCS device and "SO/SI Take position" got included in the source; then the printer was changed to a single-byte device and for some (unknown) reason, the "SO/SI Take position" stayed around in the VAGen ESF source.

To fix the problem, you need to decide whether you need a single-byte printer, a double-byte printer, or both (for example, if you are writing 2 different reports). If you need both or if you need the double-byte printer, add the @PrintFloatingArea specification for the double-byte printer to your formGroup definition. One option is to fix the map group and map definitions in VAGen and then migrate the map group and its associates again using the migration tool's single file mode. If you do this, create a new EGL package and point the migration tool to that new package. That way, you can compare to what was previously migrated -- just in case there other things from the stage 2/3 migration that you need to pick up (for example, any import statements from the file and also the nesting of the forms within the FormGroup).

Actions

More Like This

Bottom Banner