2 suggestions:

1) using format and deformat trigger to translate between the calendar systems (just adding/subtracting the number of days):

2) embed an external calendar widget (OCX container?) which does the checks, Datepicker invocation etc.

Uli

What about the FORMAT/DEFORMAT-trigger?

Set a global variable with the difference in years

Define a globale variables

  $$TL_DATE_X   ; type date and well know display format  (if you want to do furter formating)

  $$TL_YEAR_X  ; type numeric and display format "9999"

On format:

$$TL_DATE_X=$format

$$TL_YEAR_X=$format[7:4]+$$YEAR_DIFF

$format="%%$format[1:6]%%$$TL_YEAR%%%"

On deformat (if the user enter data in format dd/mm/yyyy. Else one have to code a little bit more :) )

$$TL_YEAR_X=$format[7:4]-$$YEAR_DIFF

$format="%%$format[1:6]%%$$TL_YEAR%%%"

Regards

ingo

Dear Uli and Ingo

I've made some tests with these triggers.
Using Format and Deformat triggers seems to be a good solution.

I'll make complementary testing and I'll let you know

Thanks for your time
Nicolas

Just another suggestion (with uniface 9.4.):

Look at $nlslocale and $nlsformat in Combination with date-formats, which "should" also work, because this takes the regional settings of windows.

But never tested.

Wolfgang

I've tested with $NLSLOCALE set to "system"
I've changed the regional settings to 'Thai'
When I initialize a date with $date, the date is formatted in Thai language (even the numbers) while Windows only translate the month.

As I can't read Thai, I've made a copy and paste of the date in google translation.
The year displayed is 2011

So, it seems that I cannot use $nlslocale to solve my problem.

But many thanks for this idea.

For information, I've made complementary tests with Format and Deformat triggers and it works well even if this solution is depending on the layout applied on the date field.
I'll have to enhance the code in order to be sure to find the year to replace at the right place in the $format string.

Thanks to all for your help

Nicolas

$nlslocale sounds like a bug in this specific situation.

On the other hand, just use the DIS-Format for  the year with era correction (see Help-file)

you can solve it without format/deformat.

Wolfgang

$nslocale is pretty buggy. I have three different problems with it outstanding with the Labs (and have had for several months). I'd avoid it if possible for a good while yet.

available only with uniface 9.4, I suppose.
Avoids year-substraction in the format/deformat trigger in an elegant manner.

Thanks for sharing,
Uli

Very nice this new feature  "yyyy+nnn" resp.  DIS(dd/mm/yyy+543)

But doesn't work in a flexible, runtime dependig manner :-(

What about the ney syntax:   DIS ( $NLS ( NlsFormat ))   ?

Does anyone have any experience with this new possibilities?

Ingo

Yes.

If you use the $NLS format on dates, there is no equivalent syntax entry ( ENT() ), no date validation is done on entry and odd results can happen.

1. If your locale is EN_US, and you enter the date in EN_GB format, 23/2/10 you get 11/2/11 back (it adds 23 months to the beginning of 2010 to get the end of 2011). As a programmer, you can't trap whether this has happenned, as the date returned is viable.
Similarly if you enter 2/23/10 in EN_GB you get 2/11/11 back.
2. If you are in the habit of entering part of a date and letting windows fill in the rest (i.e. putting 8 in the field gets you 8/4/11), the $NLS system remembers the last date you entered (or possibly displayed) and fills the rest of the date in with those values.

$nls_locale has other issues.
Numeric variables are treated as floats, and therefore "Fred_%%v_counter%%" switches from returning "Fred_1" to returning "Fred_1.00"
In fact, if you set $nls_locale=system in the idf asn, the whole thing stops working because the 'feature' above means that variable redirection doesn't work.

I've tested DIS format including +543.
It works well only if you want to display a date.

But it does not work when you enter a date :
- the date stored contains 543 more years than the date entered.
- The date validation is made on the date stored. So bissextile year is wrongly controled.
- the new date is displayed with 543 more years (1086 than the date entered)

I think we will finally choose the Format/Deformat Triggers solution.
In these triggers, we will call a Global Proc which will Format or Deformat the $format string:
- The formatting will depends on customer deployement options. In this way, our application will continue to work worldwide.
- The dates are always stored in Gregorian Calendar
- The date validation is made on the Gregorian date
- We can continue to enter only parts of the date (day, day+month, etc)

But it will be a huge job, because we need :
- to update the model. We must modify the Format/Deformat triggers for every date field
- to check every form, because as soon as the database date fields are copied into variables, the display of the variables will not be updated.

Nicolas

Hi Nicholas,

you can use GLOBAL UPDATES to modify the FORMAT/DEFORMAT triggers
for the model as well as the (non-database) component fields; all depends on your search profile.
I think it is a good start if you select all fields of datatype "date" and "combined date".

I recommend just to add an INCLUDED PROC specified in library DATECONTROL into the triggers:

#include DATECONTROL:<$triggerabbr>

allows you a more flexible way of getting the job done.

For checking the source because of copied variables, I prefer using grep, awk, perl or so against the PROC LISTINGS.

Very fast, very easy to handle.

Perhaps it would be a good idea to enrich these variables with a clone for the presentation
or you create a real date_toString function (returns string) to transfer a formatted date.

So all you need is to change:

$just_to_show$ = "This is just a %%$my_date$%%%"

$just_to_show$ = "This is just a %%date_toString($my_date$)%%%"

Easy, isn't it?

Uli

Hi Uli

I will investigate this solution

Thanks for your advice

Nicolas