www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DateTime resetting

reply Joel <joelcnz gmail.com> writes:
I've been working on a diary program (ChronoLog). but lately my 
date and time variable keeps resetting. I've spent hours trying 
to fix it. I'm wondering if there's a known issue.
Oct 11 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 11 October 2022 at 22:09:34 UTC, Joel wrote:
 I've been working on a diary program (ChronoLog). but lately my 
 date and time variable keeps resetting. I've spent hours trying 
 to fix it. I'm wondering if there's a known issue.
An ordinary DateTime variable? Those are pretty simple and won't reset unless something else is wrong around it. Do you have the code online? Or can at least show some of the context around its use?
Oct 11 2022
parent reply Joel <joelcnz gmail.com> writes:
On Tuesday, 11 October 2022 at 22:21:35 UTC, Adam D Ruppe wrote:
 On Tuesday, 11 October 2022 at 22:09:34 UTC, Joel wrote:
 I've been working on a diary program (ChronoLog). but lately 
 my date and time variable keeps resetting. I've spent hours 
 trying to fix it. I'm wondering if there's a known issue.
An ordinary DateTime variable? Those are pretty simple and won't reset unless something else is wrong around it. Do you have the code online? Or can at least show some of the context around its use?
I programmed the date and time stuff past midnight, then I think I had trouble onwards. Here's code, I've included other code (maybe it can be compiled and run): https://www.icloud.com/iclouddrive/08fL87THzs2BrI7-lEwXFF0Mw#ChronoLog_etc
Oct 11 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
I'm just eyeballing the code, is it the g_dateTimeCursor you're 
concerned about? That's the only one I really see there.

A few things that might explain it:

1) as a global variable, it is thread local. I don't see any use 
of threads in here, but if you do, each one has a separate copy 
and other threads won't see the same value. I do see a `new Task` 
in places though so maybe it is this... I don't know where that's 
coming from or what it actually does but possible the different 
tasks are running in different threads, and thus seeing a 
different variable. If it is this, you can make the variable 
`shared` (then handle the cross thread safety so they don't 
overwrite each other) and maybe fix it.

2) there's a bunch of places it might be modified from so 
possible you just overwrite it somewhere....


I also see a _dateTime in there. This is a member of the Control 
struct.... and since it is a struct, remember it is an 
independent value whenever you use it, just like an int.

int a = 5;
int getA() { return a; }

int b = getA();
b += 5;

// but a is still 5 here! Because ints are values, when it is 
returned by the function, it gets an independent copy.

Structs work the same way. So that `getControl` in base.d returns 
an independent copy of the control, and this has an independent 
copy of the _dateTime variable too. Changes to one will not 
affect the original.

So this might cause your problem too, with the info being lost. 
It is possible that changing getControl to return `ref` will help 
here, but hard to be sure when just eyeballing the code like I am.


Let me know if this helps.
Oct 11 2022
parent Joel <joelcnz gmail.com> writes:
On Tuesday, 11 October 2022 at 23:28:50 UTC, Adam D Ruppe wrote:
 I'm just eyeballing the code, is it the g_dateTimeCursor you're 
 concerned about? That's the only one I really see there.

 [...]
Yes! :-D getControl was the issue, I've used ref on its return value now. Thanks so much for your help! :-)
Oct 11 2022