VFP sending 8 character date in runtime with SET('CENT')='ON'

I have an application I run from both development FoxPro and from a
compiled EXE. I have CENTURY set to ON, and when running from the EXE
and writing the date to a memo file in a table (e.g. DTOC(chargedate) )
it gets written as 03/31/07. When running from the development
environment it's written as 03/31/2007.

Also vexing is the fact that when running the EXE, date fields in the
table are seen as 03/31/07 until mouse-clicked, when they expand to
03/31/2007 (i.e. if cursor is in the field). When running from the
development version of FoxPro (VFP 7.0) all the date entries are seen as
10 character (e.g. 03/31/2007).

Why am I getting this behavior and is there a fix or workaround? TIA.

Dan

Email: dmusicant at pacbell dot net

Anders
Sun Apr 01 11:54:59 CDT 2007

Do you use a private datasession in your form?
This resets lots of SETs to their default, which is OFF for SET CENTURY.
See SET DATASESSION in Help.
-Anders

"Dan_Musicant" <man@privacy.net> wrote in message
news:7sqv0313aeh8c9kpsrp9qd97fek78tdi9m@4ax.com...
>I have an application I run from both development FoxPro and from a
> compiled EXE. I have CENTURY set to ON, and when running from the EXE
> and writing the date to a memo file in a table (e.g. DTOC(chargedate) )
> it gets written as 03/31/07. When running from the development
> environment it's written as 03/31/2007.
>
> Also vexing is the fact that when running the EXE, date fields in the
> table are seen as 03/31/07 until mouse-clicked, when they expand to
> 03/31/2007 (i.e. if cursor is in the field). When running from the
> development version of FoxPro (VFP 7.0) all the date entries are seen as
> 10 character (e.g. 03/31/2007).
>
> Why am I getting this behavior and is there a fix or workaround? TIA.
>
> Dan
>
> Email: dmusicant at pacbell dot net

Cy
Sun Apr 01 12:23:10 CDT 2007

Also make sure that your not just depending on the setting of century
set in the development environment under tools->options and then setting
as default. The runtime environment does not read the development
environment's defaults. You must set century in your application in
code, and also any time you have a private data session.

Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com


Anders Altberg wrote:
> Do you use a private datasession in your form?
> This resets lots of SETs to their default, which is OFF for SET CENTURY.
> See SET DATASESSION in Help.
> -Anders
>
> "Dan_Musicant" <man@privacy.net> wrote in message
> news:7sqv0313aeh8c9kpsrp9qd97fek78tdi9m@4ax.com...
>> I have an application I run from both development FoxPro and from a
>> compiled EXE. I have CENTURY set to ON, and when running from the EXE
>> and writing the date to a memo file in a table (e.g. DTOC(chargedate) )
>> it gets written as 03/31/07. When running from the development
>> environment it's written as 03/31/2007.
>>
>> Also vexing is the fact that when running the EXE, date fields in the
>> table are seen as 03/31/07 until mouse-clicked, when they expand to
>> 03/31/2007 (i.e. if cursor is in the field). When running from the
>> development version of FoxPro (VFP 7.0) all the date entries are seen as
>> 10 character (e.g. 03/31/2007).
>>
>> Why am I getting this behavior and is there a fix or workaround? TIA.
>>
>> Dan
>>
>> Email: dmusicant at pacbell dot net
>
>

Dan_Musicant
Sun Apr 01 13:46:58 CDT 2007

On Sun, 01 Apr 2007 10:23:10 -0700, Cy Welch <cywelch@yahoo.com> wrote:

:Also make sure that your not just depending on the setting of century
:set in the development environment under tools->options and then setting
:as default. The runtime environment does not read the development
:environment's defaults. You must set century in your application in
:code, and also any time you have a private data session.
:
:Cy Welch
:Senior Programmer
:MetSYS Inc
:http://www.metsysinc.com
:
:
:Anders Altberg wrote:
:> Do you use a private datasession in your form?
:> This resets lots of SETs to their default, which is OFF for SET CENTURY.
:> See SET DATASESSION in Help.
:> -Anders

The application runs with a FoxPro 2.6a for Windows screen. There is no
private data session. As an additional measure I added some code. The
writing of DTOC(chargedate) where chargedate is a data type field in the
current pointed-to record is driven by a program, a separate PRG. In the
PRG I added the line above the write:

SET CENTURY ON

The date is still written as 03/31/07 when run by the EXE.

I'll try another test. I will additionally have the PRG write the
following after the date: "Century is set to "+ SET('CENTURY')

Sure enough, it says Century is set to OFF.

I don't know why this is happening. There's a config.fpw in the project
that says:

CENTURY=ON

I also just put the following in the main program:

SET CENTURY ON

It's still happening.

Email: dmusicant at pacbell dot net

Fred
Sun Apr 01 14:17:45 CDT 2007

Then search for SET CENTURY code in your programs. Somewhere, it's getting
SET to OFF.

--
Fred
Microsoft Visual FoxPro MVP


