FMP v8.5 adv
Win XP

I have built a calender/remember file.

A have fields:
DateToRemember <Date>
WarnDaysAhead <Number>

What I want is to to have a calculation that returns TRUE (1) when the
application needs to remind me or FALSE (0) when no reminder is needed. I
seem to miss something. I have tried a couple of things but never have
gotten it right.

The current calc is:

cRemember
Let (
DIF = DateToRemember - get ( CurrentDate) ;
Case (
DIF < 0 ; 0 ;
IsEmpty ( WarnDaysAhead ) ; 0 ;
DIF > WarnDaysAhead ; 0;
1)
)

So my reasoning was:
DIF < 0 the DateToRemember is a date in the past. (I don't want to be
remembered of those)
IsEmpty ( WarnDaysAhead ) I don't want to be remembered at all
DIF > WarnDaysAhead the DateToRemember is further ahead the the number of
day I have entered in WarnDaysAhead. (I don't want to be remembered yet)
In all other cases it is TRUE (1) and I should get warned.

Now I have this calender file and I create a separate check file. This will
perform just the check. I create a constant here (c_Const <1>) and related
this to the cRemember. Now the start-script checks if this relationship is
valid. (There are records that returned TRUE).

But one way ore the other I don't get the first calculation to return the
expected results. What am I missing.

Keep Well, Ursus

Ursus wrote:
> FMP v8.5 adv
> Win XP
>
> I have built a calender/remember file.
>
> A have fields:
> DateToRemember <Date>
> WarnDaysAhead <Number>
>
> What I want is to to have a calculation that returns TRUE (1) when the
> application needs to remind me or FALSE (0) when no reminder is needed. I
> seem to miss something. I have tried a couple of things but never have
> gotten it right.
>
> The current calc is:
>
> cRemember
> Let (
> DIF = DateToRemember - get ( CurrentDate) ;
> Case (
> DIF < 0 ; 0 ;
> IsEmpty ( WarnDaysAhead ) ; 0 ;
> DIF > WarnDaysAhead ; 0;
> 1)
> )
>
> So my reasoning was:
> DIF < 0 the DateToRemember is a date in the past. (I don't want to be
> remembered of those)
> IsEmpty ( WarnDaysAhead ) I don't want to be remembered at all
> DIF > WarnDaysAhead the DateToRemember is further ahead the the number of
> day I have entered in WarnDaysAhead. (I don't want to be remembered yet)
> In all other cases it is TRUE (1) and I should get warned.
>
> Now I have this calender file and I create a separate check file. This will
> perform just the check. I create a constant here (c_Const <1>) and related
> this to the cRemember. Now the start-script checks if this relationship is
> valid. (There are records that returned TRUE).
>
> But one way ore the other I don't get the first calculation to return the
> expected results. What am I missing.
>
> Keep Well, Ursus
>
>


Hi Ursus,

try this (with some extranea/options)

Let([
F = WarnDaysAhead;
DTR = DateToRemember;
C = Get ( CurrentDate);
DIFF = DTR - C


//WarnRePast = Case(F < C; 0;IsEmpty(F); 0);
//WarnAhead = Case( (DTR - C) > F; ""; 1)



];

Case(
//IsEmpty ( WarnDaysAhead ) I don't want to be remembered at all
IsEmpty(F); 0;
// DIF > WarnDaysAhead the DateToRemember is further ahead the the
number of day I have entered in WarnDaysAhead. (I don't want to be
remembered yet)
DIFF > F; 0;
// DIF < 0 the DateToRemember is a date in the past. (I don't want to
be remembered of those)
DTR < C; 0;


(DTR > C) and (DTR-C) > F; "not yet";
// warn
(DIFF > 0) and (DIFF ≤ F); 1;


1

))


regards

Chris

I think I have a similar problem in that I would like a text field
colored based on how a value in a date field compares to the Current
Date. The coloring will work correctly if I modify the calculation
but not on following days. My feeling is that a change in the Current
Date will not cause the calculations to be re-evaluated. Various
attempts at using the Evaluate function where a trigger variable is
based on the Current Date have not helped.

If there is a way to make the system controlled Current Date trigger a
calculation, we will both be happy.

Tom

On Jul 8, 5:59 pm, Chris Brown <cbr... [at] medicine.adelaide.edu.au>
wrote:
> Ursus wrote:
> > The current calc is:
>
> > cRemember
> > Let (
> > DIF = DateToRemember - get ( CurrentDate) ;
> > Case (
> > DIF < 0 ; 0 ;
> > IsEmpty ( WarnDaysAhead ) ; 0 ;
> > DIF > WarnDaysAhead ; 0;
> > 1)
> > )

"Chris Brown" <cbrown [at] medicine.adelaide.edu.au> schreef in bericht
news:f6s19n$g4v$1 [at] aioe.org...
> Ursus wrote:
>> FMP v8.5 adv
>> Win XP
>>
>> I have built a calender/remember file.
>>

>
> Hi Ursus,
>
> try this (with some extranea/options)
>
Thanks Chris,

Why does this work. What I have done with my own file is split the case that
I originally posted into three separate calculations and then created a
fourth that simply reads CalcA AND CalcB AND CalcC. This does also has the
correct result. Why would my case not work and why does it work when split
into three parts.

But then again. It now dows work. Thanks for that.

Ursus

Ursus wrote:
> "Chris Brown" <cbrown [at] medicine.adelaide.edu.au> schreef in bericht
> news:f6s19n$g4v$1 [at] aioe.org...
>> Ursus wrote:
>>> FMP v8.5 adv
>>> Win XP
>>>
>>> I have built a calender/remember file.
>>>
>
>> Hi Ursus,
>>
>> try this (with some extranea/options)
>>
> Thanks Chris,
>
> Why does this work. What I have done with my own file is split the case that
> I originally posted into three separate calculations and then created a
> fourth that simply reads CalcA AND CalcB AND CalcC. This does also has the
> correct result. Why would my case not work and why does it work when split
> into three parts.
>
> But then again. It now dows work. Thanks for that.
>
> Ursus
>
>


My guess would be that it is the sequence in the case statement, the
first line gets result/execution priority, the second row next
priority... I often build these up from separate calcs too, its a good
way of checking logic elements.

regards


Chris

TomMcIn wrote:
> I think I have a similar problem in that I would like a text field
> colored based on how a value in a date field compares to the Current
> Date. The coloring will work correctly if I modify the calculation
> but not on following days. My feeling is that a change in the Current
> Date will not cause the calculations to be re-evaluated. Various
> attempts at using the Evaluate function where a trigger variable is
> based on the Current Date have not helped.
>
> If there is a way to make the system controlled Current Date trigger a
> calculation, we will both be happy.
>
> Tom
>
> On Jul 8, 5:59 pm, Chris Brown <cbr... [at] medicine.adelaide.edu.au>
> wrote:
>> Ursus wrote:
>>> The current calc is:
>>> cRemember
>>> Let (
>>> DIF = DateToRemember - get ( CurrentDate) ;
>>> Case (
>>> DIF < 0 ; 0 ;
>>> IsEmpty ( WarnDaysAhead ) ; 0 ;
>>> DIF > WarnDaysAhead ; 0;
>>> 1)
>>> )
>


Hi Tom,

I not quite clear on the:

<<the coloring will work correctly if I modify the calculation
but not on following days>>


It sounds like an indexing issue.
Can you post More details?


regards

Chris

>> Why does this work. What I have done with my own file is split the case
>> that I originally posted into three separate calculations and then
>> created a fourth that simply reads CalcA AND CalcB AND CalcC. This does
>> also has the correct result. Why would my case not work and why does it
>> work when split into three parts.
>>
>> But then again. It now dows work. Thanks for that.
>>
>> Ursus
>
>
> My guess would be that it is the sequence in the case statement, the first
> line gets result/execution priority, the second row next priority... I
> often build these up from separate calcs too, its a good way of checking
> logic elements.
>
> regards

I have to come back on this. It does in fact NOT work for dates I create in
the future. Yesterday I created a test record for today. I just closed the
file and fired the check today. I did not get any warning. Then I opened the
calender file switched to the record that holds the test-item. Then refired
the test and it DID work. And then afterwards worked on every single test I
did. It still looks like the calculation on the date or the relationship
does not update.

Ursus

Ursus wrote:
>>> Why does this work. What I have done with my own file is split the case
>>> that I originally posted into three separate calculations and then
>>> created a fourth that simply reads CalcA AND CalcB AND CalcC. This does
>>> also has the correct result. Why would my case not work and why does it
>>> work when split into three parts.
>>>
>>> But then again. It now dows work. Thanks for that.
>>>
>>> Ursus
>>
>> My guess would be that it is the sequence in the case statement, the first
>> line gets result/execution priority, the second row next priority... I
>> often build these up from separate calcs too, its a good way of checking
>> logic elements.
>>
>> regards
>
> I have to come back on this. It does in fact NOT work for dates I create in
> the future. Yesterday I created a test record for today. I just closed the
> file and fired the check today. I did not get any warning. Then I opened the
> calender file switched to the record that holds the test-item. Then refired
> the test and it DID work. And then afterwards worked on every single test I
> did. It still looks like the calculation on the date or the relationship
> does not update.
>
> Ursus
>
>


Hi Ursus

the opening of the calendar file causing it to work, sounds like a
reindexing event to me. (forced at launch or file open; I forget which;
Howard S. had something to say on this ages ago)

I'm really not clear on which arrangement is not working. Do you mean
the calc I suggested, or the original?

If its the combined original one you are still puzzling over (I would be
too btw), It sounds like an indexing or refresh issue. What about
forcing a refresh or re-index a as a simple test after changing the
date? Although I have been using commit for quite a while now, I had a
situation late last week, where it would not trigger the refresh I
expected. Had to resort to the old enter preview/enter browse
combination to force the script calc.


The calc itself is unindexed?

I just tried the calc I suggested again, with 2 days as the WarnAhead value

DateToRemember Warn
10.7.07 1
11.7.07 1
12.7.07 1
13.7.07 0

Indexing on calc is:
do not store
Indexing none
automatically create as needed


Had a look at your original post, I am assuming
File_Check (c_constant)
File_Calendar (with calc c_Remember)
rel from Check to Cal using 1:: c_remember


that you created todays date in advance in CAL, then closed the file,
then today opened CHECK and it didn't recognize the value 1 records in
CAL, really sounds like CAL hasn't re-indexed. And it won't until either
it is reopened (and when it is, the Check works), or forced to reindex
(which closing doesn't do; opening does; as far as I know)

so you need to trigger a re-index, before closing CAL, or open CAL ,
before opening CHECK, in order to trigger the re-index in CAL


hope this helps

regards

Chris

>
> that you created todays date in advance in CAL, then closed the file, then
> today opened CHECK and it didn't recognize the value 1 records in CAL,
> really sounds like CAL hasn't re-indexed. And it won't until either it is
> reopened (and when it is, the Check works), or forced to reindex (which
> closing doesn't do; opening does; as far as I know)
>
> so you need to trigger a re-index, before closing CAL, or open CAL ,
> before opening CHECK, in order to trigger the re-index in CAL
>
>

I have been trying for a week now. And one way ore the other I have run into
trouble with calculated resutls. Most of them disappeared after I opened the
main file. But then re-apperad again when the file was closed. I have now
chucked out all the calculations and instead created a set field step in the
start script that fils the field. Since this forces the file open and forces
the refresh that was needed. I assume the troubles will be over now.

Thanks for your time and trouble,

Keep well, Ursus