F. Gutiérrez
10-Jun-2020, 10:14 AM
Hi
I’m using the ReportView Wizard with a desktop web app in DF 20 Alpha 1 + DF Reports 20 Technology Preview. The generated code for the filters is identical to 19.0 but I have detected this behavior which is different.
This procedure would get the value of 2 dates for a filter in the report:
Procedure SetFilters
String sReportId
String[] sDateFilters
Get psReportId to sReportId
WebGet psValue of oFromMOVIFECHA to sDateFilters[0]
WebGet psValue of oToMOVIFECHA to sDateFilters[1]
// Todo: Check if you want the values to be sorted for hi-low correction or not
If (Not (IsNullDateTime (sDateFilters[0]))) Begin
Get DateToString of oReport sDateFilters[0] to sDateFilters[0]
Send AddFilter sReportId "{MOVI.FECHA}" C_drGreaterThanOrEqual sDateFilters[0]
End
If (Not (IsNullDateTime (sDateFilters[1]))) Begin
Get DateToString of oReport sDateFilters[1] to sDateFilters[1]
Send AddFilter sReportId "{MOVI.FECHA}" C_drLessThanOrEqual sDateFilters[1]
End
End_Procedure
In 19.0 the date’s format is local. For example: sDateFilters[0]=”10/06/2020”
In 20.0 Alpha 1, the date looks like ISO 8601: sDateFilters[0]=”2020-06-10”
So this line will fail:
Get DateToString of oReport sDateFilters[0] to sDateFilters[0]
Because the date becomes “0-00-20” and the report will not yield results.
Is this a bug or does WebGet for a date field now return an ISO 8601 format? If it is like this, it could be breaking (for example, moving that to a Date variable will fail).
As an aside, the ReportView Wizard (and others) have trouble bringing Unicode characters back to the Studio. For example, the Spanish for "selection" (“selección”) will become “selecci├│n.”
I’m using the ReportView Wizard with a desktop web app in DF 20 Alpha 1 + DF Reports 20 Technology Preview. The generated code for the filters is identical to 19.0 but I have detected this behavior which is different.
This procedure would get the value of 2 dates for a filter in the report:
Procedure SetFilters
String sReportId
String[] sDateFilters
Get psReportId to sReportId
WebGet psValue of oFromMOVIFECHA to sDateFilters[0]
WebGet psValue of oToMOVIFECHA to sDateFilters[1]
// Todo: Check if you want the values to be sorted for hi-low correction or not
If (Not (IsNullDateTime (sDateFilters[0]))) Begin
Get DateToString of oReport sDateFilters[0] to sDateFilters[0]
Send AddFilter sReportId "{MOVI.FECHA}" C_drGreaterThanOrEqual sDateFilters[0]
End
If (Not (IsNullDateTime (sDateFilters[1]))) Begin
Get DateToString of oReport sDateFilters[1] to sDateFilters[1]
Send AddFilter sReportId "{MOVI.FECHA}" C_drLessThanOrEqual sDateFilters[1]
End
End_Procedure
In 19.0 the date’s format is local. For example: sDateFilters[0]=”10/06/2020”
In 20.0 Alpha 1, the date looks like ISO 8601: sDateFilters[0]=”2020-06-10”
So this line will fail:
Get DateToString of oReport sDateFilters[0] to sDateFilters[0]
Because the date becomes “0-00-20” and the report will not yield results.
Is this a bug or does WebGet for a date field now return an ISO 8601 format? If it is like this, it could be breaking (for example, moving that to a Date variable will fail).
As an aside, the ReportView Wizard (and others) have trouble bringing Unicode characters back to the Studio. For example, the Spanish for "selection" (“selección”) will become “selecci├│n.”