Report form automatically falls onto SET DATE AMERICAN 5

[Rajesh Karunakaran]

Hi Friends,

I have a report form. Before calling that I am setting SET DATE BRITISH. However, immediately after the control goes to the line REPORT FORM (lReportFile) PREVIEW, I can see the the SET DATE has become AMERICAN. Because of this my date fields are shown as mm/dd/yy format whereas I wanted them to be dd/mm/yyyy.

I have searched all over the report form, its data enviro setting and tables I have added onto it. Couldn't find anything causing this problem. Even if I select (checked the check box) 'Field Properties' -> 'Format' -> 'British Date' for my date field, that wouldn't help!

Anyone has any clue? Is this a know behavioral issue?

Thanks in advance.
Rajesh

 

[Olaf Doschke]

Is the type of field you print really date, or does it contain character, dates already converted?
Because setting the date format in both form and report controls with a datefield controlsource will work.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Hi Olaf,

Its a DATE field. When I open the table and set the date to BRITISH, AMERICAN etc, I can see the corresponding change in the display. I am not converting or changing anything. I think, there is some kind of corruption in the report file, could it be?

In the code where I am calling the report form I am in fact doing a SET DATE BRITISH and SET CENTURY ON and it has provision to reset the SET DATE and SET CENTURY to its previous state when my method finishes.

Now, I managed by setting the date BRITISH in the INIT of report form and my date shows correctly.
However, I am not yet sure why the setting was getting disturbed on its own!

Thank you very much for your time.
Rajesh

 

[atlopes]

Rajesh

If your report has a private data session, the date format setting you define in your caller program won't affect the report behavior.

 

[Olaf Doschke]

Hmm, that's funny.

The setting you do in a report field directly should be used. Atlopes would be right, if you didn't set anything there, the date format setting will be per datasession and a report with private datasession therefor has the VFP default of US date.

I'd perhaps USE the report as table and look for all records having the field name in its Expr memo field.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

Rajesh, it could be that Atlopes is on the right track. Let me try to clarify this issue.

In the Report menu in the Report Designer, there is an option named "Private Data Session". If that option is ticked, then the report will expect to find its driving table in its own data environment. In that case, it will also default to all the settings that are scoped to the data session. SET DATE is one of those settings.

If your report has "Private Data Session" ticked, then you have two options. First, you could simply un-tick it. But that could mean that you have to make other changes in the calling form, to ensure that the correct tables are present (with the correct indexes, relationships, etc.)

The other posibility is to run an optional expression in the report's Title or Page Header band. To do that, double-click on the band in the designer, and in the resulting dialogue, type an expression in the "On entry" box. The expression Would be [tt]EXECSCRIPT("SET DATE BRITISH")[/tt].

My preference would be for the second option.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

Or put SET DATE BRITISH in the Init method of the report's Data Environment.

Tamar

 

[Olaf Doschke]

Maybe I did think you used this directly in the report controls displaying dates:

If you do so, you'll not depend on the overall DATE setting.
That corresponds to a textbox's DateFormat property you can also set to 3 to not depend on SET DATE BRITISH.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Dear Atlopes, Mike, Olaf, Tamar,

Thank you all for your time!

Yes, mine is a Private Data Session!
Atlopes, you got the right clue it seems!

Tamar, in my reply earlier to Olaf, I mentioned that I came out of this by giving 'SET DATE BRITISH' in Init of report form Data Environment Code. That was the solution I could figure out.

Olaf, yes I had done that (as in your image) but it didn't solve the problem for some reason.

Thank you all!
Rajesh

 

[Olaf Doschke]

I could reproduce, yes. Weird.

If I SET SYSFORMATS ON, which sets several settings for my German locale, DATE order is DMY, MARK character is "." and in my case (that can be set apart from the language of the locale in the regional settings of windows) century is on and the short format is used, not long dates with weekday and month name.

That's already a sensible solution overall if you merely want local formatting. Indeed, at runtime the runtime will use the locale and localized resource DLL anyway, so your problem might only occur during development if it is about getting your locale settings.

Now, the surprising thing (to me) is, that setting for British of the report control format does not override that, which seems like a bug to me.

Only when I both SET SYSFORMATS ON and then SET MARK TO (without specifying a mark character), then the British date format of the report control finally overrides the MARK character to a slash.

So the curious thing is, the MARK setting from SET SYSFORMATS ON seems to prevent the change of the MARK. German and Britsh date only differ in that aspect. But it's even more curious if I do SET SYSFORMATS ON, then SET MARK TO and SET DATE AMERICAN, the report control Format set to British can override the order from mm/dd/yyyy to dd/mm/yyyy again. If I SET SYSFORMATS ON and not change MARK to nothing and SET DATE AMERICAN, I get german output even with report control format set to British, so it seems the central setting that needs to be made unspecific is SET MARK, otherwise both SET DATE BRITISH/AMERICAN/... and the report control override to British format are having no effect at all.

So if the MARK character doesn't match it seems Windows prevents Foxpro from making changes to the date format. Makes me wonder, what your locale is, if it's British you'd just need SET SYSFORMATS ON, if it's American then I wonder if MARK still plays a role, it's the slash in both cases.

It's weird, but even if you can't wrap your head around what I just said, the conclusion is you need code in the report to fix the reports Date format and better don't rely on that report control format setting. It's a bit weird and less practical anyway, as it only specifically allows British and no other language.

Another bug to note and keep in mind. Besides the behavior is not better without a private datasession, you also don't get the British override most of the time, but you at least get what your settings for the current datasession are and that's usually what you want anyway.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Rajesh Karunakaran]

Dear Olaf,

Great analysis and study!
Thank you very much for that and sharing your observations.

Thank you once again,
Rajesh

 

[Olaf Doschke]

Thanks. It's really weird in many senses, as even with SET SYSFORMATS ON you just copy over some system settings about date and currency and number formats into VFP internal settings. Changing system settings only will be reflected with the next SET SYSFORMATS ON you do, eg next application start or next form start, if you do it per form or datasession. So it should be an internal error, nothing related to Win 10 Builds, for example.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

I agree that it's weird. You would expect the more local the setting, the more likely it would be to override the default behaviour. So setting the date format for the specific field should take priority over setting it in the data environment.

I wonder what would happen if you set the field's expression to:

[tt]TRANSFORM(DateField, "@E)[/tt]

In theory, that should give British format regardless of SET DATE. But maybe the same weirdness would apply.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Yes, the same weirdness, I also get no slashes, before I don't "un"specify the date mark by literally executing [tt]SET MARK TO[/tt] without specifying a date mark character.
After I do [tt]SET MARK TO[/tt] I get British date with slashes from [tt]? TRANSFORM(Date(),"@E")[/tt] and German date with [tt]? TRANSFORM(Date())[/tt] or [tt]? TRANSFORM(Date(),"@D")[/tt], as that uses current date formatting anyway. I don't need to make any SET DATE or SET MARK or other settings when switching between the different TRANSFORMS, then, but if SET('MARK') is the German dot, that stays. So really everything concentrates about SET MARK TO.

So far I only tested within the IDE and not how the runtime behaves, I assume there is no difference. My strategy is to let all these language/locale specific settings be managed with SET SYSFORMATS ON and that in itself works.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name