"Dan_Musicant" <man@privacy.net> wrote in message
news:6b0013h8t30jfus0s4cjrnqd62m40nf51m@4ax.com...
> On Sun, 01 Apr 2007 10:23:10 -0700, Cy Welch <cywelch@yahoo.com> wrote:
>
> :Also make sure that your not just depending on the setting of century
> :set in the development environment under tools->options and then setting
> :as default. The runtime environment does not read the development
> :environment's defaults. You must set century in your application in
> :code, and also any time you have a private data session.
> :
> :Cy Welch
> :Senior Programmer
> :MetSYS Inc
> :http://www.metsysinc.com
> :
> :
> :Anders Altberg wrote:
> :> Do you use a private datasession in your form?
> :> This resets lots of SETs to their default, which is OFF for SET
> CENTURY.
> :> See SET DATASESSION in Help.
> :> -Anders
>
> The application runs with a FoxPro 2.6a for Windows screen. There is no
> private data session. As an additional measure I added some code. The
> writing of DTOC(chargedate) where chargedate is a data type field in the
> current pointed-to record is driven by a program, a separate PRG. In the
> PRG I added the line above the write:
>
> SET CENTURY ON
>
> The date is still written as 03/31/07 when run by the EXE.
>
> I'll try another test. I will additionally have the PRG write the
> following after the date: "Century is set to "+ SET('CENTURY')
>
> Sure enough, it says Century is set to OFF.
>
> I don't know why this is happening. There's a config.fpw in the project
> that says:
>
> CENTURY=ON
>
> I also just put the following in the main program:
>
> SET CENTURY ON
>
> It's still happening.
>
> Email: dmusicant at pacbell dot net

Dan_Musicant
Sun Apr 01 14:26:04 CDT 2007

On Sun, 01 Apr 2007 10:23:10 -0700, Cy Welch <cywelch@yahoo.com> wrote:

:
:Also make sure that your not just depending on the setting of century
:set in the development environment under tools->options and then setting
:as default. The runtime environment does not read the development
:environment's defaults. You must set century in your application in
:code, and also any time you have a private data session.
:
:Cy Welch
:Senior Programmer
:MetSYS Inc
:http://www.metsysinc.com

The application is pretty simple. There's a large main PRG that runs a
FPW 2.6a screen that opens tables, and some other stuff. I just added
code to the screen's setup code that sets century on. However, it's
having no effect. All the tables opened from that screen when run from
the EXE have Century = 'OFF'. Why is this and what can I do to force
SET('Century') = 'ON' ? I have some code that runs when tables close, at
least when such code exists, and if that code has the line SET CENTURY
ON, then CENTURY is on the rest of the time. This is pretty confusing.
There's no form, technically, in this application. There's just an SPR
for the screen that's put in the project.

Dan

Email: dmusicant at pacbell dot net

Dan_Musicant
Sun Apr 01 14:28:18 CDT 2007

On Sun, 1 Apr 2007 12:17:45 -0700, "Fred Taylor"
<ftaylor@mvps.org!REMOVE> wrote:

:Then search for SET CENTURY code in your programs. Somewhere, it's getting
:SET to OFF.
:
:--
:Fred
:Microsoft Visual FoxPro MVP

It's not being done when I run from the development environment so I
have to think it's not being done in code. Besides, I'd never set it off
intentionally. What I'd do is test for SET('CENTURY'), save the setting
and restore it after the application is run. I've been very carefull
about things like that because this is a utility that's designed to be
run anywhere and not mess up anything else being done with FoxPro.

Dan

Email: dmusicant at pacbell dot net

Dan_Musicant
Sun Apr 01 17:23:28 CDT 2007

I finally got things working. Forced CENTURY to ON in code. I thought it
should have been already, since the config.fpw specified it there, but
that failed for some reason. Maybe it was getting changed to OFF in
code. There are places where that could happen. Anyway, it's working
now.

Dan

Email: dmusicant at pacbell dot net

Man-wai
Mon Apr 02 07:23:35 CDT 2007

> I finally got things working. Forced CENTURY to ON in code. I thought it
> should have been already, since the config.fpw specified it there, but
> that failed for some reason. Maybe it was getting changed to OFF in
> code. There are places where that could happen. Anyway, it's working
> now.

Will it break other codes? Any function assuming CENTURY OFF?

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.20.4
^ ^ 20:23:01 up 9 days 7:35 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Mon Apr 02 07:25:11 CDT 2007

> The application is pretty simple. There's a large main PRG that runs a
> FPW 2.6a screen that opens tables, and some other stuff. I just added
> code to the screen's setup code that sets century on. However, it's
> having no effect. All the tables opened from that screen when run from
> the EXE have Century = 'OFF'. Why is this and what can I do to force
> SET('Century') = 'ON' ? I have some code that runs when tables close, at

you better do a text search on ALL source codoe for "SET CENT".

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.20.4
^ ^ 20:24:01 up 9 days 7:36 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Dan_Musicant
Tue Apr 03 14:06:29 CDT 2007

On Mon, 02 Apr 2007 20:23:35 +0800, Man-wai Chang
<toylet.toylet@gmail.com> wrote:

:> I finally got things working. Forced CENTURY to ON in code. I thought it
:> should have been already, since the config.fpw specified it there, but
:> that failed for some reason. Maybe it was getting changed to OFF in
:> code. There are places where that could happen. Anyway, it's working
:> now.
:
:Will it break other codes? Any function assuming CENTURY OFF?

I don't think so, but I want to be sure that if I run this from within
other code it will not interfere.

Email: dmusicant at pacbell dot net

Cy
Tue Apr 03 14:19:45 CDT 2007

As I had mentioned earlier, the development environment can remember
your century setting from tools->options. The runtime environment
specifically will be century off unless you specifically IN CODE set
century on. I believe that he found that adding that fixed the problem.

Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com


Man-wai Chang wrote:
>> I finally got things working. Forced CENTURY to ON in code. I thought it
>> should have been already, since the config.fpw specified it there, but
>> that failed for some reason. Maybe it was getting changed to OFF in
>> code. There are places where that could happen. Anyway, it's working
>> now.
>
> Will it break other codes? Any function assuming CENTURY OFF?
>