Drop-down calendar replacing chosen date

[eljefejb]

I have a date field on a layout (in a portal, if that makes any difference) that allows the user to select a date with the drop-down calendar.  I noticed that it is replacing the date selected by the user with the current date, at least at first.  If you click it again and re-select the desired date, it will stick the second time.  There are no auto-enter options or default values set.  I have the 4-digit year and not empty requirement boxes checked.  What gives?  This is in FMP 16.

[comment]

I am not able to reproduce this behavior - so the question is if the problem is with your system or with your file. In order to get closer to an answer, see if you can reproduce the problem in a brand new file. And try also the attached file.

 

NewTest.fmp12

[eljefejb]

I was able to reproduce the behavior in a new file.  I think it has to do with the relationship to the portal table.  I must not understand something about how it works.  Here's a simple example:

Table A has fields ID (number), startDate, and endDate.  Table B has fields ID, Date, and Hours.  The relationship is defined as A::ID = B::ID and A::startDate <= B::Date and A::endDate >= B::Date.  The checkbox to allow creation of records in Table B via the relationship is checked.

The layout for Table A has a portal to Table B, with the B::Date field being a drop-down calendar.

I had thought that clicking in the Date field in a new row of the portal would create a new related record, automatically filling in the value of A::ID for B::ID, and setting the value of B::Date to whatever was selected in the drop-down calendar.  Instead, it seems that the record is created, but the current date is entered for B::Date.  I thought maybe this is because the related record isn't committed until you click outside the date field, but if you switch to the layout for Table B, you can see that the record was clearly committed.  It just doesn't contain the date selected in the drop-down calendar.

I know I could work around this by making global fields on the Table A layout and attaching a script to a button that does the actual creation of the record in Table B.  But now I'm curious to understand what I'm missing as to how the portal works, just to further my knowledge.

Thanks for your time!  I appreciate it!

[comment]

Ahm ... When you say that the current date is initially entered into the B::Date field: does the A::endDate field contain the current date?

 

[eljefejb]

Doh! 

I've been saying "current date" this whole time, but, you're right - FM is entering the value of A::endDate for B::Date.  In my test file (attached) that would be Friday, 6/30.    I guess my brain has been ready for it to be Friday for a while.  😄

Curiously, if I click in one of the other portal fields first, then use the date picker, the value will remain as selected.  Does that mean that, by activating the calendar button first, you aren't really entering the actual field in the portal row, and therefore no record is created in which to store the selected value?  The field isn't entered until the date picker is closed, at which point the value has been forgotten?

DateTest.fmp12

[comment]

Let's clear up some false notions first:

• This has nothing to do with drop-down calendar; you will get the same behavior if you enter the date by typing it (or even pasting, or drag'n'dropping).
• This has nothing to do with the current date; the value that is force-entered is coming from one of the fields in the parent table.

The short explanation for what you see is that the Date field is a match field in the relationship - and when you create a record via a relationship, Filemaker will populate the match fields for you in order to make sure you are creating a related record.

Even with a basic relationship such as:

Parent::ParentID = Child::ParentID

if you attempt to create a related record by entering a value into Child::ParentID field in the first empty portal row, Filemaker will replace the value with the current record's Parent::ParentID value. This is different from the behavior in an already populated row, where entering a different value will break the relationship and cause the record to disappear from the portal. 

You might argue that in your case it is not necessary to replace the entered value, since it is within the specified range and the newly created record would be related anyway. But that's not how it works. 

In fact, Filemaker is so insistent that the record must be related, it will even populate the parent's match field/s if necessary (try clearing one or both your range fields and then create a record by choosing a date). This, BTW, happens to be the mechanism behind the technique known as "Magic Key".

 

[eljefejb]

Ah, I think I understand, now!  Thank you for the enlightenment!